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

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

常见业务监控零碎通常先实现操作系统层面的监控，目前这部分技术已绝对成熟，继而再扩大出其它监控，如 ：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能够用来定制合乎本人企业的监控平台。最重要的是，咱们须要留神，监控是须要站在公司的业务角度去思考，而不是针对某个监控技术的应用。