滴滴开源夜莺：助企业构建稳定性体系

本文为滴滴秦晓辉老师在 2020 DevOps 线上峰会上的分享，更多精彩内容，尽在高效运维公众号。

大家好，我是来自滴滴的秦晓辉，这次给大家带来的分享是《滴滴开源夜莺：助企业构建稳定性体系》，主要是介绍夜莺这个开源监控项目，以及在稳定性体系构建中所起的作用。

左侧图片就是夜莺项目的logo，夜莺的英文名是 Nightingale，即南丁格尔，炜哥起的名字，比较切合监控告警这个场景。

好，下面先来做个自我介绍~

个人先后待过4家公司，百度、小米、金山云、滴滴，公司内部做的项目不便多说，开源这块主要是做了三个项目，Open-Falcon、Nightingale 和 DINP，刚来滴滴那会，主要是负责滴滴云的运维，现在是负责运维解决方案、运维产品的对外输出，主导了滴滴商业化运维平台ECMC的落地。

其实夜莺就是从ECMC中拿出来的一部分，ECMC作为一个商业化产品，融合了滴滴的最佳实践，功能比较丰富，大家如果有兴趣可以联系我。

OK，我们看一下今天的内容大纲~

主要内容分两个部分，一个是夜莺设计思路和产品简介，一个是夜莺如何助建稳定性体系。话不多说，我们进入第一个主题：夜莺设计思路和产品简介。

夜莺设计思路和产品简介

我们先来看一眼业界现状，开源的监控项目其实还挺多的，为啥还要立项做夜莺呢？

资深一些的运维人员，对左侧这三张图应该不陌生，非常老牌的监控系统，特别是 zabbix，在国内应用广泛，非常灵活，比较遗憾的是容量有限，监控数据用 MySQL 存储，监控千把台机器还可以，再多了就力不从心了。

那随着移动互联网的发展，大家对网站稳定性的要求越来越高，而监控作为提升稳定性的重要抓手，对它的要求也不止是要监控机器、交换机了，还有非常多的模块、业务的监控诉求，这导致监控指标呈爆炸式增长。

大家意识到，监控系统的难点，实际是大容量高性能的时序数据的存储和查询，于是涌现了非常多的时序数据库专门来解决这个问题，比如 InfluxDB、OpenTSDB、M3DB等，而这些新涌现的时序数据库，为了对监控数据更好的建模描述，大都是用 metric 加tag 的方式，来描述一条监控指标，引入 tag 这个维度信息，让监控数据的描述能力大为增强，一下子比 zabbix 进步了一大截，后面监控策略的配置也方便了很多。

我猜测，他们大都是借鉴了 Google 的 Borg 监控，Borgmon 对监控数据的描述方式，就是 metric 加 tag 的方式，Borgmon 是人家 Google 十多年前的产品，Google 在技术上确实甩了行业好几条街。

有了这些时序数据库，容量一下子提升了不少，很多公司就开始基于这些时序数据库来构建自己的监控系统，再配合 Grafana 这样的看图神器，监控系统的构建，看起来也没有那么难了。

Open-Falcon 就是这个时候出来的，不过 Open-Falcon 出来的比较早，M3DB 那时候还没有，OpenTSDB 倒是有了，InfluxDB 有一个初级版本，不能满足生产环境的要求，OpenTSDB 在大容量场景也有很多问题，所以当时 Open-Falcon 选择基于 rrdtool 自研。

之所以把 Open-Falcon 和 Prometheus 放到一列，是因为这俩系统不只是时序数据存储，而是一整套解决方案，既有数据存储，也有告警引擎，夜莺实际是从 Open-Falcon演化而来，与之一脉相承，没有直接采用 Prometheus，有很多原因，除了滴滴自己的演化路径之外，Prometheus 也有一些自己的问题，最大的问题是单点，虽然查询引擎有 PromQL 很灵活，但是单点问题削弱了这种灵活性的价值，告警策略是基于配置文件的不太方便，学习成本较高，告警事件的处理缺少了一些生产级的灵活性。不过近年来出现了Thanos，号称是大规模 Prometheus 解决方案，大家可以调研尝试一下~

下面我们来看一下滴滴的监控系统演化路径

早期滴滴是用 InfluxDB+自研告警模块的方式，当然，更早的时候还有更早的方案，不具备普世参考意义，这里就不讲了。

后来炜哥去了滴滴，作为 Open-Falcon 的创始人，自然会把 Open-Falcon 的一些优点借鉴过去，于是就有了ODIN监控。ODIN监控现在的指标量非常巨大，总量在七亿多，滴滴很多数据上报的非常频繁，周期是10秒，所以每秒处理的指标达到千万量级，查询请求每秒在十万量级。

