Let's explore Prometheus service as a monitoring utility 🔥
It's an open-source system for monitoring services and alerts based on a time series data model. Prometheus collects data and metrics from different services and stores them according to a unique identifier—the metric name—and a time stamp.
What is the Architecture of Prometheus Monitoring?
The architecture of Prometheus monitoring consists of several main components:
Prometheus Server: The Prometheus server scrapes and stores the time series data. It collects metrics from targets and stores them as time series data with timestamps and labels.
Prometheus Targets: The targets expose metrics that the Prometheus server scrapes. Targets can be instrumented applications, exporters, or other services. Exporters are used to expose metrics from services that do not natively support Prometheus.
Alertmanager: The Alertmanager handles alerts generated by Prometheus. It can group, route, and inhibit alerts and send notifications through email, PagerDuty, etc.
Client Libraries: Client libraries are available for various programming languages. They help instrument applications to expose metrics in formats that Prometheus can scrape.
Prometheus Exporters: Exporters are used to expose metrics from services that don't natively support Prometheus. There are exporters for databases, hardware, APIs, and other services.
Service Discovery: Service discovery is used to automatically detect targets for Prometheus to scrape. This can be done through tools like Consul, Kubernetes, etc.
In summary, the Prometheus server scrapes metrics from targets discovered through service discovery. The data is then queried using PromQL and visualized. Alerts are sent to the Alertmanager which notifies relevant parties.
What are the Features of Prometheus?
• A flexible and powerful query language called PromQL. This allows users to retrieve and analyze metrics data in real-time.
• It is a time-series database, so we can easily take incremental backups of our monitoring data.
• A multi-dimensional data model using time series data identified by metric name and key/value pairs.
• Metrics are collected via an HTTP pull model where the Prometheus server scrapes metrics from targets.
• Built-in visualization options like the web UI and integration with Grafana for dashboards.
• Individual Prometheus server nodes operate autonomously with no dependency on distributed storage.
• Targets can be discovered via service discovery or static configuration.
• Client libraries are available for instrumenting applications to expose metrics to Prometheus.
• The Alertmanager component handles alerting based on alerting rules. It can route, inhibit, and deduplicate alerts.
Prometheus is useful for monitoring and alerting tasks like application performance monitoring, load testing, infrastructure monitoring, and setting up alerts based on key performance indicators.
What are the Components of Prometheus?
The main components of Prometheus are:
• Prometheus Server which does the actual monitoring work, consists of three components. A Data retrieval worker that scrapes the data from the target endpoints, a TSDB which stores all the collected data metrics and an HTTP server.
• Prometheus pulls the metric data from the target from an HTTP endpoint which by default is the hostaddress/metrics, for that to work one target must expose that metric endpoint with data available and should be in time series format.
What database is used by Prometheus?
Prometheus uses a time series database as the backend for storing metrics. Time series databases are optimized for storing and retrieving data that is organized as values over time, which makes them a good fit for storing metrics.
Prometheus has its internal time series database for storing metrics. By default, Prometheus stores this database in the ./data directory (specified by the --storage.tsdb.path flag).
While Prometheus uses its internal time series database by default, it also supports exporting metrics to external storage backends like Thanos, Cortex and VictoriaMetrics. These external storage options provide benefits like centralized metric storage and long-term storage. Tools like Grafana can then query these external storage systems directly.
In summary, Prometheus primarily uses its internal time series database to store metrics. However, it also supports exporting metrics to external time series databases for long-term storage and centralized metric access.
What is the default data retention period in Prometheus?
By default, Prometheus retains data for 15 days. This default retention period is configured using the --storage.tsdb.retention.time flag when starting Prometheus. For example:
--storage.tsdb.retention.time=15d
The retention period can be increased by setting this flag to a higher value, for example 365d for 1 year of data retention:
--storage.tsdb.retention.time=365d
Prometheus also supports size-based retention using the
--storage.tsdb.retention.size flag. The retention policy that triggers first (either time or size) will be used.
So in summary, the default data retention period in Prometheus is 15 days. This can be increased by configuring the appropriate command line flags.
Happy Learning :)
Day 79 task is complete!
90DaysOfDevOps Tasks👇