这是我之前在「dbaplus 社群」的分享,已经转载到过「hulk一线技术杂谈」
初衷
最近参与的几个项目,无一例外对监控都有极强的要求,需要对项目中各组件进行详细监控,如服务端API的请求次数,响应时间,到达率,接口错误率,分布式存储中的集群IOPS,节点在线情况,偏移量等。比较常见的方式是写日志,将日志采集到远端进行分析和绘图,或写好本地监控脚本进行数据采集后,通过监控系统客户端push到监控系统中进行打点。基本上我们需要的都能覆盖,但仍然有一些问题在使用上不太舒服,如在大规模请求下日志采集和分析的效率比较难控制或push打点的粒度和维度以及查询不够灵活等。
后来在同事对《Google SRE》这本书中的一些运维思想进行一番安利,抱着试一试的态度,开始尝试使用prometheus做为几个项目的监控解决方案。
prometheus的特点
• 多维数据模型(时序数据由 metric 名和一组 k/v 标签构成)。
• 灵活强大的查询语句(PromQL)。
• 不依赖存储,支持 local 和 remote 不同模型。
• 采用 http 协议,使用 pull 模式采集数据。
• 监控目标,可以采用服务发现或静态配置的方式。
• 支持多种统计数据模型,图形化友好。
数据类型
Counter
- Counter 表示收集的数据是按照某个趋势(增加/减少)一直变化的。
Gauge
- Gauge 表示搜集的数据是一个瞬时的,与时间没有关系,可以任意变高变低。
Histogram
- Histogram 可以理解为直方图,主要用于表示一段时间范围内对数据进行采样,(通常是请求持续时间或响应大小),并能够对其指定区间以及总数进行统计,通常我们用它计算分位数的直方图。
Summary
- Summary和Histogram十分相似,主要用于表示一段时间范围内对数据进行采样,(通常是请求持续时间或响应大小),它直接存储了 quantile 数据,而不是根据统计区间计算出来的。
在我们的使用场景中,大部分监控使用Counter来记录,例如借口请求次数,消息队列数量,重试操作次数等。一小部分使用Gauge,如在线人数,协议流量,包大小等。还有一小部分使用Histogram和Summary,用于统计平均延迟,请求延迟占比和分布律。另外针对Historgram,不论是打点还是查询对服务器的cpu消耗比较高,通过查询时查询结果的返回耗时会有十分直观的感受。
时序数据-打点-查询
我们知道每条时序数据都是由 metric(指标名称),一个或一组label(标签),以及float64的值组成的。
标准格式为 <metric name>{<label name>=<label value>, ...}
例如:
|
|
这是一组用于统计rpc接口处理次数的监控数据
其中rpc_invoke_cnt_c
为指标名称,每条监控数据包含三个标签 code
表示错误码,service
表示该指标所属的服务,method
表示该指标所属的方法.
针对这个例子,我们共有四个维度(一个指标名称,三个标签),这样我们便可以利用prometheus强大的查询语言PromQL进行极为复杂的查询
PromQL
PromQL (Prometheus Query Language) 是 Prometheus 自己开发的数据查询 DSL 语言,语言表现力非常丰富,支持条件查询、操作符、并且内建了大量内置函,供我们针对监控数据的各种维度进行查询。
我们想统计Center组件Relation.GetUserInfo
的频率:
|
|
或者基于方法和错误码统计Center的整体 rpc 请求错误频率:
|
|
如果我们想统计Center各方法的接口耗时:
|
|
另外,配合查询在打点时metric和labal名称的定义也有一定技巧。
比如在我们的项目中:
rpc_invoke_cnt_c
表示rpc调用统计center_api_req_num_cv
表示http api调用统计group_msg_queue_cnt_c
表示对列长度统计
尽可能将使用各服务或者组建通用的名称定义metric然后通过各种lable进行区分。
最开始我们的使用方式是这样的,比如我们有三个组件center
,gateway
,message
。rpc调用统计的metric相应的命名成了三个:
center_rpc_invoke_cnt_c
gateway_rpc_invoke_cnt_c
message_rpc_invoke_cnt_c
这种命名方式,对于个组件的开发同学可能读起来会比较直观,但是在实际查询过程中,这三个metric相当于三个不同的监控项。
例如我们查询基于method统计所有组件rpc请求错误频率,如果我们使用通用名称定义metric名,查询语句是这样的。
‘’sum by (method, code) (rate(rpc_invoke_cnt_c{code!=”0”}[1m]))
但如果我们各个组件各自定义了名称的话,这条查询需要写多条。虽然我们可以通过 {__name__=~".*rpc_invoke_cnt_c"}
的方式来规避这个问题,但在实际使用和操作时体验会差很多。
同时通过前面的各类查询例子也会发现,我们在使用label时也针对不同的意义进行了区分如 method=GroupJoin|GetUserInfo|PreSignGet|...
来区分调用的函数方法 code=0|1|4|1004|...
来区分接口返回值。
更多的metric和label相关的技巧可以参考官方文档[https://prometheus.io/docs/practices/naming/]`
服务发现
在使用初期,参与的几个项目的prometheus都是各自独立部署和维护的。其配置也是按照官方文档中的标准配置来操作。机器数量少的时候维护简单,增删机器之后简单的reload一下即可。例如
但随着服务器量级增长,业务整合到同一组prometheus的时候,每次上下线实例都是一个十分痛苦的过程。所以我们尝试使用了prometheus的服务发现功能。
从配置文档中不难发现prometheus对服务发现进行了大量的支持,例如大家喜闻乐见的consul和k8s
|
|
由于最近参与的几个项目深度使用公司内部的配置管理服务gokeeper,虽然不是prometheus原生支持,但是通过简单适配也是同样能满足服务发现的需求的。我们最终选择file_sd_config
作为服务发现的配置。
file_sd_config
接受json格式的配置文件进行服务发现。每次json文件的内容发生变更,prometheus会自动刷新target列表,不需要手动触发reload操作。所以我们针对gokeeper编写了一个小工具,定时到gokeeper中采集服务分类及分类中的服务器列表,并按照file_sd_config
的要求生成对应的json格式。
下面是一个测试服务生成的json文件样例。
|
|
prometheus配置文件中将file_sd_configs
的路径指向json文件即可。
|
|
高可用
高可用目前暂时没有太好的方案。官方给出的方案可以对数据做shard然后通过federation来实现高可用方案,但是边缘节点和global节点依然是单点。
使用方法比较简单,例如我们一个机房有三个prometheus节点用语shard,我们希望global节点采集归档数据用于绘图。首先需要在shard节点进行一些配置。
prometheus.yml
:
|
|
node_rules/zep.test.rules
:
|
|
在这里job:center_rpc_invoke_cnt:sum:rate:1m
将作为metric名,用来存放查询语句的结果。
在global节点prometheus.yml也需要进行修改。
|
|
在这里我们只采集了聚合数据用于绘图,不建议将shard节点的所有数据采集过来存储再进行查询和报警的操作。这样不但会使shard节点计算和查询的压力增大(通过http读取原始数据会造成大量IO和网络开销),同时所有数据写入global节点也会使其很快达到单prometheus节点的承载能力上限。
另外部分敏感报警尽量不要通过global节点触发,毕竟从shard节点到global节点传输链路的稳定性会影响数据到达的效率,进而导致报警实效降低。例如服务updown状态,api请求异常这类报警我们都放在shard节点进行报警。
此外我们还尝试编写一个实验性质的prometheus proxy工具,代替global节点接收查询请求,然后将查询语句拆解,到各shard节点抓取基础数据,然后再在proxy这里进行prometheus内建的函数和聚合操作,最后将计算数据抛给浏览器。这样便可以直接节约掉global节点和大量存储资源,并且proxy节点由于不需要存储数据,接受请求和计算数据,横向扩展十分方便。当然问题还是有的,由于每次查询proxy到shard节点拉取的都是未经计算的原始数据,当查询的metric数据量比较大的时候,网络和磁盘IO开销巨大。因此在绘图时我们对查询语句限制比较严格,基本不允许进行无label限制的模糊查询。
报警
prometheus的报警功能目前来看相对计较简单。主要是利用alertmanager这个组件。配合rules_file
中编辑的查询出发条件,prometheus会主动通知alertmanager然后发出报警。由于我们公司内使用的自研的qalarm报警系统,接口比较丰富,和alertmanager的webhook简单对接即可使用。alertmanager也内建了一部分报警方式,如email和第三方的slack,初期我们的存储集群报警使用的就是slack,响应速度还是很不错的。
需要注意的是,如果报警已经触发,但是由于一些原因,比如删除业务监控节点,使报警恢复的规则一直不能触发,那么已出发的报警会按照alertmanager配置的周期一直重复发送,要么从后台silence掉,要么想办法使报警恢复。例如前段时间我们缩容ceph集群,操作前没有关闭报警,触发了几个osddown的报警,报警刷新周期2小时,那么没过两小时alertmanager都会发来一组osddown的报警短信。对应编号的osd由于已经删掉已经不能再写入up对应的监控值。索性停掉osddown报警项,直接重启ceph_exporter
,再调用prometheus api删掉对应osd编号的osdupdown监控项,随后在启用osddown报警项才使报警恢复。
如下图的报警详情页面,红色的是已触发的报警,绿色的是未触发报警
绘图展示
对于页面展示,我们使用的是grafana,如下面两张图,是两个不同服务的dashboard,可以做非常多的定制化,同时grafana的template也可以作为参数传到查询语句中,对多维度定制查询提供了极大的便利。