16年我从小米离职那会，小米的指标总量在1亿左右，Facebook放出Gorilla那个论文的时候，指标量在20亿左右，所以7亿，其实已经是一个非常庞大的数量了。

后来，ODIN监控和内部的一个智能基线监控系统woater合并为滴滴统一监控，同时，ODIN监控也衍生出了一个商业版本的监控系统，就是ECMC的monitor，ecmc-monitor中的部分能力抽取出来开源，于是才有了Nightingale。

从这个血缘发展关系可以看出，Nightingale是升级版的Open-Falcon，如果大家之前了解过Open-Falcon，对夜莺的理念和使用方式将不会陌生。下面我们来看一下夜莺的项目情况。

夜莺三月底开源，到现在差不多一个月，收获1300多个github star，180个fork，issue和pr加起来有90多个，大家有很强的参与热情。这段时间快速release了3个大版本，9个小版本，一直在持续打磨，我们希望跟社区同仁一起，把监控这个事情做到极致。

前两天，在炜哥和井老板的撮合下，美菜决定引入夜莺，和我们一起共建社区，我们非常欢迎更多的公司参与进来~

既然夜莺衍生自Open-Falcon，那到底做了哪些改进，相信大家会比较感兴趣，我们一起来看一下~

一句话概括，思想上有延续，实现上优化巨大，几乎就是重写了。我们具体来看一下：

• 告警引擎逻辑重构：Open-Falcon是推模式，告警非常即时，我们改成了推拉结合，支持了数据缺失告警和多条件同时满足才能告警的与条件策略，告警事件的处理，支持告警收敛、告警认领、告警升级等非常实用的生产级特性

• 引入导航对象树：我们内部称为服务树，各互联网大厂运维平台的标配，也是之前Open-Falcon社区呼声非常高的需求，告警策略可以直接关联到服务树节点，子节点会直接继承，让监控策略的配置，一下子简单了很多

• 索引模块升级换代：Open-Falcon使用 MySQL 存储监控指标的索引数据，在扩展性和灵活性上存在瓶颈。夜莺引入了内存索引模块，避免了原来MySQL索引数据达到亿级别时面临的尴尬局面

• 时序数据库优化：最大的优化是引入 Facebook 的 Gorilla 压缩方案，近期几个小时的数据采用内存存储，大幅提升数据查询效率

• 告警引擎高可用改进：告警引擎judge模块通过心跳机制做到了故障自动摘除，再也不用担心单个judge宕机导致部分策略失效，需要人工介入的问题，index模块也是采用类似方式保证可用性

• 原生内置日志监控功能：夜莺客户端原生内置了日志匹配和指标抽取能力，在 web 控制台页面上支持了日志匹配规则的配置，绝对的业务监控利器。Prometheus是要求各个业务进程都开一个webserver的接口，请求就能返回这个模块的监控指标，这是从Google的规范衍生而来，Google的所有模块，都要求开一个web接口，叫/varz，请求之后可以返回监控指标。但是对于国内公司，这个规范太强了，很少有公司能够遵照。而日志监控，相对侵入性就小多了，业务方接受度会高很多，滴滴内部的业务监控，有很多就是通过日志监控实现的

• 可运维性增强：将多个模块合并，简化了系统整体部署难度，原来的部分模块间调用自然就变成了进程内方法调用，性能更高

• 配置文件中心化：配置文件做了易用性改造，把一些共同的配置抽取出来做成单独的配置文件，大批配置在代码里给了默认值，使得配置文件更清晰，易于维护

OK，这是做的一些比较大的改进。当然，也有一些特性是维持不变的，比如数据模型没变，这样就可以复用Open-Falcon社区的插件。监控数据落盘存储，仍然使用rrdtool，让rrdtool来做实时归档，存储几年的数据都不成问题。

如上就是和Open-Falcon的功能对比，下面我们来看一下夜莺的整体系统架构

左边的collector是agent，用来部署到目标机器上采集监控数据的，右侧的组件都是服务端组件，除了nginx、redis、mysql 这三个开源软件，剩下的服务端自研的组件有五个，transfer、tsdb、index、judge、monapi，从模块数量上来看，比 Open-Falcon 少多了，主要是有些功能模块做了合并。

我们简单来看一下这个架构，collector 作为采集端，除了可以采集 cpu、内存等常用指标，还支持插件扩展机制，内置了日志监控能力，同时还对外暴露了接口，支持业务主动上报监控数据。

