The fire of god
This series is about Prometheus, an open source real-time monitoring alerting solution. Every time, I think of Prometheus, the Greek god who brought the fire of God. And this open source logo is also a fire, I like the design of this logo.
This series focuses on Prometheus and how to use it and its surrounding ecology to build a real-time monitoring and alarm platform of its own.
This series is intended for users who are first exposed to Prometheus. It focuses on operation and actual combat, but important concepts will also be refined and mentioned below. The series is mainly divided into the following pieces
Prometheus
Each concept introduction and construction, how to capture data (this share content)- How do I push data to
Prometheus
In what scenarios are push and pull used Prometheus
Data structure and query languagePromQL
The use of- How do Java applications and
Prometheus
Integration, how to enable service discovery if custom business metrics Prometheus
How andGrafana
Visual suite for integration and alarm setting- How to write a Java suite that integrates with monitoring Dubbo metrics
- Practical case sharing: How to monitor the market of each business end and system end
Prometheus and the basic concepts of temporal databases
Prometheus now has more than 3W stars on Github, which is basically more than 10,000 stars. It can be regarded as the absolute mainstream of the community. The community is also quite active, and there is a lot of experience to learn from. In the enterprise system, can be assured to use.
Prometheus is an open source monitoring and alarm system and time-sequence database developed by SoundCloud. Prometheus literally consists of two parts, a monitoring alarm system and a built-in timing database (TSDB).
The time series database (TSDB) can be simply understood as a database optimized to process time series data, and the arrays in the data are indexed by time. There are several major benefits over traditional structured databases:
- Time series data focuses on the rapid uptake of ocean volume data. Time series database considers each change of data as a new piece of data, so it can measure changes: analyze past changes, monitor current changes, and predict future changes. Traditional structured data can do this when the amount of data is small, but it needs to spend a lot of cost when the amount of data is large.
- High-precision data is stored for a short time, while summary data with medium or lower precision is stored for a long time. For real-time monitoring, every precise data is not necessarily required, but a summary of time data at a fixed time. This in the case of structured databases means filtering, keeping a large number of writes while also making a selection, which is more work than structured databases are designed to handle.
- The database itself must continuously compute abstractions from high-precision data for long-term storage. These calculations include both simple aggregations and complex ones. Traditional databases can’t handle that amount of computation. Because you have to count these aggregations and complex operations in real time.
Start building Prometheus
prometheus.io/
Click the Download TAB on the official website of Prometheue to Download the file. The following uses Linux as an example:
Once downloaded, unzip and run
Nohup/data/Prometheus, Prometheus -- web. Listen - address = 0.0.0.0:9090 -- config. The file = / data/Prometheus/Prometheus yml --web.enable-lifecycle --storage.tsdb.path=/data/prometheus/data --storage.tsdb.retention.time=15d &Copy the code
Thus, the Prometheus server is simply set up. At this point, we can access it on the Web
http://127.0.0.1:9090
You can go to the administration page
Several labels on the interface are as follows:
Alert: Configures alarm rules. We will then replace this with Grafana’s own alarm interface configuration.
Graph: A console for running PromQL statements and graphically displaying the resulting statements, as described in a later section.
Status: Displays the system information, system Status, configuration information, target node Status, and service discovery Status.
Prometheus overall architecture and ecology
This is the official overall architecture. The beige is for Prometheus’ own components, and the green is for third-party middleware and applications.
A brief introduction to the overall Prometheus ecosystem:
Prometheus
There’s only one way to get the data, which isscrape
, also known aspull
“, which means pull.Prometheus
Every once in a while, from the goal (target
) here toHttp
Protocol pull indicator (metrics
), these targets can be applications, proxies, cache middleware, databases, etc.- Pull out the data
Prometheus
Will be stored in its own TSDB database. Own WebUI console as wellGrafana
The data can be continuously queried in the time range, and plotted into a real-time chart to show. Prometheus
Support for examplezookeeper
.consul
Service discovery middleware such astarget
). You don’t have to configure them individuallytarget
.alertManager
Components support custom alarm rules and various alarm channels
Pull the data
Prometheus gets data primarily by pulling, or simply by periodically accessing a configured target, which is a URL to which data is fetched.
Now let’s simulate a data source and ask Prometheus to pull it.
Create a new SpringBoot Web project with the POM dependency added
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
Copy the code
Add in the application. The properties
server.port=8080
anagement.endpoints.web.exposure.include=*
Copy the code
After startup, we can access the following address on the page:
http://127.0.0.1:8080/actuator/prometheus
The following data is obtained:
aboutactuator
How to monitor application metrics and how to customize metrics will be covered separately in a later series, but just assume that we started a service and provided a URL to list some metrics in kv form.
For example, jvm_memory_max_bytes{area=”heap”,id=”PS Old Gen”,} 2.863661056E9 has a key before it and a value after it.
Key is divided into key name and key labels. Key name is jVM_MEMORY_MAX_bytes. There are two key labels.
This metric provides the maximum memory for the JVM, where area is heap, indicating that this is the heap area, and ID is PS Old Gen, indicating that this is the Old age. Taken together, this metric is the old maximum in the JVM. The value type is byte, which translates to about 286M.
After we have the data source of the indicator, edit the Prometheus. Yml file in the root directory of Prometheus and add the following configuration:
- job_name: 'test'
scrape_interval: 5s
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['localhost:8080']
labels:
instance: demo
Copy the code
This configuration said prometheue every 5 seconds from http://localhost:8080/actuator/prometheus this url pull indicators, and add the instance this tag for each of the indicators.
After adding Prometheus, restart Prometheus. The Targets page on the Web page is displayed. If the previous steps worked, you should see:
If the status is UP, prometheue has successfully obtained data from the target.
Enter the key of the previous metric on the query page:
Each value here is the last data captured by Prometheus. Every time you execute it, the data changes.
The reason why there are multiple pieces of data here is because each indicator has a different label. The exact same label would be classified as an indicator.
Click the Graph TAB to see the trend of an index over time series
The figure above shows the changes of the system CPU specifications.
The last
In a world where microservices are ubiquitous and small businesses have nearly a hundred microservice nodes, the Prometheus ecosystem allows all data to be visualized in real time with minimal cost. What this means for development and operations is that all the data is no longer a black box, and at least for me it feels safe to observe and analyze all the data.
This series is designed to teach you step by step how to build your own system and monitor your business by using practical operations. We’ll continue to update it. The next section will analyze how to build pushGateway to push data to Prometheus and what scenarios the two different data acquisition methods are used for respectively.
Contact the author
Welcome to follow “Yuanren Tribe” on wechat public account.
Free access to 50G technical data, including a complete set of enterprise micro service courses and seckill courses