自从上了 Prometheus 监控！睡觉踏实多了

点关注公众号，回复“1024”获取2TB学习资源！

背景

对很多人来说，未知、不确定、不在掌控的东西，会有潜意识的逃避。当我第一次接触 Prometheus 的时候也有类似的感觉。对初学者来说， Prometheus 包含的概念太多了，门槛也太高了。

概念：Instance、Job、Metric、Metric Name、Metric Label、Metric Value、Metric Type（Counter、Gauge、Histogram、Summary）、DataType（Instant Vector、Range Vector、Scalar、String）、Operator、Function

马老师说：“虽然阿里巴巴是全球最大的零售平台，但阿里不是零售公司，是一家数据公司”。Prometheus 也是一样，本质来说是一个基于数据的监控系统。

日常监控

假设需要监控 WebServerA 每个API的请求量为例，需要监控的维度包括：服务名（job）、实例IP（instance）、API名（handler）、方法（method）、返回码(code)、请求量（value）。

如果以SQL为例，演示常见的查询操作：

查询 method=put 且 code=200 的请求量(红框)

SELECT * from http_requests_total WHERE code=”200” AND method=”put” AND created_at BETWEEN 1495435700 AND 1495435710;

查询 handler=prometheus 且 method=post 的请求量(绿框)

SELECT * from http_requests_total WHERE handler=”prometheus” AND method=”post” AND created_at BETWEEN 1495435700 AND 1495435710;

查询 instance=10.59.8.110 且 handler 以 query 开头 的请求量(绿框)

SELECT * from http_requests_total WHERE handler=”query” AND instance=”10.59.8.110” AND created_at BETWEEN 1495435700 AND 1495435710;

通过以上示例可以看出，在常用查询和统计方面，日常监控多用于根据监控的维度进行查询与时间进行组合查询。如果监控100个服务，平均每个服务部署10个实例，每个服务有20个API，4个方法，30秒收集一次数据，保留60天。那么总数据条数为：100(服务) 10（实例） 20（API） 4（方法） 86400（1天秒数）* 60(天) / 30（秒）= 138.24 亿条数据，写入、存储、查询如此量级的数据是不可能在Mysql类的关系数据库上完成的。因此 Prometheus 使用 TSDB 作为存储引擎。

存储引擎

TSDB 作为 Prometheus 的存储引擎完美契合了监控数据的应用场景

存储的数据量级十分庞大

大部分时间都是写入操作

写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序

写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库

删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据

基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何作用

读操作是十分典型的升序或者降序的顺序读

高并发的读操作十分常见

那么 TSDB 是怎么实现以上功能的呢？

"labels": [{     "latency":        "500" }] "samples":[{     "timestamp": 1473305798,     "value": 0.9 }]

原始数据分为两部分 label, samples。前者记录监控的维度（标签:标签值），指标名称和标签的可选键值对唯一确定一条时间序列（使用 series_id 代表）；后者包含包含了时间戳（timestamp）和指标值（value）。

series ^ │. . . . . . . . . . . .   server{latency="500"} │. . . . . . . . . . . .   server{latency="300"} │. . . . . . . . . .   .   server{} │. . . . . . . . . . . .  v <-------- time ---------->

TSDB 使用 timeseries:doc:: 为 key 存储 value。为了加速常见查询查询操作：label 和 时间范围结合。TSDB 额外构建了三种索引：Series, Label Index 和 Time Index。

以标签 latency 为例：

存储两部分数据。一部分是按照字典序的排列的所有标签键值对序列（series）；另外一部分是时间线到数据文件的索引，按照时间窗口切割存储数据块记录的具体位置信息，因此在查询时可以快速跳过大量非查询窗口的记录数据

每对 label 为会以 index:label: 为 key，存储该标签所有值的列表，并通过引用指向 Series 该值的起始位置。

数据会以 index:timeseries:: 为 key，指向对应时间段的数据文件

数据计算

强大的存储引擎为数据计算提供了完美的助力，使得 Prometheus 与其他监控服务完全不同。Prometheus 可以查询出不同的数据序列，然后再加上基础的运算符，以及强大的函数，就可以执行 metric series 的矩阵运算（见下图）。

如此，Promtheus体系的能力不弱于监控界的“数据仓库”+“计算平台”。因此，在大数据的开始在业界得到应用，就能明白，这就是监控未来的方向。

一次计算，处处查询

当然，如此强大的计算能力，消耗的资源也是挺恐怖的。因此，查询预计算结果通常比每次需要原始表达式都要快得多，尤其是在仪表盘和告警规则的适用场景中，仪表盘每次刷新都需要重复查询相同的表达式，告警规则每次运算也是如此。因此，Prometheus提供了 Recoding rules，可以预先计算经常需要或者计算量大的表达式，并将其结果保存为一组新的时间序列， 达到 一次计算，多次查询的目的。

以上内容链接：cyningsun.com/02-22-2020/hidden-secret-to-understanding-prometheus.html

安装 Prometheus server

Prometheus 可以支持多种安装方式，包括 Docker、Ansible、Chef、Puppet、Saltstack 等。下面介绍最简单的两种方式，一种是直接使用编译好的可执行文件，开箱即用，另一种是使用 Docker 镜像。