collector将监控数据通过长连接推给transfer，transfer是个无状态组件，可以水平扩展，transfer会将数据做一致性哈希分片，不同的分片数据打给不同的tsdb，所以数据很多的话，就要部署多个tsdb来组成集群，如果要做高可用可以部署多个集群来做双写。tsdb收到数据之后，除了存储到内存和落盘，还会转发一份给index模块用来构建索引，这里有些优化措施，tsdb到index的数据是增量的方式，毕竟，只有新数据才需要建立索引。

judge模块是告警引擎，周期性从monapi同步告警策略，然后对数据做告警判断，如果监控数据触发阈值，就会生成告警事件，推到redis的队列里，后面会有monapi模块来消费这些告警事件，进行告警事件的处理，通常的处理方式就是告警发送，或者回调

monapi实际集成了之前open-falcon的多个模块的功能，除了会消费redis里边的告警事件，还提供webapi给前端js调用。js除了会调用monapi，还会调用index模块来查询索引，调用transfer模块来查询数据，所以会在这三个模块前面挂一个nginx，用不同的location来区分不同的后端。

另外，index和judge模块，都会有周期性的心跳机制，上游在请求这俩模块的时候，可以知道哪些实例挂掉了，哪些还活着，然后自动踢掉挂掉的实例，以这种方式来做容灾。

所以，整个后端组件全部是有容灾机制的。任何一台机器挂掉，对整个集群的可用可靠性都不会造成影响。

OK，了解了整个架构，我们再做细粒度拆解，看夜莺在数据采集、存储、告警、事件处理等几个方面分别是如何思考的。先来看夜莺数据采集的能力

这块的理念和Open-Falcon是一致的，作为监控系统的研发人员，坦白讲，无法对所有要监控的对象都了若指掌，比如要监控mysql，到底应该监控哪些指标，DBA要比我懂得多，要监控hadoop，那大数据的研发也比我懂得多，所以，我们需要一种共建生态的做法，让专业的人干专业的事。

其实也简单，夜莺建立了一种通用的DataModel，来描述监控数据，大家只要遵照这个规范上报数据即可。我们就只关注服务端存储能力、告警能力的建设。

这个DataModel，和OpenTSDB、Prometheus相比，非常相似，与Open-Falcon相比，几乎完全一致，只是多了一个Extra字段，用来存放扩展信息，比如traceid，或者一些错误日志等，这些信息不便于放到tag里，因为是不可枚举的，放到这个Extra字段正合适，如果数据触发阈值，告警事件里会带上这个Extra字段的信息，便于我们定位问题。这个特性适用于自定义监控数据上报的一些场景，算是给高端玩家的福利。

当然，夜莺也不是说所有的监控数据采集都不管，会提供一个默认的Linux的collector，采集Linux系统的一些常用指标，社区也有成员贡献了Windows版本的collector，交换机的collector，都可以直接拿来使用。

Linux版本的collector内置了日志监控，可以用正则提取监控指标，强烈推荐大家试用一下，绝对的业务监控的利器。

扩展机制这部分，主要是插件机制，可以兼容Open-Falcon的所有插件和大部分独立采集器。为什么不是兼容所有采集器，是因为夜莺与Open-Falcon相比有两点差异，一个是变更了rpc传输协议，从jsonrpc变成了msgpack，另一个是counter类型的处理前置到了collector组件，所以，如果要推送counter类型指标，只能推到collector，不能直接推到transfer。

说完了监控数据采集，我们再来说说监控数据存储

这个图已经非常清晰了，监控数据量大的话，tsdb需要集群，如果对可靠性还有要求，那就要考虑部署多个tsdb集群，上层transfer可以配置双写模式。滴滴内部的tsdb是做成了两个集群，每个集群70台nvme的机器，性能非常强悍，为了抗住每个周期的7亿多监控指标，真的是付出了巨大的成本。

单个集群内部是一致性哈希分片，这个比较容易理解不再赘述，单个tsdb进程来看，内存使用gorilla构建内存tsdb，落盘使用rrdtool，做降采样归档。

监控的服务端最核心的能力，一个是数据存储和查询，另一个是告警引擎，我们来看一下夜莺的告警引擎

夜莺的告警引擎非常灵活，我称其为生产级的灵活性，因为告警这个事情，在企业落地的时候，会遇到非常多零零碎碎的需求，没有还不行，业务不满意啊，那夜莺的这些灵活的策略特性，也是我觉得比Prometheus有优势的点，我们具体来看一下。

