Prometheus endpoint monitoring with Netdata

Prometheus endpoints are HTTP interfaces exposed by various applications and services that provide metrics in a format consumable by Prometheus. These endpoints follow the OpenMetrics exposition format, which ensures compatibility with Prometheus monitoring. By collecting and analyzing metrics from these endpoints, Prometheus enables users to gain deep insights into their infrastructure’s performance and health, helping them detect and resolve issues proactively. The ability to monitor Prometheus endpoints is crucial for maintaining the performance and reliability of modern applications and systems.

These endpoints enable you to track and analyze various aspects of your infrastructure. From monitoring system-level components like CPU usage, memory, and network traffic to keeping an eye on application-specific metrics such as request rates, error rates, and latency, Prometheus endpoints play a crucial role in ensuring the optimal performance of your systems and allowing you to make data-driven decisions.

As part of Netdata’s big tent philosophy, we aim to provide a comprehensive monitoring solution that integrates seamlessly with various technologies, including Prometheus.

How can Netdata Help?

Netdata offers an efficient and user-friendly way to monitor Prometheus endpoints. By using Netdata, you get instant opinionated dashboards for every Prometheus endpoint with near zero configuration. This simplifies the monitoring process and allows you to focus on what matters most—ensuring the optimal performance of your systems. Netdata’s Prometheus Endpoint Collector comes with several features that make it an excellent choice for monitoring your Prometheus endpoints:

• Compatibility with OpenMetrics exposition format: Netdata’s collector is designed to work seamlessly with the OpenMetrics exposition format, ensuring smooth integration with your existing Prometheus setup.
• Autodetection of 1000+ Prometheus endpoints: Netdata can automatically detect and monitor nearly 1000 Prometheus endpoints, making it easier than ever to keep track of your infrastructure.
• Instant Dashboards: Netdata automatically generates one or more charts for every metric collected via a Prometheus endpoint. The number of charts depends on the number of exposed metrics. This allows you to visualize and analyze the data collected from your Prometheus endpoints easily. For example, scraping a node_exporter produces over 3000 metrics. Netdata will create charts for all these metrics, giving you a comprehensive overview of your system’s performance.

Configuring Netdata for Prometheus Endpoint Monitoring

Edit the go.d/prometheus.conf configuration file using edit-config from the Netdata config directory, which is typically at /etc/netdata.

cd /etc/netdata # Replace this path with your Netdata config directory
sudo ./edit-config go.d/prometheus.conf

Here is an example with two endpoints:

jobs:
  - name: node_exporter_local
    url: http://127.0.0.1:9100/metrics

  - name: win10
    url: http://203.0.113.0:9182/metrics

Endpoints can be either local or remote as long as they provide their metrics at the provided URL.

For all available options, see the Prometheus collector’s configuration file.

Collecting Metrics from Prometheus Endpoints in Kubernetes

Netdata is also capable of collecting metrics from Prometheus endpoints within a Kubernetes environment. Service discovery supports Prometheus endpoints via the Prometheus collector, making it simple to integrate Netdata into your Kubernetes setup.

Annotations on pods provide fine control over the scraping process, allowing you to customize how Netdata collects data from your Prometheus endpoints:

• prometheus.io/scrape: By default, Netdata will scrape all pods. If you set this annotation to false, the pod will be excluded from the scraping process.
• prometheus.io/path: If the metrics path is not /metrics, you can define the correct path using this annotation.
• prometheus.io/port: Specify the port that Netdata should scrape the pod on, instead of using the pod’s declared ports.