Prometheus 与 nodata 告警

Prometheus 与 nodata 告警

背景

随着云原生和高动态服务端的发展，在运维领域，以 Prometheus 为代表的现代时间序列存储正在加速替代以 Zabbix 为代表的传统监控系统。运维领域在享受时间序列技术发展红利的同时，也面临时间序列管理思路上的转变和监控系统实际应用的上一些难点 —— nodata 告警便是其中之一。nodata 告警是传统监控系统的必备功能，但却缺席了几乎所有现代时间序列存储实践，这给运维监控带了诸多缺陷。本文尝试分析其中原因，并给出一些可能的解决方法。

nodata 告警触发器的特殊性与必要性

nodata 告警触发器（Trigger）与普通告警触发器相比具有原生的特殊性。普通告警触发器的作用是对一组监控指标（Metric）的过滤，通常是基于数值大小的过滤。

运维监控场景下，发生 nodata 告警最大的可能性是监控系统本身的失效，比如采集点失效或采集对象失效，在我们的实践中，服务器意外下线、磁盘故障、服务崩溃等都会导致 nodata 告警；另外还有一类监控指标，这类指标以 nodata 为『正常状态』，如 5xx code 产生的速率，在没有 5xx code 产生时，虽然我们希望指标的数值为 0 （而不是 nodata） ，但在实践中往往很难保证，对于这类指标有效性的保证，我们会在其他文章中详细说明。

nodata 告警触发器的难点之一在于全集 的获取。在高动态的服务端环境中，往往很难得到『全部服务器集合』、『全部 IP 地址集合』、『全部 Pod 集合』、『某服务全部运行实例集合』这样的全集。所以，在数值型的监控采集之外，必须建设更加结构化的信息组织方式，并配以自动、半自动与人工相结合的信息维护方法。假如在结构化信息中很难方便准确地获取『全部某某集合』这样的信息，就无法制作真正有效地 nodata 告警触发器。

nodata 告警触发器的另一个难点是计算的开销大。普通告警触发器对指标的数值过滤，可以通过『带条件的查询』做到，这本质上是将告警计算的开销一次性卸载到时间序列存储系统中，而现代的时间序列存储系统一般都支持这样做。由上文对 nodata 告警触发器的定义可以得到，nodata 的计算必须在数值过滤之前&#