PromQL 从⼊⻔到精通 对于 Prometheus 生态的监控系统，PromQL 是必备技能，本文着重点讲解这个查询语言，掺 杂一些生产实践场景，希望对你有所帮助。 ? 本文作者：秦晓辉，Open-Falcon、Nightingale 等开源项目创始人之一，极客时间《运 维监控系统实战笔记》作者；当前在创业（快猫星云联创），为客户提供监控/可观测性产品 方案，有需求的朋友欢迎联系我的微信 数据类型 Prometheus 有四种数据类型：Gauge、Counter、Histogram、Summary，其中最关键的是 Gauge 和 Counter，Histogram 和 Summary 只是为了上报监控数据的 Client 侧的便利，可 以看做是组合使用了 Gauge 和 Counter。所以我们重点就来讲解 Gauge 和 Counter 类型。 Gauge 类型 Gauge 如果实例存活，用 1 表示；再比如内存使用率，这个时刻采集是 33.7%，下个周期采集可能就 变成了 25.8%；还有像机器最近 5 分钟的 load、正在运行的进程数量等等，都使用 Gauge 类 型来表示。这种类型的值，我们非常关注当前值。 Counter 类型 Counter 类型是单调递增的值，比如机器上某块网卡收到的数据包的总量，是从操作系统启动 之后，就持续递增的，对于这种类型的值

Prometheus（Kubernetes 可能有多套，以至于 Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 告警太多的常见原因 最常见的原因，是告警规则设置得不合理。比如很多规则触发了告警之后，实际没有后续动作，只是起到 常态化通知的效果，不需要排查，也不需要止损，甚至连个长线的 TODO 都没有。这类告警多了人就疲 了，当重要的告警来临的时候，也容易忽略。这样的规则如果不经过治理，日积月累，就会产生很多无用 的告警。 第二个常见的原因是底层出问题导致所有的上层依赖都告警，越是底层影响越大，比如基础网络如果出问 层影响越大，比如基础网络如果出问 题，发出几万条告警都是正常的。 第三个原因是渠道错配。一些不重要的告警也使用打扰性很高的渠道发出，用户可能会觉得单一渠道不可 靠，想用多个渠道同时发送的方式来保障告警触达率，这也属于告警规则配置不合理的范畴。 第四个原因是预期内的维护动作导致的。比如程序升级变更，如果进程重启时间过长，可能会导致关联的 服务告警，或者某个机器重启，忘记提前屏蔽了，也会产生一堆关联告警。

入， 稳定性体系一定要重视起来，而监控，就是稳定性体系中至 关重要的一环 运维监控需求来源 01.监控的原始需求来自业务稳定性 左图是2013年的一个新闻，讲 Google宕机的影响。2020年也出现 过aws大规模宕机的情况，影响不 止是55万美元，直接影响大半个 互联网！ 2018年有美国调研机构指出，如 果服务器宕机1分钟，银行会损失 27万美元，制造业会损失42万美 27万美元，制造业会损失42万美 元 美团故障？滴滴故障？腾讯故障？ 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失？尽快发现故障并止损！故障处理过程中，监控是『发现』和『定位』两个环节 的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 组件服务 业务应用 夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 源监控，支持云原生监控，经受了滴滴大规模生产检验 Nightingale 夜莺是新一代国产智能监控平台，既可以解决传统物理机虚拟机的场景，也可以解 决容器的场景。衍生自Open-Falcon和滴滴Odin监控，经受了包括小米、美团、滴滴 在内的数百家企业的生产环境验证，简单可依赖，好用到爆！