基于Prometheus体系的复杂业务系统监控实践

张晓强

中国联通软件研究院济南分院，山东济南，250000

0 引言

相较于主机、容器、中间件等通用性的监控对象，业务系统监控具有更大的挑战性。首先，对于主机、容器、中间件等，Prometheus社区有很多通用指标采集器、监控指标规范等可以借鉴，采集周期多为固定时长，指标数据相对简单、规整。但是业务监控不同：业务指标相对来说较为复杂，不同的业务系统会有不同的指标体系，对于具体的业务指标，需要单独开发指标采集器；告警规则不同，业务指标之间有时会产生一定的关联性，需要关联判断；采集周期不确定，一般分为固定时间点和固定时间周期两种。在长期的业务系统监控实践中，我们根据Prometheus生态体系，结合实际的业务情况，摸索出一套现实可行的业务监控系统[1]。

1 系统架构

系统分为数据采集层、监控与告警组件、用户交互三层（如图1所示）。数据采集层采用自研指标统一采集框架，在Prometheus原有采集功能上扩充指标数据超时及指标基线功能。监控组件采用Prometheus+Alertmanager，Prometheus采用主备部署模式，用于拉取并存储时间序列数据以及计算、配置告警规则，Alertmanager采用三节点集群部署模式，用于进行告警的管理及将告警发送到对应的webhook，在webhook中根据配置的告警策略通过通知中心发送给用户。用户交互层通过自研的钉钉移动端，包含监控视图、运维操作、数据可视化、通知中心等功能[2]。

1.1 指标采集

业务数据采集没有现成的指标采集器可以使用，需要自己去开发。采集器主要分为两种模式，标准模式和自定义采集模式。标准模式将指标数据刷新到缓存中，Prometheus调取接口获取缓存中数据，采集效率高，但数据会有延迟。自定义采集模式为Prometheus调用采集器接口时，采集器才会去业务系统获取对应的指标，并把指标返回给Prometheus，数据延迟低，但采集性能差。在实际的业务监控中，对于及时性要求不高或者获取业务数据时间耗时长的指标，我们采用标准模式以降低Prometheus采集的性能消耗，对于及时性要求很高且指标数量少、数据获取时间短的指标我们采用自定义采集的模式以降低指标数据延迟。Prometheus提供拉取+推送（实际是pushgateway提供中间数据缓存，实际仍为拉取方式）两种采集方式。对于固定周期数据使用拉取方式实现，对于固定时间点（如每月、每周固定时间点产生）或随机产生指标适用于推送方式实现。

Prometheus本身不提供指标基线功能，只要是指标采集器返回的数据照单全收，对于指标缺失是没有感知的。但是对于指标缺失的情况，所有的告警规则计算结果都会为空，这样就会产生一定的风险。对此我们进行了改造，首先在主应用侧维护所有的指标基线，在不同的指标采集器侧维护同步接口，定时从主应用同步所有的指标基线存储到本地Redis中，且为每条指标增加当前时间戳字段表示数据时间，同时对于不同的指标设置不同的超时时间。指标采集器进行Redis中指标取值刷新时，会判断该条指标是否在指标基线中，若存在则赋值并刷新时间戳，否则则忽略。在Prometheus拉取指标时，直接取出Redis中所有的指标进行返回，采集器会判断Redis中指标基线取值是否已超过超时时间，若超过则将指标取值打为-9999.99等特殊数值，在Prometheus中配置告警规则判断是否有-9999.99的取值来判断是否有指标缺失，若存在则告警通知用户[3]。如图2所示。

1.2 指标体系

Prometheus指标分为三部分。①指标名和标签（metric）：在内部存储上指标名也作为名为__name__的特殊标签与其他标签共同唯一标识每条指标；②时间戳（timestamp）：指标数据采集的时间，精确到毫秒；③样本值（value）：表示当前样本的值，folat64类型。

在系统中采用Prometheus默认时序数据库进行指标存储。Prometheus会将所有采集到的样本数据以时间序列（time-series）的方式保存在内存数据库中，并且定时保存到时序库中。时间序列中纵轴为所有的标签，横轴为时间戳，这样所有的标签只需要存储一次，每次采集指标只需要存储时间戳和取值即可，大大地提升了存储性能。

Prometheus支持四种类型的指标，包括Counter（只增不减）、Gauge（可增可减）、Summary（数据集的不同分位数）、Histogram（数据集的不同区间的指标数量）。在实际的业务系统监控中，我们采用Gauge的指标类型，基于其可增加可减少，也可以直接赋值的特性，可以很好地满足业务监控需求。

