Prometheus技术系列文章——prometheus调研总结

prometheus调研总结

文章目录

Prometheus技术系列文章——prometheus调研总结
前言
1. Prometheus介绍
2. Prometheus特点
3. Prometheus架构图
- 3.1. 基本原理
- 3.2. 工作流程
- 3.3. 组件
- - 3.3.1. pushgateway
  - - 3.3.1.1. pushgateway存在的意义
    - 3.3.1.2. pushgateway缺点
  - 3.3.2. prometheus server
  - 3.3.3. grafana
  - 3.3.4. alert manager
4. 安装Prometheus Server
- 4.1. docker方式安装
- 4.2. 下载二进制包直接运行
5. 安装Node Exporter采集主机数据
6. 配置grafana可视化监控平台
- 6.1. 安装部署grafana
7. 配置部署AlertManager
8. PromQL
- 8.1. 聚合操作
- 8.2. 内置函数
- 8.3. 偏移查询
- 8.4. 指标类型
- 8.5. 基础查询
- 8.6. 范围查询
- 8.7. 操作符
9. prometheus功能列表
10. prometheus与open-falcon的功能对比
11. prometheus采用Pull模式好处是什么？
12. 为什么alertmanager没有Openfalcon方便?
- 1. 分组
- 2. 抑制
- 3. 静默
总结

前言

本文主要是对prometheus的调研总结

1. Prometheus介绍

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。
2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。
Prometheus目前在开源社区相当活跃。
Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。

2. Prometheus特点

多维度数据模型。
灵活的查询语言。
不依赖分布式存储，单个服务器节点是自主的。
通过基于HTTP的pull方式采集时序数据。
可以通过中间网关进行时序列数据推送。
通过服务发现或者静态配置来发现目标服务对象。
支持多种多样的图表和界面展示，比如Grafana等。

3. Prometheus架构图

3.1. 基本原理

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

3.2. 工作流程

指标采集： prometheus server 通过pull 形式采集监控指标，可以直接拉取监控指标，也可以通过pushgateway做中间环节，监控目标先push形式上报数据到pushgateway
指标处理： prometheus server 将采集的数据存储在自身db或者第三方db
指标展示： prometheus server 通过提供http接口，提供自带或者第三方展示系统
指标告警： prometheus server 通过push告警信息到alert-manager，alert-manager通过静默-抑制-整合-下发 4个阶段处理通知到观察者

3.3. 组件

3.3.1. pushgateway

可选，数据采集的中间系统，监控目标先将指标上报到pushgateway，prometheus再通过pull方式采集监控数据

监控目标通过脚本或者其他程序push指标到pushgateway中，prometheus通过pull方式拉取pushgateway上的指标

3.3.1.1. pushgateway存在的意义

prometheus以pull形式采集监控指标，这样存在2个问题：

每次新增监控目标，就需要修改prometheus的配置文件
如果监控目标所在网络和prometheus所在网络不通，就无法通过prometheus的pull形式采集指标

3.3.1.2. pushgateway缺点

pushgateway存在单点问题，如果pushgateway出现故障，所有监控目标都将监控失败。当然可以借助lsb解决单点问题https://github.com/prometheus/pushgateway/issues/241
丢失了prometheus对实例健康状态检查功能
取消监控一个服务，需要手动删除pushgateway上对应的持久化数据

3.3.2. prometheus server

prometheus服务器实例

3.3.3. grafana

可选，当然也是建议采用，第三方展示工具，可以编写PromQL查询语句，通过http协议与prometheus集成

3.3.4. alert manager

prometheus的alerting 模块，负责接收告警，例如prometheus server发送的告警信息，并且提供分组、静默、抑制、下发等功能

分组
将告警消息分组，便于大量告警涌入时带来通知过多问题
静默
按照一定规则，在一定时间内不进行通知下发，在时间阈值达到后，进行下发
抑制
一个告警消息被另一种告警消息抑制，另一种告警发送后，该告警不下发管理API
管理API

HTTP_METHOD	PATH	DESCRIPTION
GET	/-/healthy	Returns 200 whenever the Alert manager is healthy.
GET	/-/ready	Returns 200 whenever the Alert manager is ready to serve traffic.
GET	/-/reload	triggers a reload of the Alertmanager configuration file.

4. 安装Prometheus Server

4.1. docker方式安装

参考这篇文档

linux部署docker以及常用容器部署