首先从 官网的下载页面 获取 Prometheus 的最新版本和下载地址，目前最新版本是 2.4.3（2018年10月），执行下面的命令下载并解压：

$ wget https://github.com/prometheus/prometheus/releases/download/v2.4.3/prometheus-2.4.3.linux-amd64.tar.gz   $ tar xvfz prometheus-2.4.3.linux-amd64.tar.gz

然后切换到解压目录，检查 Prometheus 版本：

$ cd prometheus-2.4.3.linux-amd64   $ ./prometheus --version   prometheus, version 2.4.3 (branch: HEAD, revision: 167a4b4e73a8eca8df648d2d2043e21bdb9a7449)     build user:       root@1e42b46043e9     build date:       20181004-08:42:02     go version:       go1.11.1

运行 Prometheus server：

$ ./prometheus --config.file=prometheus.yml

使用 Docker 安装 Prometheus 更简单，运行下面的命令即可：

$ sudo docker run -d -p 9090:9090 prom/prometheus

一般情况下，我们还会指定配置文件的位置：

$ sudo docker run -d -p 9090:9090 \       -v ~/docker/prometheus/:/etc/prometheus/ \       prom/prometheus

我们把配置文件放在本地 ~/docker/prometheus/prometheus.yml，这样可以方便编辑和查看，通过 -v 参数将本地的配置文件挂载到 /etc/prometheus/ 位置，这是 prometheus 在容器中默认加载的配置文件位置。如果我们不确定默认的配置文件在哪，可以先执行上面的不带 -v 参数的命令，然后通过 docker inspect 命名看看容器在运行时默认的参数有哪些（下面的 Args 参数）：

$ sudo docker inspect 0c   [...]           "Id": "0c4c2d0eed938395bcecf1e8bb4b6b87091fc4e6385ce5b404b6bb7419010f46",           "Created": "2018-10-15T22:27:34.56050369Z",           "Path": "/bin/prometheus",           "Args": [               "--config.file=/etc/prometheus/prometheus.yml",               "--storage.tsdb.path=/prometheus",               "--web.console.libraries=/usr/share/prometheus/console_libraries",               "--web.console.templates=/usr/share/prometheus/consoles"           ],       [...]

正如上面两节看到的，Prometheus 有一个配置文件，通过参数 --config.file 来指定，配置文件格式为 YAML。我们可以打开默认的配置文件 prometheus.yml 看下里面的内容：

/etc/prometheus $ cat prometheus.yml    # my global config   global:     scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.     evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.     # scrape_timeout is set to the global default (10s).       # Alertmanager configuration   alerting:     alertmanagers:     - static_configs:       - targets:         # - alertmanager:9093       # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.   rule_files:     # - "first_rules.yml"     # - "second_rules.yml"       # A scrape configuration containing exactly one endpoint to scrape:   # Here it's Prometheus itself.   scrape_configs:     # The job name is added as a label `job=` to any timeseries scraped from this config.     - job_name: 'prometheus'           # metrics_path defaults to '/metrics'       # scheme defaults to 'http'.           static_configs:       - targets: ['localhost:9090']

Prometheus 默认的配置文件分为四大块：

global 块：Prometheus 的全局配置，比如 scrape_interval 表示 Prometheus 多久抓取一次数据，evaluation_interval 表示多久检测一次告警规则；

alerting 块：关于 Alertmanager 的配置，这个我们后面再看；

rule_files 块：告警规则，这个我们后面再看；

scrape_config 块：这里定义了 Prometheus 要抓取的目标，我们可以看到默认已经配置了一个名称为 prometheus 的 job，这是因为 Prometheus 在启动的时候也会通过 HTTP 接口暴露自身的指标数据，这就相当于 Prometheus 自己监控自己，虽然这在真正使用 Prometheus 时没啥用处，但是我们可以通过这个例子来学习如何使用 Prometheus；可以访问 http://localhost:9090/metrics 查看 Prometheus 暴露了哪些指标；

Prometheus+InfluxDB+Grafana 打造高逼格监控平台！

Docker部署Prometheus+Grafana监控系统

30 个高可用 Prometheus 架构实践中的踩坑集锦

Prometheus 如何做到“活学活用”，大牛总结的避坑指南

总结

最近两年 Prometheus 的发展非常迅速，社区也非常活跃，国内研究 Prometheus 的人也越来越多。随着微服务，DevOps，云计算，云原生等概念的普及，越来越多的企业开始使用 Docker 和 Kubernetes 来构建自己的系统和应用，像 Nagios 和 Cacti 这样的老牌监控系统会变得越来越不适用，相信 Prometheus 最终会发展成一个最适合云环境的监控系统。

更多学习：下一代监控系统！来看看它有多牛逼

推荐阅读 点击标题可跳转

突发！大疆宣布暂停俄罗斯乌克兰业务

你还在用命令看日志？快用 Kibana 吧，一张图胜过千万行日志

别再手撸 Shell 脚本了！送你 35 个开箱即用的实用脚本

开源维护至今 12 年，这才叫良心软件！！

神级下载工具，解决你 99% 下载难题！

Spring Boot项目配置免费HTTPS的详细流程！

ES+Redis+MySQL，这个高可用架构设计太顶了！

转发 关注

点亮下方“在看”图标

更多人看到

Docker

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。