运维监控系统实战笔记(day5)

文章来源：极客时间  运维监控系统实战笔记

Prometheus中有哪些关键设计？

有标准，特别是命名模式，简单直观，易懂

标准先行，注重生态

Prometheus 最重要的规范就是指标命名方式，它用标签集来标识指标。它在统一的标签集表达方式是最通用、最灵活的。

建议：标签 Key 不能随便起名，该有的标签也不能缺失。既减少了理解成本，也保证了数据的规整完备，便于后续做数据分析。比如，对于应用层面的监控，可以要求必须具备这几个信息。

• 指标名称 metric

metric（即 __name__）。如果是 Counter 类型，单调递增的值，指标名称以 _total 结尾。

• 服务名称 service

服务名称 service 要全局唯一，比如 n9e-webapi，p8s-alertmanager，一般是系统名称加上模块名称，组成最终的服务名称。如果公司比较大，就需要一个全局的服务目录做参考，否则不同的团队可能会起相同的名称，

• 实例名称 instance

一个服务一般会部署多个实例，可以直接使用机器名或 Pod 名作为 instance 名称。如果在物理机部署，有实例混部的情况，就要把端口加上，比如实例一是 10.1.2.3:3306，实例二是 10.1.2.3:3307。

• 服务类型 job

比如所有的 MySQL 的监控数据，都统一打上 job=mysql 的标签，Redis 的监控数据，就打上 job=redis 的标签。如果是自研的模块，也可以使用 webserver backend frontend 这种分类方式。

• 地域可用区 zone

把地域信息放到标签里，有个巨大的好处

• 集群名称 cluster

有的时候一个可用区会部署多个集群，特别是一些中间件，比如 ElasticSearch，给每个重要的业务单独部署一个集群

• 环境类型 env

环境类型 env 用来标识是生产环境还是测试环境。

指标的数据格式和传输协议制定好之后，各种 Exporter、各种支持 Remote Read/Write 的后端存储就可以接入进来了，而这些 Exporter、存储的丰富和繁荣，又反向推动了 Prometheus 的流行，形成正向循环。

主要使用拉模式，解耦

Prometheus 主要使用拉模式获取指标，辅以推模式（Pushgateway 的职能）。

如果是拉模式，部署好监控系统之后，再来调用中间件的接口获取数据即可。如果是推模式，就需要在中间件里重新配置监控数据上报地址，然后重启中间件，这个代价就太高了。但是拉模式需要有很好的服务发现机制

如果服务没有部署在 Kubernetes 中，而是部署在传统物理机或虚拟机上，这个时候就需要使用 Consul 之类的服务发现机制。但如果在监控体系建设之前，服务没有接入注册中心，为了满足监控需求而接入注册中心，用户会觉得成本太高。此时推模式就有了用武之地，这就是很多公司的自研服务都使用推模式发送监控数据的原因。

所以结论就来了：中间件类使用拉模式，自研的服务使用推模式，自研的服务如果都接入了注册中心，则也可以使用拉模式。

当然，推拉的选择还有一个点比较关键，就是网络通路问题，

推拉模式的选择，还有一些其他影响因素，比如推模式服务端通常比较容易处理，因为数据接收是无状态的。但是拉模式在数据量大的时候要考虑分片的问题，还有就是失联告警问题，拉模式很容易感知到目标失联。推模式就比较复杂了，需要对数据缺失做告警，比如 Prometheus 的 absent 函数，absent 函数需要把指标的每个标签都写全，才能达到预期效果。而指标数量何止千万，几乎不可能完成。

最后就是可控性问题，拉模式，监控系统是主动的一方，可以控制频率；推模式，客户端是主动的一方，如果代码写“挫”了，就会给监控系统造成很大压力。

监控目标动态发现机制

Prometheus 内置了多种服务发现机制，最常见的有四种。

