A dynamic environment, as a container, needs a light, performing and interoperable system for the monitoring.
The Prometheus metric/openMetrics exposure protocol is the most widespread and versatile solution as it is based on Google Borgmon system. In 2016 the Cloud Native Computing Foundation agreed to incubate the project of strengthening its opensource orientation, a feature that turned it into the most preferred solution within the scope of cloud containers.
The display of application and system metrics has to adapt to the growing opensource and web-based world. Prometheus has adopted the “Single http page for all metrics” approach that represents an effective way to meet to this need.
A metric is based on a textual line that is structured as follows:
metric_name(unit_of_measurement){label1=value1,label2=value2,…} value (timestamp)
For example:
http_request_count{page=index} 234
net_tx_interface_bytes{ifname=eth0} 123
A metric cardinality results from the number of labels associated with it. All popular programming languages provide a compatible exporter. Among them there are:
- Python: https://github.com/prometheus/client_python
- Golang: https://github.com/prometheus/client_golang
- Java: https://github.com/prometheus/client_java
Similarly, most commonly used frameworks have a specialized library that includes all necessary basic metrics, for example:
- Springboot: https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html
Prometheus Main Features
TimeseriesDB
The Prometheus team introduced a custom format to maximize performance in response to the high performance yet low impact requirements in terms of computational resources. Each data block residing in a folder on the filesystem contains two hours of samples. Additionally, they include the metric partitioning in that specific time range that is called chunk series. The main advantage of this format is that each metric occupies approximately either 1 or 2 Bytes per sample.
[root@prometheus small]# tree ├── 2020_07 │ ├── 119236896_79269_20200721133611.531_20200721154700.066_1623BA8D67E4C1A3 │ │ ├── index.bin │ │ ├── metaindex.bin │ │ ├── timestamps.bin │ │ └── values.bin │ ├── 146250_76434_20200721162658.025_20200721162722.922_1623BA8D67E4C3BE │ │ ├── index.bin │ │ ├── metaindex.bin │ │ ├── timestamps.bin │ │ └── values.bin
Metric collection service
Prometheus acquires metrics from the configured endpoints in two different ways: it can do it statically in a configuration file; or dynamically by using a supported discovery service like a major cloud provider, such as Kubernets.
The main benefits of Prometheus, in opposition to other approaches to monitoring and acquiring metrics, is the simplicity of collection (it is the application/system that exposes the metrics) without the need for agents installed on the endpoint.
As we will explore further, this approach is most effective in the container area.
