Considering using Prometheus, but worried about committing to using our clients?
When starting out with a new technology it is wise not to end up in a situation later on where you've decided not to use it, but it's still lingering around your codebase. This is one of the reasons I recommend to start out with the Node exporter when exploring Prometheus, rather than going all-out with instrumenting your code base. When it comes to providing instrumentation from inside for Prometheus from inside your applications, this concern should be kept in mind but should not be the only factor in your decision.
The first thing to be aware of is that the Prometheus text format used for transferring metrics has become something of a defacto standard with many different commercial and non-commercial monitoring systems able to ingest it, including Datadog, InfluxDB, Outlyer, Sensu, Metricbeat, Sysdig, and SignalFX. By using a Prometheus client you not only get modern instrumentation that is designed to work with the full Prometheus data model, but offers you options in the future if you decide to use other monitoring systems. Furthermore there's work underway to make the Prometheus text format an actual standard, and the Prometheus client libraries will almost certainly form part of that.
The second thing is that Prometheus clients are not limited to outputting the Prometheus text format. That is how they are usually used, but the code that does so uses public APIs that you can use to output to other formats. As an example of this the Python, Java, and Go client libraries can all export to Graphite out of the box. The Prometheus clients are intended to be open.
So if you're using Prometheus, don't be afraid to get the most out of your instrumentation by using a Prometheus client library!
Looking to integrate Prometheus with other monitoring systems? Contact us.
No comments.