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.
Reliable Insights
A blog on monitoring, scale and operational Sanity
High CPU load is a common cause of issues. Let's look at how to dig into it with Prometheus and the Node exporter.
Whether you're on bare metal or using a cloud provider, there's a question you should always be able to answer. What machines do I have, and what is meant to be running on them?
Read more
As your Prometheus usage grows and starts to get loaded, it'd be useful to know which metrics are using the most resources so that you can re-evaluate their utility.
A common question from new users is if they need to restart Prometheus every time they change the configuration. The good news is that you don't, allowing your monitoring to continue uninterrupted as your system changes.
Failed requests are a fact of life, network weirdness and machine failures are inevitable. It can be tempting to simply retry the request when this happens, but this may cause more harm than good.
Prometheus doesn't try to lock you into it's ecosystem - in fact it makes it straightforward to both get data both in and out. This reduces operational overhead and allows for smoother transitions between monitoring systems.
Having to manually update a list of machines in a configuration file gets annoying after a while. One of the features of Prometheus is service discovery, allowing you to automatically discover and monitor your EC2 instances!
When getting something working for the first time, it's easy to get caught up in Docker or Vargant. Before you run it in production with full access and user data, do you know what code you're running?
The node exporter includes many metrics out of the box, it can't possibly cover all use cases though. That's where the textfile collector comes in, allowing you to extend machine instrumentation for your use case.
