prometheus监控告警

监控告警-Prometheus

第一章：概述

本章将介绍监控告警的一些基本概念。

1.1 什么是监控告警？

• 监控是什么？

  说白了就是用一种形式去盯着、观察服务器，把服务器的各种行为表现都显示出来，用以发现问题和不足。

• 告警是什么？

  监控和告警这两个词需要分开来理解，监控是监控，告警是告警。监控是把行为表现展现出来，用来观察的。告警则是当监控获取的数据发生异常并且达到了某个临界点的时候，采用各种途径来通知用户、管理员、运维人员甚至是老板。

  告警系统中最重要的一个概念之一就是对告警阈值的理解。阈值(Trigger Value)是监控系统中对数据达到某一个临界值的定义。

1.2 监控都有哪些组成部分和流程？

监控本身看的是数据，数据从哪里来？

数据不是凭空从天上掉下来的，也不是研发人员主动给的，只能是从运维数据采集来。

1.3 监控设计

• 评估系统的业务流程、业务种类、架构体系

  各个企业的产品不同，业务方向不同，程序代码不同，系统架构更不同

  对于各个地方的细节都需要有一定程度的认知，才可以开起设计的源头

• 分类出所需的监控项种类

  一般可以分为：业务级别监控/系统级别监控/网络监控/程序代码监控/日志监控/用户行为分析监控/其他种类监控

  • 业务监控： 可以包含用户访问QPS，DAU日活，访问状态，业务接口（登录、注册、上传、聊天、留言、短信、搜索等），产品转化率，充值额度，用户投诉等等这些很宏观的概念
  • 系统监控：主要是跟操作系统相关的基本监控项，CUP/内存/硬盘/IO/TCP连接/流量等等
  • 网络监控：对网络状态的监控（交换机、路由器、防火墙、vpn等，应用更多的是直接对主机的网络监控），互联网公司必不可少，但很多时候又被忽略，如：内网之间（物理内网、逻辑内网、云平台可用区等）、外网、丢包率、延迟等
  • 日志监控：监控中的重头戏，往往单独设计和搭建，全部种类的日志都需要有采集（syslog,soft,网络设备,用户行为）
  • 程序监控：一般需要和开发人员配合，程序中嵌入各种接口，直接获取数据或者特质的日志格式

---

第二章：Prometheus简介

本章将介绍 Prometheus 的特点、架构以及与一些流行监控工具的比较。

2.1 什么是Prometheus？

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community. It is now a standalone open source project and maintained independently of any company. To emphasize this, and to clarify the project's governance structure, Prometheus joined the Cloud Native Computing Foundation in 2016 as the second hosted project, after Kubernetes.

Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合，2018年8月Prometheus正式从CNCF毕业，预示着Prometheus将走入企业，支撑着大大小小的公司，帮助他们完成新一代监控系统的过渡。

2.2 Prometheus的特点

• 多维数据模型（时序由 metric 名字和 k/v 的 labels 构成）。
• 灵活的查询语句（PromQL）。
• 无依赖分布式存储，支持 local 和 remote 不同模型，单个服务器节点是自主的。
• 通过基于http协议的pull方式采集时序数据，简单易懂。
• 可以通过中间网关进行时序数据推送。
• 可以通过服务发现或静态配置的方式来发现目标服务对象。
• 支持多种统计数据模型，图形化友好。

2.3 Prometheus组织架构

2.3.1 基本原理

Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。

2.3.2 核心组件

2.3.2.1 Prometheus server

• Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。

• Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。

• Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。

2.3.2.2 Exporters

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

• 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。

• 间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

2.3.2.3 AlertManager

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。

2.3.2.4 PushGateway

由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。

Pushgateway 是 Prometheus 生态中一个重要工具，使用它的原因主要是：

• Prometheus 采用 pull 模式，可能由于不在一个子网或者防火墙原因，导致 Prometheus 无法直接拉取各个 target 数据。
• 在监控业务数据的时候，需要将不同数据汇总, 由 Prometheus统一收集。

