GC stats are one of the many metrics that the Java/JVM client library exposes.
A blog on monitoring, scale and operational Sanity
GC stats are one of the many metrics that the Java/JVM client library exposes.
While the Java client library uses pom.xml and Maven, there's nothing stopping you from using other tools such as Gradle
The Prometheus instrumentation best practices say to "Avoid missing metrics". Let's look at why, and how to deal with it.
If you've determined a metric should be tested, how do you go about that?
If you've an existing instrumentation library in use, it's not always practical to immediately switch to a Prometheus instrumentation library. There are a multitude of integrations available to aid your transition.
The Prometheus client library guidelines recommend having a Child
be returned via labels()
. Why?
A common question around Prometheus client libraries is how much RAM they'll use on a busy process. There tends to be disbelief when we say it's the same as an inactive server. Let's look deeper.
I previously looked at how the Prometheus Python client can output to Graphite. You can do the same with the Java client, letting you instrument once and integrate with non-Prometheus monitoring systems.
Getting started with a new library it helps to have an example to work from. Let's look at a simple example of using Prometheus instrumentation in Java.
Sometimes mBeans produce errors when scraped by the JMX exporter. Being able to look at detailed logs can help you figure out exactly which mBean is having issues and why.