4.2. 下载二进制包直接运行

具体安装方式参考我的这篇文章
Prometheus技术系列文章——下载二进制包方式部署Prometheus以及相关组件

5. 安装Node Exporter采集主机数据

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据。
从上面的描述中可以看出Exporter可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外，也可以是直接内置在监控目标中。只要能够向Prometheus提供标准格式的监控样本数据即可。
这里为了能够采集到主机的运行指标如CPU, 内存，磁盘等信息。我们可以使用Node Exporter

Node Exporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。

具体安装方式参考我的这篇文章
Prometheus技术系列文章——下载二进制包方式部署Prometheus以及相关组件

6. 配置grafana可视化监控平台

6.1. 安装部署grafana

参考如下文档
linux部署docker以及常用容器部署

效果展示如下

7. 配置部署AlertManager

部署之前先定义告警规则参考我的这篇文章
prometheus自定义告警规则解析和配置

部署参看我的这篇文章

Prometheus技术系列文章——下载二进制包方式部署Prometheus以及相关组件

结果如下

8. PromQL

8.1. 聚合操作

求和
sum()
最小值
min()
最大值
max()
平均数
avg()
计数
count()
对value进行计数
count_values()
样本值最大的k个元素
topk()
标准差
stddev()
样本值最小的k个元素
stdvar、bottomk()
分布统计
quantile()

8.2. 内置函数

abs()、absent()、ceil()、changes()、clamp_max()、clamp_min()、day_of_month()、day_of_week()、days_in_month()、hour()、time()、minute()、delta()、deriv()、exp()、floor()、histogram_quantile()、holtwinters()

idelta()、increase()、irate()、rate()、label_join()、label_replace()、In()、log2()、log10()、predict_linear()、resets()、round()、scalar()、sort()、sort_desc()、sqrt()、vector()、_over_time()

8.3. 偏移查询

http_requests_total offset 5m 等价于 http_requests_total{job=“prometheus”}[5m]

8.4. 指标类型

Counter

Gauge

Histogram

Summary

8.5. 基础查询

输入指标即可，{}选择器输入属性信息

http_requests_total{job = “prometheus”,group=“canary”}

8.6. 范围查询

时间选择器http_request_total{}[5m]

8.7. 操作符

布尔运算、加减乘数等、优先级

9. prometheus功能列表

以下表格是prometheus功能模块列表

序号	产品模块	功能模块	功能项	备注	模块功能图/举例
1	数据服务
2		监控数据服务
3			侵入式埋点监控（直接采集）
4				通过在客户端集成，如果Kubernetes API直接通过引入Prometheus go client，提供/metrics接口查询kubernetes API各种指标；这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
5			Exporters间接采集
				间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。
6				社区提供的Prometheus社区提供了丰富的Exporter实现，涵盖了从基础设施，中间件以及网络等各个方面的监控功能。这些Exporter可以实现大部分通用的监控需求。
7			PushGateway
8				由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
9	报警服务
10		告警规则服务
11			告警名称
12				用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
13			告警规则
14				告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警
15			AlertManager
16				Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。
17			分组
18				分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。	例如，当集群中有数百个正在运行的服务实例，并且为每一个实例设置了告警规则。假如此时发生了网络故障，可能导致大量的服务实例无法连接到数据库，结果就会有数百个告警被发送到Alertmanager。而作为用户，可能只希望能够在一个通知中中就能查看哪些服务实例收到影响。这时可以按照服务所在集群或者告警名称对告警进行分组，而将这些告警内聚在一起成为一个通知。
19			抑制
20				抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制	例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。
21			静默
22				静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。	静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。

10. prometheus与open-falcon的功能对比