由于以上原因，不得不使用 pushgateway，但在使用之前，有必要了解一下它的一些弊端：

• 将多个节点数据汇总到 pushgateway, 如果 pushgateway 挂了，受影响比多个 target 大。
• Prometheus 拉取状态 up 只针对 pushgateway, 无法做到对每个节点有效。
• Pushgateway 可以持久化推送给它的所有监控数据。

因此，即使你的监控已经下线，prometheus 还会拉取到旧的监控数据，需要手动清理 pushgateway 不要的数据。

2.3.2.5 Service Discovery

服务发现在Prometheus中是特别重要的一个部分，基于Pull模型的抓取方式，需要在Prometheus中配置大量的抓取节点信息才可以进行数据收集。有了服务发现后，用户通过服务发现和注册的工具对成百上千的节点进行服务注册，并最终将注册中心的地址配置在Prometheus的配置文件中，大大简化了配置文件的复杂程度， 也可以更好的管理各种服务。

• 在众多云平台中（AWS,OpenStack），Prometheus可以 通过平台自身的API直接自动发现运行于平台上的各种服务，并抓取他们的信息

• Kubernetes掌握并管理着所有的容器以及服务信息，那此时Prometheus只需要与Kubernetes打交道就可以找到所有需要监控的容器以及服务对象

• Consul（官方推荐）等服务发现注册软件

• 通过DNS进行服务发现

• 通过静态配置文件（在服务节点规模不大的情况下）

2.3.2.6 Storage

Prometheus提供了两种数据持久化方式：一种是本地存储，通过Prometheus自带的TSDB（时序数据库），将数据保存到本地磁盘，为了性能考虑，建议使用SSD。但本地存储的容量毕竟有限，建议不要保存超过一个月的数据。Prometheus本地存储经过多年改进，自Prometheus 2.0后提供的V3版本TSDB性能已经非常高，可以支持单机每秒1000w个指标的收集。

Prometheus本地数据存储能力一直为大家诟病，但Prometheus本地存储设计的初衷就是为了监控数据的查询，Facebook发现85％的查询是针对26小时内的数据。所以Prometheus本地时序数据库的设计更多考虑的是高性能而非分布式大容量。

另一种是远端存储，适用于大量历史监控数据的存储和查询。通过中间层的适配器的转化，Prometheus将数据保存到远端存储。适配器实现Prometheus存储的remote write和remote read接口，并把数据转化为远端存储支持的数据格式。目前，远端存储主要包括OpenTSDB、InfluxDB、Elasticsearch、M3DB等，其中M3DB是目前非常受欢迎的后端存储。

运维方面：

Prometheus has several flags that allow configuring the local storage. The most important ones are:

• --storage.tsdb.path: This determines where Prometheus writes its database. Defaults to data/.
• --storage.tsdb.retention.time: This determines when to remove old data. Defaults to 15d. Overrides storage.tsdb.retention if this flag is set to anything other than default.
• --storage.tsdb.retention.size: [EXPERIMENTAL] This determines the maximum number of bytes that storage blocks can use (note that this does not include the WAL size, which can be substantial). The oldest data will be removed first. Defaults to 0 or disabled. This flag is experimental and can be changed in future releases. Units supported: KB, MB, GB, PB. Ex: "512MB"
• --storage.tsdb.retention: This flag has been deprecated in favour of storage.tsdb.retention.time.
• --storage.tsdb.wal-compression: This flag enables compression of the write-ahead log (WAL). Depending on your data, you can expect the WAL size to be halved with little extra cpu load. Note that if you enable this flag and subsequently downgrade Prometheus to a version below 2.11.0 you will need to delete your WAL as it will be unreadable.

这几个参数是设置本地存储的配置，自行翻译吧。

On average, Prometheus uses only around 1-2 bytes per sample. Thus, to plan the capacity of a Prometheus server, you can use the rough formula:

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