• 基于配置文件的发现机制：这种方式看起来很低端，其实非常常用，因为可以配合配置管理工具一起使用，非常方便。
• 基于 Kubernetes 的发现机制：Kubernetes 中有很多元信息，通过调用 kube-apiserver，可以轻易拿到 Pod、Node、Endpoint 等列表，
• 基于公有云 API 的发现机制：比如要监控公有云上所有的 RDS 服务，一条一条配置比较麻烦，这个时候就可以基于公有云的 OpenAPI 做一个服务发现机制，自动拉取相关账号下所有 RDS 实例列表，大幅降低管理成本。
• 基于注册中心的发现机制：社区里最为常用的是 Consul，典型场景是 PING 监控和 HTTP 监控，把所有目标注册到 Consul 中，然后读取 Consul 生成监控对象列表即可。

基于配置文件的管理方式

Prometheus 的告警规则管理、记录规则管理、抓取配置管理与发送策略管理，全部是基于配置文件的，

Prometheus 默认是单机时序存储，容量有上限，基于配置管理的问题和容量问题，我个人非常建议那些推行 DevOps 的团队来使用，而且是每个团队自己有一套单独的 Prometheus，互不干扰，正所谓“You build it. You Run it. You monitor it. You own it.”

当然，这样也会带来问题，最典型的是数据孤岛问题，不过我们可以把各个 Prometheus 中的核心关键指标抽取到一个统一的地方来呈现，比如使用 Prometheus 联邦机制，只共享核心指标，其余指标不需要抽取到中心，自己团队消化就好。

灵活的查询语言

PromQL（Prometheus Query Language）是 Prometheus 的查询语言，非常灵活。这也是 Prometheus 的一个关键设计。

采集侧是无法穷举所有计算场景的，采集侧应该采集原始数据，后续的二次计算还是应该放到中心来搞定。

比如机器的内存指标，我们可以从 cat /proc/meminfo 中看到很多内存相关的监控指标，采集器可以轻易拿到 MemAvailable 和 MemTotal 这样的字段，但是操作系统不会直接暴露内存可用率，此时就需要使用 PromQL：MemAvailable / MemTotal * 100 做二次计算了。

有一些监控数据的采集，是完全由用户配置出来的，比如 SNMP 数据采集，采集哪些 OID 是用户配置的；JMX 数据采集，采集哪些 MBean、哪些 Pattern 也是用户配置的。监控采集器压根就不知道这些数据的具体语义，只有配置采集规则的人知道，这种情况更不可能自动计算，采集器只能采集原始数据，如果有二次计算的需求，最好是设计到服务端，让服务端来做。

小结

• Prometheus 非常注重标准制定和生态建设，而且标准很稳定，没有变来变去，社区有很多人参与其中，共建整套生态。Prometheus 不期望解决所有问题，但是影响力巨大，就是因为标准和生态的强大。
• Prometheus 主要使用拉模式，辅以推模式。我们比较了推拉两种模式，简单来看，拉模式便于解耦，推模式则更简单。中间件监控适合拉模式，自研模块适合推模式。当然，如果注册中心完备，服务都接入了注册中心，服务监控的数据采集也可以使用拉模式。
• 拉模式更需要监控目标动态发现机制，主要使用拉模型的 Prometheus 内置了多种发现机制，最常用的是基于配置文件、Kubernetes、公有云 API、Consul 四种发现机制。
• Prometheus 的配置管理非常简单，直接使用 Yaml 文件，很直观，便于推行 laC 管理模式，只是在公司级大规模协同的时候会有些不方便。当然，国内的大部分企业没有践行 IaC，Yaml 配置的方式会相对难搞一些。
• Prometheus 查询语言就是 PromQL，这也是它最后一个关键设计，让采集侧专注采集，服务端提供灵活的计算能力，有些偏传统的企业难以接受这种做法，只想简单过滤指标来配置阈值，很难把 PromQL 的优势发挥出来，非常可惜。

本节的思维导图