关于监控:极客星球-业务监控及告警系统体系化建设之路

监控零碎体系化建设背景及现状

监控零碎对于业务零碎的重要性显而易见，但该如何抉择监控零碎，以及如何实现系统监控和告警的性能，始终是监控零碎中的两大难题。本文就来解密一下数据智能企业在监控零碎上的解决和倡议，和大家一起探讨。

常见业务监控零碎通常先实现操作系统层面的监控，目前这部分技术已绝对成熟，继而再扩大出其它监控，如：Zabbix、小米 Open-Falcon。当然也有同时反对两者的监控零碎，如 Prometheus。若对业务监控要求较高，倡议开发者们在选型中优先思考 Prometheus。

下图为截至 2022 年 5 月，谷歌提供监控零碎应用状况散布：

开源监控报警零碎——Prometheus

Prometheus（普罗米修斯）是由 SoundCloud 开发的开源监控报警零碎和工夫序列数据库（TSDB），它是一个监控采集与数据存储框架（监控服务器端），反对多种 exporter 采集指标数据，并反对 PushGateway 进行数据上报，性能足够撑持上万台规模的集群，相较于其它监控零碎应用的 push 数据的形式，Prometheus 则应用的是 pull 的形式。

1、基本原理：

Prometheus 基本原理是通过 HTTP 协定周期性抓取被监控组件的状态。这样做的益处是，任意组件只有提供 HTTP 接口就能够接入监控零碎，不须要任何 SDK 或者其余的集成过程，这样做非常适合虚拟化环境，如：VM、Docker。Prometheus 是为数不多同时适宜 Docker、Mesos、Kubernetes 环境的监控零碎之一。

2、Exporter：

输入被监控组件信息的 HTTP 接口被称为 exporter。目前互联网公司罕用的组件大部分都有能够间接应用的 exporter，如：Varnish、Haproxy、Nginx、MySQL、Linux 零碎信息 (包含磁盘、内存、CPU、网络等等)。具体采集的数据类型依赖于 Exporter（监控客户端），例如采集 MySQL 的数据须要应用 mysql_exporter。当 Prometheus 调用 mysql_expoter 采集到 MySQL 的监控指标之后，把采集数据寄存到 Prometheus 所在服务器的磁盘数据文件中。它的各个组件根本都是用 Golang 编写的，对编译和部署非常敌对，并且没有非凡依赖，根本都是独立工作。
Exporter 品种如下：

• 官网 Exporter 地址：https://github.com/prometheus；
• node_exporter：Linux 类操作系统相干数据的采集程序；
• jmx_exporter：Java 过程指标采集程序；
• mysqld_exporter：MySQLserver 数据采集程序；
• redis_exporter：Redis 数据采集程序

3、Prometheus 架构：

1）Prometheus Server

次要负责数据采集和存储，提供 PromQL 查询语言的反对。Server 通过配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等形式指定抓取指标。依据这些指标，Server 定时去抓取 metrics 数据，每个抓取指标须要裸露一个 http 服务的接口用于 Prometheus 定时抓取。这种调用被监控对象获取监控数据的形式被称为 Pull。Pull 形式体现了 Prometheus 独特的设计哲学，这一点与大多数采纳 Push 形式的监控零碎不同。

2）PushGateway

Prometheus 反对临时性 Job 被动推送指标的两头网关。某些现有零碎是通过 Push 形式实现的，为了接入这个零碎，Prometheus 提供对 PushGateway 的反对。这些零碎被动推送 metrics 到 PushGateway，而 Prometheus 只是定时去 Gateway 上抓取数据。

3）AlertManager

AlertManager 是独立于 Prometheus 的一个组件，能够反对 Prometheus 的查问语句，并在触发了事后设置在 Prometheus 中的高级规定后，Prometheus 便会推送告警信息到 AlertManager。

4）Exporter