计算Prometheus服务器的容量 ，关于采集时间间隔的设置可以参考文章规划Prometheus的存储用量。

To tune the rate of ingested samples per second, you can either reduce the number of time series you scrape (fewer targets or fewer series per target), or you can increase the scrape interval. However, reducing the number of series is likely more effective, due to compression of samples within a series.

If your local storage becomes corrupted for whatever reason, your best bet is to shut down Prometheus and remove the entire storage directory. Non POSIX compliant filesystems are not supported by Prometheus's local storage, corruptions may happen, without possibility to recover. NFS is only potentially POSIX, most implementations are not. You can try removing individual block directories to resolve the problem, this means losing a time window of around two hours worth of data per block directory. Again, Prometheus's local storage is not meant as durable long-term storage.

If both time and size retention policies are specified, whichever policy triggers first will be used at that instant.

Expired block cleanup happens on a background schedule. It may take up to two hours remove expired blocks. Expired blocks must be fully expired before they are cleaned up.

2.3.3 服务过程

• Prometheus server 定期从静态配置的 targets 或者服务发现的 targets 拉取metrics(指标)数据。

• Prometheus采用PULL的方式进行监控，即服务器可以直接通过目标PULL数据或者间接地通过中间网关来Push数据。 PushGateway支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。

• Prometheus是将采集过来的数据先存放在内存之中的，并通过一定规则进行清理和整理数据，把得到的结果存储到新的时间序列中。当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘（如果使用 remote storage 将持久化到云端）。

• Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。

• Alertmanager 收到警告的时候，会根据配置，聚合，去重，降噪，最后发送警告。

• Prometheus通过PromQL和其他API可视化地展示收集的数据。Prometheus支持很多方式的图表可视化，例如Grafana、自带的Promdash以及自身提供的模版引擎等等。Prometheus还提供HTTP API的查询方式，自定义所需要的输出。

注意：

• Prometheus 的数据是基于时序的 float64 的值，如果你的数据值有更多类型，无法满足。

• Prometheus 不适合做审计计费，因为它的数据是按一定时间采集的，关注的更多是系统的运行瞬时状态以及趋势，即使有少量数据没有采集也能容忍，但是审计计费需要记录每个请求，并且数据长期存储，这个Prometheus 无法满足，可能需要采用专门的审计系统。

2.4 Prometheus的优势

优势和它的特点是分不开的：

• 基于time series时间序列模型（时序由 metric 名字和 k/v 的 labels 构成）

  时间序列(time series (X,Y))是一系列有序的数据，通常是等时间间隔的采样数据。

• 采样数据的查询完全基于数学运算，二不是其他的表达式，并提供专有的查询输入console。

  这个特点很独特，所有查询都基于数学运算公式，如（增量(A)+增量(B)）/ 总增量(C) > 固定百分比，则触发告警。

• 采用http pull/push两种对应的数据采集传输方式

  所有的数据采集都基本采用http的形式，且分为pull/push拉和推两种方式去采集程序，对数据操作很方便。

• 开源，且有大量的社区成品插件

  很多prometheus社区开发的插件已经异常强大和完善，如果对监控要求不是特别高，默认的几个成品插件装上就可以用到底了。监控成型速度快。

• push的方法使用非常灵活

  push的这种采集方法灵活度超乎想象，几乎任何形式的数据都可以实现。

• 本身自带图像调试

  prometheus本身自带了现成的图形成型界面，虽然不能跟grafana的效果相比，但是这种自带图形成图可以方便我们进行调试。

• 最精细的数据采样

  大多数市面上的开源监控采样也就能精确到半分钟、一分钟的程度，商品化监控产品就更别提了，为了缩小数据存储的成本，有的甚至是5分钟作为采样最小间隔。

  prometheus理论上可以达到每秒采集，而且可以自行定制频率，可以自行衡量采样时间和存储成本的平衡。

prometheus一些不足的地方:

• 暂不支持集群。
• 如果集群数量过大，本身监控有性能的瓶颈，如果是集群则可以解决这个问题。
• 偶尔发生数据丢失（2.0之前版本偶尔会发生，2.0之后已解决）。
• 学习成本太大，尤其是独有的数学命令行，各种数学模型概念复杂，中文资料极少。
• 对磁盘资源消耗较大，具体看监控的集群量、监控项的多少和保存时间的长短等。

2.5 Prometheus的适用场景

在选择Prometheus作为监控工具前，要明确它的适用范围，以及不适用的场景。

• Prometheus在记录纯数值时间序列方面表现非常好。它既适用于以服务器为中心的监控，也适用于高动态的面向服务架构的监控。

• 在微服务的监控上，Prometheus对多维度数据采集及查询的支持也是特殊的优势。

• Prometheus更强调可靠性，即使在故障的情况下也能查看系统的统计信息。权衡利弊，以可能丢失少量数据为代价确保整个系统的可用性。因此，它不适用于对数据准确率要求100%的系统，比如实时计费系统（涉及到钱）。

2.6 Why Prometheus?

Zabbix	Prometheus
后端用 C 开发，界面用 PHP 开发，定制化难度很高。	后端用 golang 开发，前端是 Grafana，JSON 编辑即可解决。定制化难度较低。
集群规模上限为 10000 个节点。	支持更大的集群规模，速度也更快。
更适合监控物理机环境。	更适合云环境的监控，对 OpenStack，Kubernetes 有更好的集成。
监控数据存储在关系型数据库内，如 MySQL，很难从现有数据中扩展维度。	监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合。
安装简单，zabbix-server 一个软件包中包括了所有的服务端功能。	安装相对复杂，监控、告警和界面都分属于不同的组件。
图形化界面比较成熟，界面上基本上能完成全部的配置操作。	界面相对较弱，很多配置需要修改配置文件。
发展时间更长，对于很多监控场景，都有现成的解决方案。	2015 年后开始快速发展，但发展时间较短，成熟度不及 Zabbix。

	开发语言	成熟度	扩展性	高性能	社区活跃	容器支持	企业使用	部署维护
Zabbix	C、PHP	高	高	低	中	低	高	中
Open-Falcon	Golang	中	中	高	中	中	中	高
Prometheus	Golang	中	高	高	高	高	高	低

Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。

Open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案。

从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到Go。不得不说，Go凭借简洁的语法和优雅的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。

从系统成熟度上看，Zabbix是老牌的监控系统：Zabbix是在1998年出现的，系统功能比较稳定，成熟度较高。而Prometheus和Open-Falcon都是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。

从系统扩展性方面看，Zabbix和Open-Falcon都可以自定义各种监控脚本，并且Zabbix不仅可以做到主动推送，还可以做到被动拉取，Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。

从数据存储方面来看，Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能，Open-Falcon采用RDD数据存储，并且可以对接到OpenTSDB，而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。

从配置和维护的复杂度上看，Prometheus只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，尤其是Open-Falcon。

从社区活跃度上看，目前Zabbix社区活跃度比较低，Open-Falcon虽然也比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势，社区活跃度最高，并且受到CNCF的支持，后期的发展值得期待。

从容器支持角度看，由于Zabbix出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。Open-Falcon虽然提供了容器的监控，但支持力度有限。Prometheus的动态发现机制，不仅可以支持Swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。伴随着容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。总体来说，对比各种监控系统的优劣，Prometheus可以说是目前监控领域最锋利的“瑞士军刀”了。

总结：

• Prometheus 属于一站式监控告警平台，依赖少，功能齐全。

• Prometheus 支持对云的或容器的监控，其他系统主要对主机监控。

• Prometheus 数据查询语句表现力更强大，内置更强大的统计函数。

• Prometheus 在数据存储扩展性以及持久性上没有 InfluxDB，OpenTSDB，Sensu 好。

参考文档：http://www.sohu.com/a/342733264_198222

---