首先是告警分级，严重到不严重分三个级别，P1、P2、P3，不同的级别会对应不同的发送通道，比如P1很严重，既会打电话，也会发短信，还会发邮件，P3不太严重，就不打电话不发短信，只是发个邮件。

告警收敛也是个很实用的功能，可以配置N分钟之内最多发M次告警。这样，如果故障一直没有恢复，不会发很多告警打扰你，也不会只发一次，后面容易忽略。

告警回调是说告警之后会自动回调你的自动化系统，来触发告警自愈的逻辑，这个功能Open-Falcon里也有。

告警认领和告警升级，是防止晚上值班人员睡着了，告警迟迟没有人响应，此时可以触发升级机制，再去通知备份oncall人员，或者值班人员的leader，让leader来兜底。

时间窗口，Open-Falcon也有，不过夜莺做的更灵活，除了可以定义白天一个策略，晚上一个策略，也可以定义工作日一个策略，周末一个策略。

留观时长，是为了应对偶发性的恢复毛刺现象，报警之后，如果指标恢复，不会立马报恢复，会等待一段时间来观察，称为留观时长，直到观察期过了，没有问题才发恢复通知。

静默恢复，比较简单，就是不发恢复通知。指标异常了，会发告警，恢复了，不发恢复通知。

策略继承和特例排除，都是依托服务树的，非常非常实用，比如我负责某个业务线的运维，我只要在业务线对应的服务树节点上配置告警策略即可，下面所有的子节点都会继承，特殊的节点也可以排除，非常方便。

与条件告警，是相对Open-Falcon新引入的能力，即多个指标同时满足条件才会报警。

标签过滤也做了优化，不但支持包含，还支持排除，比如硬盘利用率，就可以把/boot分区这样的不用关注的分区排除掉。

性能上也有一些优化，judge模块只会缓存有策略关联的数据，没有策略关联的则不缓存，大幅减少内存消耗。

最后，我们说一下夜莺事件处理的能力~

所有历史告警事件，以及当前未恢复的告警，都入库存储，用来做日常巡检和告警分析。

发送通道的话，其实夜莺本身不直接支持，夜莺的理念，是做好核心模块，告警事件产生之后扔到Redis队列里就不管了，我们需要自己写自己的sender模块来发送，社区目前提供三个sender，邮件、钉钉、微信，都在github的n9e这个group下，欢迎大家提交更多的sender模块。

最后一个事件处理机制是告警回调，通常用来对接内部的自动化渠道，做告警自愈，这个不再赘述。

最后说一下夜莺的后续发展~

核心方向有三个，第一，引入指标聚合模块，有了这个能力，就可以聚合集群维度的指标数据，非常关键的一个功能。

第二，是与云原生体系更好的整合，比如自动读取Kubernetes的各个组件的指标数据，自动读取cadvisor的数据。

第三，是整理社区周边，Open-Falcon很多插件可能都已经年久失修了，后面希望发动社区力量把这些插件整理到夜莺的社区维护起来。欢迎大家把周边的组件提交到github的n9e这个group。

第一部分到这就结束了，主要是对夜莺的一个全方位的介绍，下面我们进入第二部分~

夜莺如何助建稳定性体系

夜莺如何助建稳定性体系，这块主要从稳定性体系的建设角度来看，夜莺起到的作用，为大家在公司里落地夜莺，提供一些思路。

我们首先来看整个稳定性体系的一些建设思路~

提升稳定性，本质就是要减少故障，那怎么减少故障？我们可以考虑从故障的整个生命周期各个环节去着手，每个环节想一些优化手段，过程好了，结果总不会太差。

先来看预防环节，你能想到哪些关键词？哪些优化措施？预防阶段其实是最应该下大力气去搞的环节，这个环节最核心的是去降低故障发生的概率，即所谓的降发生。

想办法排掉隐患，制定规范流程，避免不规范的操作引发故障，这个环节做的事情比较难以被老板看到，需要尽可能多的去想一些量化措施，量化成果的同时，能够看到趋势再往好的方向发展，就足够了。

其次是发现环节，监控主要是为这个环节出力的，监控线上问题，有问题及时报警，那我们就需要完备的指标体系，如果没有完备的监控指标，告警引擎再灵活，也是巧妇难为无米之炊，上报了完备的监控指标，能覆盖业务运行情况了，再考虑策略的完备性，出了任何故障都能有监控策略对应，都能有告警通知，如果oncall同学睡着了，也可以有告警升级机制来兜底。

