关于prometheus:Prometheus-监控系统

软件的开发不仅仅在于解决业务，它还须要程序尽可能的运行上来，这就波及到了服务的稳定性。稳定性波及很多因素，硬件软件都须要保障。为了能让这些条件更加短缺，咱们须要一直的收集数据，剖析数据，监控数据，进而优化能优化的点。Prometheus 在这方面就为咱们提供了很好的监控计划。

Prometheus 是一个开源的监控和报警零碎，它将咱们关怀的指标值通过 PULL 的形式获取并存储为工夫序列数据。如果单从它的收集性能来讲，咱们也能够通过 mysql、redis 等形式实现。然而，这些数据是在每时每刻产生的，其宏大的规模须要咱们好好的思考其存储形式。另外，这些监控数据大多数时候是跟统计相干的，比方数据与工夫的散布状况等，这须要有业余的度量常识。而这些正是 Prometheus 的善于所在。

因为 Prometheus 的关注重点在于指标值以及工夫点这两个因素，所以内部程序对它的接入老本十分的低。这种易用性能够让咱们对数据进行多维度、多角度的察看和剖析，使得监控的成果更加具体化，例如内存耗费、网络利用率、申请连接数等。

除此之外，Prometheus 还具备了操作简略、可拓展的数据收集和弱小的查询语言等个性，这些个性能帮忙咱们在问题呈现的时候，疾速告警并定位谬误。所以当初很多微服务基础设施都会抉择接入 Prometheus，像 k8s、云原生等。

Prometheus 为了保障它的拓展性、可靠性，在除了提供外围的 server 外还提供了很多生态组件，为了不减少了解的复杂度，咱们先从上帝视角，看看它的外围 Prometheus server：

能够看到，Prometheus server 的解决链路很清晰，其实就是数据收集 - 数据存储 - 数据查问。当然，一个欠缺的零碎必定会衍生出许多组件来撑持它的个性。所以咱们会看到，在 Prometheus 架构里还存在着其余的组件，例如：

Pushgateway：为监控节点提供 Push 性能，再由 Prometheus server 到 Pushgateway 集中 Pull 数据。
Targets Discover：依据服务发现获取监控节点的地址。
PromQL：针对指标数据查问的语言，相似 SQL。
Alertmanager：依据配置规定以及指标剖析，提供告警服务。

最初，Prometheus 的整体架构如下：

下面提到 Prometheus 的外围关注点在于指标（Metrics），指标咱们能够简略的了解为一个度量值，这个值能够是 CPU 负载、内存应用、申请连接数等。它们来源于操作系统、应用服务、设施数据等，会随着工夫的变动而有所不同。为了能让这些指标更好的体现出度量外延，Prometheus 提供了四种指标类型：

Counter（计数器）：只增不减的计数器
Gauge（仪表盘）：可增可减，任意变动的仪表盘
Histogram（直方图）：将指标进行量化均匀，失去相似在 0~10ms 之间的申请数有多少，而 10~20ms 之间的申请数又有多少的直方图
Summary（摘要）：histogram 在客户端是简略的分桶和分桶计数，因为 prometheus 服务端基于这么无限的数据做百分位估算，不是很精确，summary 就是解决百分位精确的问题而来的。

实际上，在 Prometheus 里指标的组成有几局部：指标名、labels、指标值。（labels 就是咱们常常提到的维度）。例如，上面就是一个对于 http 的计数器类型指标数据：

# HELP prometheus_http_requests_total Counter of HTTP requests.
# TYPE prometheus_http_requests_total counter
prometheus_http_requests_total{code="200",handler="/api/v1/label/:name/values"} 7
prometheus_http_requests_total{code="200",handler="/api/v1/query"} 19
prometheus_http_requests_total{code="200",handler="/api/v1/query_range"} 27
prometheus_http_requests_total{code="200",handler="/graph"} 11
prometheus_http_requests_total{code="200",handler="/metrics"} 8929
prometheus_http_requests_total{code="200",handler="/static/*filepath"} 52
prometheus_http_requests_total{code="302",handler="/"} 1
prometheus_http_requests_total{code="400",handler="/api/v1/query_range"} 6

须要留神的是，Prometheus 须要收集的数据是随着工夫的增长而增长的，所以它个别不倡议保留长期的指标数据，默认保留 15 天。如果监控的数据发现问题，那么须要咱们配置告警发现，疾速解决。

对于 Prometheus 的应用置信网上有很多具体教程，此处不再阐明。咱们来看下它的要害配置文件：prometheus.yml：

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

能够看到，次要分为了三局部：全局配置（例如数据收集工夫距离）、告警规定、监控节点。告警规定是基于 PromQL 表达式触发条件的，如：

groups:
    - name: example
      rules:
      - alert:  InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: Instance has been down for more than 5 minutes

PromQL 是 Prometheus 内置的数据查询语言，就像 Mysql 的 SQL 语句一样，为咱们提供了丰盛的查问性能，可利用在面板上查问过滤、告警规定里的表达式等。上面咱们就来初步意识下 PromQL。