Exporter Exporter 是 Prometheus 的一类数据采集组件的总称。它负责从指标处收集数据，并将其转化为 Prometheus 反对的格局。与传统的数据采集组件不同，它并不向地方服务器发送数据，而是期待地方服务器被动前来抓取。Prometheus 提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前反对的有数据库、硬件、消息中间件、存储系统、HTTP 服务器、JMX 等。

5）HTTP API

这是一种查问形式，能够自定义所须要的输入。

6）Prometheus 反对两种存储形式

第一种是本地存储，通过 Prometheus 自带的时序数据库将数据保留到本地磁盘，为了性能思考，倡议应用 SSD。但本地存储的容量毕竟无限，倡议不要保留超过一个月的数据。
另一种是近程存储，实用于存储大量监控数据。通过中间层适配器的转化，目前 Prometheus 反对 OpenTSDB、InfluxDB、Elasticsearch 等后端存储。通过适配器实现 Prometheus 存储的 remote write 和 remote read 接口，便能够接入 Prometheus 作为远端存储应用。

7）Prometheus 外围价值

• 系统监控：次要是跟进操作系统的根本监控我的项目，如 CPU、内存硬盘、IO、TCP 连贯、进出口流量；
• 程序监控：个别须要和开发人员配合，在程序中被动上报各种获取到的数据或者特定的日志格局；
• 业务监控：能够蕴含用户拜访 QPS、DAU 日活、拜访状态 (Http code)、业务接口 (登入、注册、聊天、上传、留言、短信、搜寻)

开源剖析监督平台——Grafana

1、根本简介

Grafana 是一套开源的剖析监督平台，反对 Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 等数据源，其 UI 十分丑陋且高度定制化，抉择 Prometheus + Grafana 的计划，能够满足大部分中小团队的监控需要。

增加完数据源后，可依据理论需要，增加自定义的仪表盘和视图组件。

2、五步上手集成 springboot 我的项目

第一步 新建 springboot 我的项目，依赖如下：
<dependencies>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <scope>runtime</scope>
</dependency>

</dependencies>

springboot 配置文件：

Actuator Web 拜访端口

management.server.port=8081
management.endpoints.jmx.exposure.include=*
management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=always

management.endpoint.prometheus.enable=true
management.metrics.export.prometheus.enable=true

第二步 启动服务，浏览器查看服务
http://ip:8081/actuator/prome…

HELP process_start_time_seconds Start time of the process since unix epoch.

TYPE process_start_time_seconds gauge

process_start_time_seconds{application=”springboot-prometheus”,} 1.652688867103E9

HELP system_cpu_usage The “recent cpu usage” for the whole system

TYPE system_cpu_usage gauge

system_cpu_usage{application=”springboot-prometheus”,} 1.0

HELP tomcat_sessions_active_current_sessions

TYPE tomcat_sessions_active_current_sessions gauge

tomcat_sessions_active_current_sessions{application=”springboot-prometheus”,} 0.0

HELP jvm_gc_live_data_size_bytes Size of old generation memory pool after a full GC

TYPE jvm_gc_live_data_size_bytes gauge

jvm_gc_live_data_size_bytes{application=”springboot-prometheus”,} 0.0

HELP logback_events_total Number of error level events that made it to the logs

TYPE logback_events_total counter

logback_events_total{application=”springboot-prometheus”,level=”info”,} 16.0

HELP jvm_classes_unloaded_classes_total The total number of classes unloaded since the Java virtual machine has started execution

TYPE jvm_classes_unloaded_classes_total counter

HELP tomcat_sessions_rejected_sessions_total

TYPE tomcat_sessions_rejected_sessions_total counter

tomcat_sessions_rejected_sessions_total{application=”springboot-prometheus”,} 0.0

以上数据为 Prometheus 收集的数据格式，蕴含指标及数据。

第三步 将下面的利用接口作为 job 接入 Prometheus，批改 Prometheus 的 /prometheus.yml

