What do you like best about the product?

Chronosphere feels like an observability product that was built for engineers and operators. After seeing costs blow up with competing products while working on observability at previous companies, it's refreshing to see a platform that puts the customer's needs first–especially with managing costs. Data generated by machines at scale can quickly and easily get out of hand, and having flexible controls makes our lives easier.

Early in the onboarding process, I was blown away when we discussed the tools available in the aggregation tier. It appeared that giving us this level of control wouldn't be good for Chronosphere's revenue in the long run, but I soon realized it's part of their philosophy and mission to give the power back to the customers. As an operator coming from an ELK-based stack (which comes with plenty of operational toils), Chronosphere is a true SaaS where you don't need to worry about the underlying storage and query infrastructure.

The profiling tools that allow you to look at incoming data at various process stages have been handy in many cases. The backend ingest and query performance have been phenomenal, especially compared to our legacy stack. Being able to use rollups to extend the retention of data will prove helpful to us in the long run, which isn't something we've been able to do effectively in our legacy stack.

Product aside, the team has been highly supportive throughout the process, from onboarding to implementation to stabilization. They've been a solid partner for the complex project of moving observability stacks within a large engineering organization.

What do you dislike about the product?

We've made good progress with the controls we've been given but still struggle with cardinality explosion on the client side and its impacts on application performance. While battle-tested in production at scale, the Prometheus client library has challenges that require attention and boundaries to prevent misuse and anti-practices. This challenge is exacerbated in large organizations where engineers have varying levels of experience with time series metrics and the concept of cardinality.

This challenge is somewhat outside of the sphere of responsibility of Chronosphere. Like the Chronosphere collector, I think there might be some opportunity for productized tooling on the library side to help solve common problems across all organizations working with Prometheus. Still, on the bright side, the team is working on backend features like the usage profiler to give us the next level of visibility.

What problems is the product solving and how is that benefiting you?

Chronosphere is helping us collect, monitor, and visualize our application and infrastructure metrics. It allows us to use the open-source Prometheus ecosystem at scale without having to manage the backend.