Hello everyone, I am Wolf King, a programmer who loves playing ball
Interview breadth, depth are very important, more expansion of knowledge is always good! Take a look at Prometheus, touted as the next generation of surveillance!
preface
We know zabbix is an untouchable feature in the surveillance world. But the container monitoring is inadequate. Prometheus technology was introduced to solve the problem of monitoring containers.
The following articles are intended to be a series on Prometheus and to help clarify things for yourself.
Zabbix
Prior to Prometheus, there were several monitoring systems, such as Zabbix and Open-Falcon. So what’s the difference between Prometheus and these monitoring systems? Here we introduce Zabbix, the monitoring system.
Zabbix is an open-source distributed monitoring system developed by Alexei Vladishev. It supports multiple collection methods and collection clients, as well as SNMP, IPMI, JMX, Telnet, SSH and other protocols. It stores the collected data in the database and analyzes it. The corresponding alarm is triggered.
The core components of Zabbix are Agent and Server. Agent is responsible for collecting data and sending data to Server/Proxy in active or passive ways. In addition, Agent can execute customized scripts to expand monitoring items. The Server receives monitoring information sent by the Agent, stores it, and triggers alarms.
In order to quickly and efficiently configure Zabbix monitoring items, Zabbix provides a template mechanism for batch configuration.
Zabbix Server stores the collected monitoring data in the Zabbix Database. Zabbix Database supports common relational databases, such as MySQL, PostgreSQL, and Oracle. MySQL is the default Database. The Zabbix Web page (written in PHP) is responsible for querying the data. Zabbix’s use of relational data to store temporal data often leaves it short on data storage when monitoring large clusters. Zabbix also supports sequential data storage in version 4.2, although it is not yet mature.
Open-falcon is xiaomi’s Open source enterprise-level monitoring tool developed in Go language. It is used by Internet companies including Xiaomi, Didi and Meituan, etc. It is a flexible, scalable and high-performance monitoring solution, which will not be explained here.
The following table shows the advantages and disadvantages of their respective monitoring systems through multidimensional dimensions:
\
Prometheus profile
Prometheus is an open source system monitoring and alarm framework. Inspired by Google’s Brogmon monitoring system, it was created in 2012 by former Googlers working at SoundCloud, developed as a community open source project, and officially released in 2015.
In 2016, Prometheus officially joined the Cloud Native Computing Foundation (CNCF) program as the second most popular program after Kubernetes. At the end of 2017, version 2.0 was released based on the new storage layer, which can better cooperate with container platform and cloud platform.
Prometheus, a next-generation cloud native monitoring system, has more than 650 contributors working on Prometheus and more than 120 third-party integrations.
Prometheus pros and cons
1. Provide multi-dimensional data model and flexible query method. By associating monitoring indicators with multiple tags, monitor data can be combined in any dimension
2. Support local storage of server nodes without external storage, which can store tens of millions of data per second through the timing database provided by Prometheus; In addition, Prometheus can connect to third-party sequential databases and OpenTSDB for scenarios where large amounts of historical data are stored.
3. Defined the open index data standard to collect time series data in the METHOD of Pull based on HTTP. Only the monitoring data of Prometheus can be collected and summarized by Prometheus, and the serial data can be pushed to the intermediate gateway in the way of Push, which can deal with various monitoring scenarios more flexibly
4. Supports static file configuration and dynamic discovery to discover monitored objects and automatically complete data collection. Prometheus currently supports Kubernetes, ETCD, Consul and other service discovery mechanisms
5. Easy to maintain, can be started directly through binary files, and provides container deployment image.
6. Supports partition sampling and federated deployment of data and large-scale cluster monitoring
Components and architecture of Prometheus
Prometheus ecosystem component
The Prometheus ecosystem consists of several components, most of which are written in Go and therefore easy to deploy, most of which are optional. The main components are described below:
Prometheus Server
Prometheus Server is the core component of Prometheus and is responsible for obtaining, storing, and querying monitoring data.
Prometheus Server manages monitoring targets through static configuration or dynamically manages monitoring targets and obtains data from them using Service Discovery.
Second, Prometheus Server stores the collected monitoring data. Prometheus Server itself is a time series database that stores the collected monitoring data on local disks in a time series manner.
Finally, Prometheus Server provides a custom PromQL language for data query and analysis.
Prometheus Server’s built-in Express Browser UI enables data query and visualization directly through PromQL.
Push Gateway
The main realization is to receive the index data pushed by the Client, at the specified time interval, by the main program to grab.
Because Prometheus data acquisition is based on the Pull model, the network environment must be configured so that Prometheus Server can communicate directly with exporters.
When such network requirements cannot be met directly, PushGateway can be used for forwarding.
You can use PushGateway to Push internal network monitoring data to the Gateway.
Prometheus Server can obtain monitoring data from PushGateway in the same Pull manner.
Exporter
It collects data and exposes it to Prometheus Server through HTTP. Prometheus Server can access monitoring data to be collected through an interface provided by Prometheus.
Node_exporter, mysqLD_exporter, STATsd_exporter, Blackbox_exporter, haproxy_exporter, HAProxy, StatsD, Graphite, Redis such service monitoring;
Alarm Manager
Alarm management is mainly responsible for the realization of alarm function.
Prometheus Server supports the creation of alarm rules based on PromQL. If the PromQL rules are met, an alarm is generated, and the alarm handling process is managed by the AlertManager.
AlertManager allows for integration with email, Slack, and other built-in notifications, as well as Webhook custom alarm handling. AlertManager is the alarm handling center of Prometheus.
Prometheus architecture
The diagram above shows the Prometheus architecture. On the left are the exporters of Prometheus data format. In addition, Pushgateway can be used to convert Push to Pull to support agents that Push data types.
Prometheus may even obtain data from other Prometheus to form federated clusters. The basic principle of Prometheus is to periodically capture the status of monitored components through HTTP. Any component that provides the corresponding HTTP interface and conforms to the data format defined by Prometheus can access Prometheus monitoring.
Prometheus supports automatic discovery of monitored objects to dynamically obtain monitored objects.
In the middle of the image is the Prometheus Server. The Retrieval module periodically pulls data and stores data through the Storage module.
PromQL query syntax provided by Prometheus. The PromQL module parses the syntax tree and calls the query interface of the Storage module to obtain monitoring data.
On the right of the figure, alarms and page displays are displayed. Prometheus sends alarms to the AlertManger, and the AlertManger processes alarms and performs operations on them.
Data Display In addition to the web user interface (WebUI) provided by Prometheus, you can query Prometheus monitoring data using components such as Grafana.
Prometheus Server load periodically captures metrics data on targets, and each fetching target exposes an HTTP service interface for Prometheus’ periodically fetching. This method of calling monitored objects to obtain monitoring data is called Pull. The Pull approach represents Prometheus’ unique design philosophy, which is distinct from the Push approach used by most monitors
The advantages of the Pull mode are that upstream and horizontal monitoring can be automatically implemented. With less configuration, the Pull mode is easier to scale, more flexible, and easier to achieve high availability. Simply put, the Pull approach reduces coupling. In the push system, it is easy to break down the monitored system due to the failure of pushing data to the monitoring system. Therefore, in Pull mode, the collected end does not need to perceive the existence of the monitoring system and is completely independent of the monitoring system. In this way, data collection is completely controlled by the monitoring system
conclusion
At this point, we have seen some of the differences, advantages and disadvantages of monitoring systems, and analyzed the components of Prometheus and its overall architecture. In the next chapter, we will learn more about Prometheus.
Willing to output dry Java technology public number: Wolf king programming. The public number has a large number of technical articles, massive video resources, beautiful brain map, might as well pay attention to it! Get lots of learning resources and free books!
Forwarding moments is the biggest support for me!
\
Click “like and watching” if you feel something! Thank you for your support!