利用夜莺扩展能力打造全方位监控系统 喻波 滴滴 专家工程师 目 录 运维监控需求来源 01 监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 环节出问题都能及时感知 产品要求 01.端上、链路、资源、组件、应用多维度跨云监控 端上 卡顿 崩溃 链路 连通性 链路质量 服务端 硬件资源 组件服务 业务应用 夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 源监控，支持云原生监控，经受了滴滴大规模生产检验 Nightingale 夜莺是新一代国产智能监控平台，既可以解决传统物理机虚拟机的场景，也可以解 决容器的场景。衍生自Open-Falcon和滴滴Odin监控，经受了包括小米、美团、滴滴 在内的数百家企业的生产环境验证，简单可依赖，好用到爆！ 3500+ 600+ 500+ star issue fork

效得多。 如上，是从思路方法层面，对事件的处理做了逻辑讲解。要求所有的监控系统实现这些能力不太现实，而 且会造成一个一个的事件孤岛，所以典型的做法是把所有监控系统生成的事件统一聚合到一个平台来处 理，这就是 OnCall 中心，下面我们以 FlashDuty 来举例，讲解 OnCall 中心的工具实践。 工具实践篇 称手好用的工具是可以大幅提升效率的，同时，好的工具可以沉淀最佳实践，沉淀经验，假设由你来设计 告警/故障处理 通常，我们并不会基于告警来做协同，更多的是基于故障来做协同。点击某个故障，可以看到故障详情， 会有认领、关闭、合并故障、评论等相关操作，示例图如下： 对于一些大故障，跨多个团队，拉齐信息是非常关键的，如果有某个团队发现了一些线索，可以通过评论 的方式让其他团队快速知悉，新进的故障处理人员也可以通过这些评论以及故障关联的告警快速得知故障 历史信息，快速启动排查工作。

filter数据 精度降低 建议 降低使⽤用成本 agent prometheus target target target alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 获取监控数据 获取监控数据 推送告警 降低使⽤用成本 agent prometheus target target target alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 推送告警 1. 降低编写规则的成本 降低使⽤用成本 agent prometheus target target target alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2

从了。 Prometheus 文档中有一个章节专门介绍函数，各个函数的介绍中，都会写明是用于 instant- vector，还是用于 range-vector，如果不理解查询类型，就无法很好的应用这些函数。 查询选择器 PromQL大括号里的部分是 selector，查询选择器，用于从一大堆监控数据中，过滤出真正关心 的数据，在 Prometheus 生态里，时序数据的标识，就是一堆标签集合，所以这里的过滤，就 (multiplication)  / (division)  % (modulo)  ^ (power/exponentiation) 1 1 举一个例子来演示真实环境下的算术运算符的应用，比如之前的例子，对于内存可用率的指标 mem_available_percent 这个指标是采集器直接计算好的，如果采集器没有计算，而是上报了 原始指标 mem_available 和 mem_total，我们仍然可以使用 分位的值，但是这个值不是通过promql在服务端计算的，而是在应用的内存里，在SDK层面计 算的，即客户端把这个分位值算好，再上报给服务端，服务端就无需通过histogram_quantile 这么重的函数做计算了，而是直接查看就好。 但是，既然是在客户端SDK层面计算，就会产生局限，这些分位值只能是实例级别（或者说进程 级别，因为SDK是在应用进程里运行的）的分位值，这个是否个问题？ 笔者看来，