然后是定位环节，主要是靠各类监控大盘，从上到下，从业务到模块，层层递进下钻，才能方便定位问题。一些链路追踪的手段，根因推荐等，也能帮我们定位问题，当然，还有良好的协作机制。

再说止损环节，显然，就是预案相关的工作，出了问题能有对应的操作原则和操作手册，指导oncall同学去止损，当然，不需要人为参与的告警自愈机制，是每个公司都应该去建设的能力。

最后说复盘环节，这个环节主要是优化故障跟踪和管理、改进项管理，让每个故障不再重复发生，举一反三，是复盘的核心目的。

那夜莺在各个环节可以提供哪些助力呢？我们先来看故障预防环节~

故障预防环节

夜莺在这个环节可以帮助排掉部分隐患，可以量化部分风险。因为夜莺提供了完备的接口，可以查询策略数据、告警数据，以此分析量化监控系统的使用情况，我们内部称为监控健康分。

排掉隐患方面，比如，去检查所有机器是否都关联了必要的策略，即告警完备性排查；检查策略是否有效，即时发现人员离职的情况，避免出现孤儿策略。

量化风险方面，比如，统计回调覆盖率，回调覆盖率其实代表了故障处理的自动化程度，我们内部有些产品，回调覆盖率可以打到70%多，即有70%多的故障，都是无人值守自动化处理的，这非常了不起。

另外就是统计告警事件，产品线的维度，或者人的维度，都可以统计，来横向对比，看哪些产品线报警过多，说明稳定性堪忧，人的维度来说，收报警最多的人，可能是工作安排不合理，也可能是策略配置不合理。

所有告警历史事件都是可以追踪的，所以可以统计告警恢复时长，一般使用分位值来量化，告警恢复时长可以体现止损的及时性和预案有效性。

OK，接下来来看故障发现环节~

故障发现环节

夜莺提供的核心能力，就是告警引擎，即时通知和告警升级的机制，这块在前面讲的比较多了，就不再赘述。

接下来来看故障定位环节~

故障定位环节

夜莺在这部分的核心作用是监控大盘，夜莺的监控大盘支持两个比较有意思的能力，一个是阈值，一个是下钻链接。阈值是一个危险值，体现为图上面的一条红色横线，巡检的时候就可以一目了然。下钻链接是为了串联不同的监控大盘，典型用法是最上层的监控大盘展示业务指标，这个业务指标如果异常，可能是某个模块出了问题，那就把所有的模块做成一个大盘，业务指标的图上增加一个下钻链接，点击，就可以链到模块大盘上去。

另外监控里边的告警事件，和变更平台里的变更事件，建议都统一接入事件大盘，因为很多线上故障都是变更引起的，如果告警事件和变更事件放到一个大盘里，就可以比较方便的看到，某个故障很可能与就近的变更有关系。那么回滚相关的变更，可能就是最快的止损方案。

最后就是告警现场数据，夜莺的告警事件里，会存储触发阈值的那几个异常值，有助于排查问题。同时告警回调机制，也给了我们一种快速抓现场的机制，比如这边一告警，那边触发一个回调，自动去机器上跑一些命令，将结果发邮件给相关人员，相关人员就能拿到第一手现场数据。

下面我们来看一下止损环节~

故障止损环节

夜莺在这块只有一个能力，就是告警回调，与内部自动化逻辑打通。前面已经说过多次了，这里就不再赘述。PPT这张图片，是一个自愈脚本的实例，清理一些无用日志，比如硬盘满了，回调机制就可以触发这个脚本的执行，去自动清理日志，然后故障就自动恢复了。

滴滴内部每周的故障自愈任务量大约几千次，节省了大量运维人力，的确是运维人员提升稳定性提升效率的神器。

最后说一下故障复盘环节~

故障复盘环节

这个环节侧重于告警跟踪，故障管理，夜莺作为监控，就要提供详实的监控数据，告警事件，这点毋庸置疑。

最近了解到aws内部有个工具叫TT，即Ticket Tracker，可以用来跟踪告警，非常方便，Google内部我记得也有一个类似的工具，在SRE那本书里有讲，具体忘记了。总之感觉这样的工具非常方便，特别是对oncall轮班的场景，大家可以考虑在内部构建类似的工具。

好了，简单总结一下，夜莺作为监控系统，其实是贯穿故障的整个生命周期，预防、发现、定位、止损、复盘，每个环节都有一些不可或缺的能力，说监控是运维最重要的平台，我觉得毫不为过。

希望夜莺能够成为各位运维过程的有力工具，希望今天的分享确实给大家带来了一些收获，我的分享就到这里，谢谢大家。