产品功能项/产品	prometheus	open-falcon	个人总结
产品架构图
监控数据获取	1、通过HTTP接口的方式从各种客户端获取数据，这些客户端必须符合Prometheus监控数据格式 2、通过Pull的方式从PushGateway中获取到监控数据。	1、falcon-agent60S往transfer里面推一次 2、手动通过push接口按照固定格式push数据到falcon-agent然后agent会以极快的速度传到transfer	prometheus和open-falcon对于监控数据获取的模块，我觉得最直观的感受是推和拉的区别 open-falcon通过falcon-agent与transfer建立的60S一次TCP长连接把监控数据推上去。 prometheus是通过Prometheus Server通过HTTP接口的方式从各种客户端获取数据，这些客户端必须符合Prometheus监控数据格式
报警服务	1、通过自定义的rules规则进行报警控制 2、报警通知采用组件alertmanager 3、报警接收是以一种固定的方式为单位例如一个邮箱，一个钉钉号这种具体的值通过receiver和alert对应进行报警通知	1、通过exprisssion全局自定义配置报警或者通过templates模板与hostgroups绑定的策略进行报警 2、报警通知采用alarm模块的方式、服务可以进行接入例如、mail-provider邮件报警服务 3、报警接收不是一个具体的值是一个teams组，这个组里面可以有很多profiles，每个Profiles可以有邮箱地址、短信地址等等信息	对于报警接收而言open-falcon的方式要更合适更易扩展对于报警策略而言open-falcon的报警策略有缺陷仍然是在open-falcon总结篇章提到的问题，由于HostGroup是一个扁平结构使用起来可能会有不同机器压力策略不一样放在一个分组用父子模板策略配置覆盖之后这台机器的judge组件，监听在6080端口，我们需要把judge的所有机器放到一个HostGroup，为其配置端口监控问题是，如果judge扩容5台机器，这5台机器就要分别加到上面四个分组里相比之下prometheus的报警方式完全依赖于alertmanager组件反倒不会有这种hostgrooup与templates模板绑定报警产生的这种问题，独有的PromQL查询出来数据达到报警规则之后会像alertmaneger发送告警信息

11. prometheus采用Pull模式好处是什么？

如果监控目标宕了可以更容易发现
可以通过web浏览器手动访问监控目标并检查其健康状况
推送模式会要求更多的配置，因为服务器要知道被控端，被控端还要知道服务器。拉取模式不但需要的配置量更少，而且配置更灵活。当被控端点移动以后，不需要重新配置被控端。
推送模式更容易导致DDos情况发生，相比而言拉取模式风险更低一些。

总结：
Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建监控系统。对于一些复杂的情况，还可以使用Prometheus服务发现(Service Discovery)的能力动态管理监控目标。它不执行检查脚本，而仅仅通过网络收集被控目标的时序数据。对每个被控目标，Prometheus服务器简单地通过HTTP（高并发，使用goroutines）收取所有指标的当前状态，没有任何其他的运行负荷。

但是，pull模式也有相应的弊端，server和被控端的网络不可达，但是prometheus针对这种问题推出了变通的pushgateway模式，这主要是TCP网络操作的困难性导致的。

PS: 一些信息来源于官方手册和网上博客，这些信息是我进行了归纳总结之后整理而成。

12. 为什么alertmanager没有Openfalcon方便?

首先open-falcon是一套完整的开源监控平台，prometheus更多的是以组件化的方式通过例如alertmanager和grafana这种组件来实现监控预警的相应机制。

其次alertmanager采用的报警策略分为以下几个方面

1. 分组

分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。

2. 抑制

抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制

3. 静默

静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。

而它的报警通知是直接由alertmanger模块下的alertmanager.yml配置文件进行配置如下图1-1所示

图1-1 配置文件图

通过global全局配置邮箱等等报警通知服务信息然后route路由分发到receivers -name对应的组然后-name下在配置对应的发送方式，这个时候如果要控制发送多个用户那么我们只能通过增加-to的用户来进行添加，如下图1-2所示

图1-2 多用户通知配置文件图

这导致在添加报警通知用户的时候极大的不方便，相比之下open-falcon采用报警接收组的报警接收服务就会更边便捷化，如下图1-3所示

图1-3 open-falcon报警接收图
Open-falcon在报警接收模块做的配置不单单是指定一个值或者指定一个人而是一个teams的概念，这个teams我觉得非常好用，可以很方便的拓展报警接收信息、包括老员工离职从teams移除个人的profile信息、或者新员工入职从teams加入个人的profile信息，teams模块如下如图1-4所示。

图1-4 open-falcon teams图
teams模块里可以有很多profile每个profile里面有个人的邮箱、手机、IM、QQ等等信息报警的时候直接根据这些信息进行报警服务，profile如图1-5所示。

图1-5 open-falcon profile图

总结

综上所述是我在部署应用调研这个过程中遇到的或者说在配置的时候直观的感觉到的问题，如果有不对的地方还请进行指正，我会加以修改。如果对你有所帮助的话请点个关注，我会不定时更新技术分享，对于文章中内容有问题的地方可以在下面留言，看到我会及时回复。