{{announcement.body}}
{{announcement.title}}

Metrics Monitoring: Open Source or Commercial Hosted? 5 Questions to Consider

DZone 's Guide to

Metrics Monitoring: Open Source or Commercial Hosted? 5 Questions to Consider

For many startups, no-cost open source seems like a no-brainer, but there are some things to keep in mind before implementing OS tools.

· Open Source Zone ·
Free Resource

Go with open source or commercial monitoring for my growing cloud application? This question is as old as open source software itself but, with the rapid growth of native cloud applications, it becomes more important than ever.

When you’re building your SaaS product and your engineering team has a tight budget, turning to an open source monitoring tool deployed in-house may look like a great option. However, as you scale for your user growth, this choice may negatively impact your engineering teams, your business, and your customers.

Developer and DevOps leaders should consider five key questions when weighing the decision to go with a commercial or open source monitoring solution.

Key Questions to Consider

1. How Important Is High-Availability of My Monitoring Platform?

Availability and reliability of monitoring directly impact a SaaS business’ bottom line as well as customer satisfaction – most businesses can’t afford their monitoring platform to be down when they need it most.

Open source tools like Prometheus handle high availability through their federation concept that is based on a complex, layered architecture like a pyramid structure. Once the limits of one “pyramid” instance are reached, you’d need the second one. If one of the instances goes away, so does your monitoring data, which is a big concern for any serious site reliability team.

With a commercial hosted monitoring tool, engineers can meet high availability requirements of their customers, particularly with tools incorporating built-in redundancies and a high availability architecture at multiple levels.

2. Should I Invest Finite Engineering Resources in Building and Maintaining a Monitoring Tool vs. My Core SaaS Business?

For a SaaS enterprise, it’s all about delivering a service your customers love. And for developers, it’s fulfilling to work on meaningful projects that directly grow business value.

As engineering teams begin adding more metrics to their open-source tool, they may begin experiencing latency issues when their metrics load. When analyzing what to do to try to scale the tooling, it may require investing up to six months of an engineer’s time to re-architect the open source implementation for scale up. And then, invest even more time to maintain it.

Teams will quickly realize the importance of shifting their focus on scaling their own business, and on innovation versus on building monitoring solutions.

3. What Amount of Time and Resources for Maintenance Should My Monitoring Platform Require?

For an engineering team supporting a rapidly growing cloud service and infrastructure, this question is particularly important. Is your team big enough to fill in gaps left with open source monitoring blind spots?

In addition, you want to avoid a situation where an open source instance doesn’t recover after a crash, which can leave you without monitoring. Switching to a commercial-hosted monitoring tool will remove the need to maintain a complex system implementation.

4. Will My Monitoring Platform Scale Immediately When I Need It, Without Having to Pay for That Scale Prematurely?

Let’s assume your SaaS business is successful and starts to grow. The important question you now need to ask is – will my tools scale?

As an organization begins to rapidly grow, so does its metrics volumes as engineers add more and more necessary telemetry. Why invest further into bigger, yet more complex open source infrastructure – efforts that would take the focus away from innovation velocity and continuing to scale the business?

Consider a scale-limiting scenario often seen when adopting open source time series tools: when one open source node gets too busy to deal with all the metrics you can either get a bigger box to run it, or give it more horsepower. Or you need to create another instance. But you then have the audacious task of configuring which instance gets what metrics from what services on your network. Having to maintain everything can get messy very quickly.

5. How Quickly Do I Need My Engineering Teams to Adopt and Use My Monitoring Platform?

As your digital enterprise grows, so does your engineering team. The speed at which a team can ramp-up on the use of a monitoring platform can determine its value.

Open source tools may appear flexible (due to query language, for example), and they may initially provide flexibility. However, these tools come with a high cost of long learning curves and long onboarding time for new team members. Additionally, even when new engineers start to using the tool, adding and pushing new metrics, they run into scaling limitations. Unable to handle a relatively light query load, the queries can become painfully slow to run, causing time-outs and crashing their browsers.

Key Takeaway

When it comes to metrics monitoring, making the decision to go open source or commercial is not easy – it requires careful consideration of both team and overarching business goals. As you review and address key questions, you can start to gather the right information to understand the situation and make a more informed decision. In the example of a SaaS business, the benefits of a commercial monitoring tool outweighed that of an open source tool, minimizing complexity, meeting high availability requirements, and facilitating scale, among other benefits. However, the decision to choose a commercial monitoring tool or an open source monitoring tool will ultimately be driven by the unique needs of teams and businesses.

Topics:
monitoring and performance ,monitoring tools ,open source ,high availability ,devops ,saas ,software as a service

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}