PromQL 是面向指标查问的，后面咱们说过，指标是由指标名、labels、指标值组成的，所以当咱们想要查问某个指标时，便能够在浏览器拜访 http://localhost:9090/graph 后输出如下表达式：

prometheus_http_requests_total

而后就能够看到相干的指标值了：

像下面这种查问表达式返回的后果被称之为 刹时向量 ，即返回后果里每个标签的每个指标只会存在单个值。如果咱们想要按工夫范畴来查问的话，那么就须要应用 区间向量 表达式了，通过 [] 来抉择咱们的工夫。例如：

prometheus_http_requests_total[1m]

示意查问最近 1 分钟的样本数据

![prometheus_http_requests_total[1m]](https://img-blog.csdnimg.cn/e…,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAeXVlX3hpbl90ZWNo,size_20,color_FFFFFF,t_70,g_se,x_16)

除了刹时向量、区间向量，PromQL 的返回还有 标量 （一个浮点型的数据值）、 字符串 类型，依据这些后果类型，咱们就也做更多的操作了。

PromQL 反对咱们对指标后果进行运算，比方：

算术运算符：+（加法）、–（减法）、*（乘法）、/（除）、%（模）、^（幂）。
比拟运算符：>（大于）、<（小于）、==（等于）、!=（不等于）、>=（大于或等于）、<=（小于或等于）
逻辑运算符：and（与）、or（或）、unless（排除）
聚合运算：sum（和）、min（最小）、avg（均匀）、count（总数）、stddev（计算维度上的总体标准偏差）、stdvar（计算维度上的总体规范方差）等

有了这些运算符，咱们就可更灵便的解决指标值了。

当然，咱们也能够对数据进行过滤，在 PromQL 里次要有以下两种过滤表达式：

齐全匹配：即 = 和 != 的用法
正则匹配：携带了正则表达式，能够用 =~ 和!~ 分表示意正向和反向匹配

例如：process_cpu_seconds_total{job="Node Exporter"} 将筛选标签 job = Node Exporter 的指标数据。

Prometheus 2.x 默认将工夫序列数据库保留在本地磁盘中，当然，咱们也能够将数据保留到第三方的存储服务中。

Prometheus 依照两个小时为一个工夫窗口，将两小时内产生的数据存储在一个块（Block）中。每个块都是一个独自的目录，外面蕴含了对应工夫窗口内的所有样本数据（chunks），元数据文件（meta.json）以及索引文件（index）。

其中索引文件会将指标名称和标签索引到样板数据的工夫序列中。此期间如果通过 API 删除工夫序列，删除记录会保留在独自的逻辑文件 tombstone 当中。

而样本数据所在的块则会被间接保留在内存中，不会长久化到磁盘中。为了确保 Prometheus 产生解体或重启时可能复原数据，Prometheus 启动时会通过预写日志（write-ahead-log(WAL)）从新记录，从而复原数据。
预写日志文件保留在 wal 目录中，每个文件大小为 128MB。wal 文件包含还没有被压缩的原始数据，所以比惯例的块文件大得多。个别状况下，Prometheus 会保留三个 wal 文件，但如果有些高负载服务器须要保留两个小时以上的原始数据，wal 文件的数量就会大于 3 个。

受限于可拓展性和持久性，Prometheus 的本地存储仅限于单个节点，所以 Prometheus 并没有提供集群的存储解决方案，而是提供了一系列的接口，以便和近程存储系统相结合，比方当咱们在 prometheus.yml 配置文件里配置了 Remote Write(近程写) 的 URL 地址后，Prometheus 就会将采集到的样本数据通过 HTTP 的模式发送给适配器，后续用户就能够在适配器里对接内部服务了。内部服务能够是真正的存储系统，也能够是云存储、音讯队列等。

和Remote Write(近程写) 一样，当咱们在配置文件里配置了 Remote Read(近程读) 的 URL 地址后，就会通过 HTTP 的模式到 Adaptor 里查问数据，而后 Adaptor 再去第三方存储服务里获取数据转发回来。

因为 Prometheus 是以指标为要害数据，所以当咱们想要对数据进行一条链路的走向时，是达不到的。而且它的数据是面向工夫程序的，如果咱们想要提供一些报表解决，那是挺难的。

另外，因为 Prometheus 是奔着简略易拓展目标设计的，所以在分布式存储、集群、多租户等方面根本没有波及，它更专一于实时监控。

系统监控其实是每一个成熟架构都须要思考的重点，它是基础设施里的重要组成部分，能让咱们提前发现问题，解决问题。而 Prometheus 作为风行的开源监控零碎，当初逐步成为了规范，所以提前相熟它，应用它，还是大有收益的，毕竟保障业务的稳定性，也是咱们开发工作的一部分呢。

[1]what is prometheus?
[2]一篇文章带你了解和应用 prometheus 的指标
[3]prometheus 中文文档

感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。

关于prometheus:Prometheus-监控系统

前言

什么是 Prometheus？

Prometheus 的整体架构

指标(Metrics)

Prometheus 配置

PromQL

运算符

数据过滤

数据存储

本地存储

近程存储

Prometheus 毛病

总结

参考