Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.
Prometheus implements a highly dimensional data model. Time series are identified by a metric name and a set of key-value pairs. Prometheus fundamentally stores all data as time series: streams of timestamped values belonging to the same metric and the same set of labeled dimensions. Besides stored time series, Prometheus may generate temporary derived time series as the result of queries.
A flexible query language allows slicing and dicing of collected time series data in order to generate ad-hoc graphs, tables, and alerts. Prometheus provides a functional expression language that lets the user select and aggregate time series data in real time. The result of an expression can either be shown as a graph, viewed as tabular data in Prometheus’s expression browser, or consumed by external systems via the HTTP API.
Prometheus has multiple modes for visualizing data: a built-in expression browser, Grafana integration, and a console template language.
Prometheus stores time series in memory and on local disk in an efficient custom format. Scaling is achieved by functional sharding and federation. Prometheus includes a local on-disk time series database, but also optionally integrates with remote storage systems. Prometheus’s local time series database stores time series data in a
custom format on disk.
Each server is independent for reliability, relying only on local storage. Written in Go, all binaries are statically linked and easy to deploy. Prometheus is configured via command-line flags and a configuration file. While the command-line flags configure immutable system parameters (such as storage locations, amount of data to keep on disk and in memory, etc.), the configuration file defines everything related to scraping jobs and their instances, as well as which rule files to load.
Alerts are defined based on Prometheus’s flexible query language and maintain dimensional information. An alertmanager handles notifications and silencing. Alerting rules allow you to define alert conditions based on Prometheus expression language expressions and to send notifications about firing alerts to an external service.
Whenever the alert expression results in one or more vector elements at a given point in time, the alert counts as active for these elements’ label sets.
Client libraries allow easy instrumentation of services. Over ten languages are supported already and custom libraries are easy to implement. Before you can monitor your services, you need to add instrumentation to their code via one of the Prometheus client libraries. These implement the Prometheus metric types.
Existing exporters allow bridging of third-party data into Prometheus. Examples: system statistics, as well as Docker, HAProxy, StatsD, and JMX metrics. There are a number of libraries and servers which help in exporting existing metrics from third-party systems as Prometheus metrics. This is useful for cases where it is not feasible to instrument a given system with Prometheus metrics directly (for example, HAProxy or Linux system stats).
JFrog Artifactory is the only repository manager that fully supports all major…
NFS-client is an automatic provisioner that use your existing and already…
This chart bootstraps a Fluentd daemonset on a Kubernetes cluster using the…
Tell us about a new Kubernetes application
Never miss a thing! Sign up for our newsletter to stay updated.
Discover and learn about everything Kubernetes