为了应对业务的复杂程度，指标体系中统一添加了模块和租户标签，以区分不同业务模块的指标。对于所有的指标体系进行统一编码，统一管理，每条指标明细配置唯一ID和CMDB实例名称，告警发生后以便定位具体的告警指标和CMDB实例，方便进行告警分析。指标基线由CMDB统一管理，配置指标无数据告警，保证数据可靠性。

1.3 告警处理

告警规则配置在Consul中，通过Consul Template同步到Prometheus配置文件中，不同的业务模块使用不同的配置文件。告警规则结合业务经验进行配置，一般为固定阈值，对于阈值随时间变化的监控点，需要按照需求定时去刷新Consul中规则配置文件，除了阈值外，还应配置阈值持续时间，即超过阈值多长时间才算告警，避免一些瞬时超过阈值造成误告警或者告警闪断。告警规则分为一般告警及严重告警，不同的告警等级对应不同的告警通知方式以及告警恢复的紧急程度。

Prometheus负责告警规则计算，告警触发后，将告警信息发送到Alertmanager，Alertmanager负责接收Prometheus等发送的告警。Alertmanager具有告警分组、告警静默、告警抑制功能；告警分组是在告警第一次发生后，等待一段时间再进行发送，若在等待期间有同组的告警触发，则会加入分组中一块发送给用户，以防发生告警风暴；告警抑制是告警之间往往有一定的关联程度，具有因果关系的告警不应该重复发送给用户，例如进程停止后往往会造成进程积压，进程状态发生告警后，进程积压不应该再发给用户；告警静默是告警发生后，用户可以手动触发静默，使告警不再发送给用户，给用户足够的解决问题的时间。Alertmanager接收告警后通过配置的告警路由将告警路由到正确的webhook接口，通过自定义webhook接口对告警信息、告警策略进行个性化定制，例如采用不同的告警方式、根据值班表发送给不同的值班人员等[4]。

1.4 用户交互

用户交互采用自研钉钉移动端平台的方式，前台采用React框架，后台采用SpringCloud微服务框架。平台区分多租户，不同租户之间提供租户服务、配置信息、存储资源隔离，保证租户之间互不影响、互不干涉。平台提供多种监控视图，针对不同业务模块、不同监控对象为用户提供多维度多样式的监控视图。同时平台提供相关的运维操作功能及数据展示功能，实现告警、监控、运维操作一体化[5]。

通知中心提供短信通知、钉钉通知及电话外呼功能。针对一般告警，通常只需要进行钉钉通知。钉钉通知分为工作通知、群机器人等方式。在用户权限允许范围内，用户可自行订阅告警通知以及告警通知接收时间等，通知接收后用户可在钉钉平台中进行告警确认、告警静默等操作。对于严重的告警，需要通过电话外呼的形式发送给用户，电话外呼采用逐层上报告警策略，结合值班表会对值班人员进行多次通知，若用户没有响应，则会向上反映，直到告警接收为止，确保严重告警发生后，保证值班人员能够接收到告警信息。对于可预见性的告警提供生产联动功能，在正常生产操作发生时静默告警点，防止产生误告警。

2 业务流程监控

在系统建设过程中，指标接入工作一直以监控点作为单位进行，对于系统中一些关键的业务流程是否覆盖全面、是否能够有效地监控无法进行有效的分析。为了增加监控系统的可靠性、全面性，针对关键的业务流程进行重点监控，我们引入了业务流程监控。使用CMDB和图数据库，构建业务流程图，每个节点对应一部分实际存在的进程、数据库、中间件、主机、容器等组件，针对具体的实例节点定制监控点规范、稽核实例节点是否监控全面、是否监控有效。同时针对具体的应用构建应用拓扑，告警发生时，根据业务拓扑分析告警产生的根本原因或产生的范围影响[6]。

3 结论与展望

业务监控复杂程度高，对于一些业务指标设置固定的告警规则会造成很多的误告警，需要结合AiOps技术实现单指标阈值监控及多指标阈值自动判断。平台缺乏监控自助接入功能，目前监控接入依赖维护人员人工配置，效率低。同时，当前告警处理自动化程度低，无法实现告警自动恢复、处理等功能。平台接入指标后，缺乏可靠的告警全面性、有效性分析标准，对于缺失的监控无法有效识别。在后续建设工作中，需要扩充告警分析模块，对产生的告警进行影响范围分析、根因分析、智能告警收敛等，进一步提升告警的价值，减少业务人员处理的告警数量；完善告警自助接入功能，将接入功能全面下放；对接告警自动及手动处理模块，实现告警闭环，同时建立完善的有效性、全面性分析机制，进一步提升监控系统可用性、可靠性。