第四步 重启 prometheus
systemctl restart prometheus，此时 prometheus 的 targets 中便会减少一个

以上便是咱们提供给 Prometheus 默认收集的指标，咱们能够基于这些指标通过 PromQL 查问，查问后果在 Grafana 中做展现。

第五步 为不便展现，咱们在 Grafana 中增加面板，保留即可展现到咱们的仪表盘中。

同时，Grafana 中增加 JVM 模板。Grafana 官网提供了很多模板，咱们只需输出模板编号，即可实现仪表盘的配置。
更多模板请见：https://grafana.com/grafana/d…

JVM 相干的罕用指标监控，到此便配置实现，以上配置也能够依据理论状况，调整每个模块的展现信息。

3、配置告警告诉

1）告警告诉模块

到这一阶段，咱们曾经可能通过 Grafana 展现收集并查看数据。想一想，零碎还缺失什么性能？监控最重要的目标是，判断监控零碎是否失常，并在零碎不失常时，告知相干人员及时排查和解除问题，即告警告诉。因而，还短少一个无关告警告诉的模块。prometheus 的告警机制由以下两局部组成：

• 告警规定

prometheus 会依据告警规定 rule_files，将告警发送给 Alertmanager。

• 治理告警和告诉

该模块是 Alertmanager，它负责管理告警、去除反复数据、告警告诉。告诉形式有多种抉择，如 Email、HipChat、Slack、WebHook 等等。

实际操作为：新创建一个规定文件 alert_rules.yml
groups:

• name: example
  rules:

  Alert for any instance that is unreachable for >5 minutes.

  • alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
    severity: page
    instance: 127.0.0.1:8081
    annotations:
    summary: “Instance {{$labels.instance}} down”
    description: “{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes.”

以上代码的粗心是创立了 1 条 alert 规定——InstanceDown。
InstanceDown 就是实例宕机（up == 0）触发告警，5 分钟后告警（for：5m）。

• alert：告警规定的名称。
• expr：基于 PromQL 表达式告警触发条件，用于计算是否有工夫序列满足该条件。
• for：评估等待时间，可选参数。用于示意只有当触发条件继续一段时间后才发送告警。在期待期间新产生告警的状态为 pending。
• labels：自定义标签，容许用户指定要附加到告警上的一组附加标签。
• annotations：用于指定一组附加信息，比方用于形容告警详细信息的文字等，annotations 的内容在告警产生时会一起作为参数发送到 Alertmanager。
• summary 形容告警的概要信息，description 用于形容告警的详细信息。
• Alertmanager 的 UI 也会依据以上两个标签值，显示告警信息。

向 promethues.yml 增加告警规定：

重启 promethues 即可在 Alerts 中看到咱们定义的告警规定：

• 状态阐明：Prometheus Alert 告警状态有三种状态，包含 Inactive、Pending、Firing；
• Inactive：非活动状态，示意正在监控，然而还未有任何警报触发；
• Pending：示意这个警报必须被触发。因为警报能够被分组、压抑 / 克制或静默 / 静音，所以要期待验证，一旦所有的验证都通过，则转到 Firing 状态；
• Firing：将警报发送到 AlertManager，它将依照配置将警报发送给所有接收者。一旦警报解除，则转到 Inactive 状态，如此循环

模仿服务宕机：kill 过程

此时满足条件 up == 0，State 变成为 PENDING

当工夫超过评估等待时间 5m 后（for：5m），State 变成 FIRING，此时会产生告警。并发送给 Alertmanager 解决。

2）告警告诉模块

在下面咱们能够看到 alerts 页面的告警信息，然而怎么把告警信息告诉到研发和业务相干人员呢？这一操作须要由 Alertmanager 实现。
咱们先配置 alertmanager 文件 alertmanager.yml
global:
resolve_timeout: 5m
smtp_smarthost: ‘smtp.exmail.qq.com:25’ # 应用 qq 邮箱服务器发邮件
smtp_from: ‘iid_robot@xxx.com’ # 发件人，填写你的 qq 邮箱
smtp_auth_username: ‘iid_robot@xxx.com’ # 与下面保持一致
smtp_auth_password: ‘password’ # 你 qq 邮箱的受权码
smtp_require_tls: false # 不应用加密认证

route:
group_by: [‘example’] #与 promethues 配置文件 alert_rule.yml 中配置规定名对应
group_wait: 30s #报警等待时间
group_interval: 10m #报警间隔时间
repeat_interval: 20m #报警反复工夫距离
receiver: ’email’ #告警解决形式
receivers:

• name: ’email’
  email_configs:

  • to: ‘595467072@qq.com’

html: ‘{{template “email.to.html” .}}’

  send_resolved: true   # 故障复原后发送邮件 

inhibit_rules: # 告警克制规定

• source_match:
  serverity: ‘critical’
  target_match:
  serverity: ‘warning’
  equal: [‘alertname’,’dev’,’instance’]

alertmanager 收到告警告诉后，会依据以后配置的形式，如邮件等，发送告警信息：

当咱们服务重启，问题被修复时，也会收到一封邮件告知。若不想收到该邮件，可在 alertmanager.yml 配置：receivers.email_configs.send_resolved：false 即可

Prometheus 及 Grafana 比照剖析

1、Prometheus 优缺点剖析：

监控数据基于工夫序列存储数据库，便于实现数据聚合。各个组件有成熟的高可用计划，没有单点故障、不依赖分布式存储、单个服务器节点可间接工作。其应用的是 PromSQL，这是一种灵便的查询语言，可利用多维数据实现简单的查问。同时反对多种多样的图表和界面展现，个别和 Grafana 配合应用。

Prometheus 是基于指标（Metric）的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。它更多得展现趋势性监控，而非精准数据；Prometheus 认为只有最近的监控数据才有查问的须要，其本地存储的设计初衷只是保留短期（例如一个月）的数据，因此不反对针对大量历史数据的存储。若须要存储长期的历史数据，倡议基于远端存储机制将数据保留于 InfluxDB 或 OpenTSDB 等零碎中。

另外，alertmanager 的匹配规定配置很简单，是在 prometheus 的时序数据库的根底上做二次定制。这也意味着如果中途更换数据库，那么之前的配置须要从新调整。这一点对于前期配置开发十分不利，尤其其键值还依赖 exporter 的 metrics 信息，从编码的角度而言，这里短少接口的封装，对于程序的可维护性而言是一大挑战。

2、Grafana 优缺点剖析：

Grafana 的可用性很高，图表插件十分多，齐全能够依据本人的需要进行选用，并且社区上传了大量 Dashboard 可供使用，因而其劣势与其余组件相似，都是开源、开箱即用等。
但其社区奉献也带来了同 exporter 一样的问题，首先是 Dashboard 和 exporter 的匹配度广泛不高，下载之后须要破费大量工夫进行二次调整。除此之外，接入的 api 也不敌对，例如接入 prometheus，其接入 api 即为 prometheus 的时序数据库的查问语句，因为操作者对其不相熟，也须要大量工夫进行了解。最初就是短少列表信息的内容，社区的 Dashboard 次要由各种图表形成，能够满足整体剖析的需要，然而在问题定位时就显得力不从心了。

综合来看，Prometheus 和 Grafana 组合基本上是目前支流监控零碎的标配，Prometheus 做存储后端，而 Grafana 负责剖析及可视化界面，是一个省时省力，效率最高的计划，简直能满足大部分企业对于零碎和业务的监控需要。当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的了解也不同，也有比拟好的开源的监控框架如 Sensu 等，再加上 influxdb、grafana 能够用来定制合乎本人企业的监控平台。最重要的是，咱们须要留神，监控是须要站在公司的业务角度去思考，而不是针对某个监控技术的应用。