Flashcat导读：

对于像映客直播这样的在线直播行业，建立全面高效的运维监控体系对于直播稳定性的重要性不言而喻。映客直播运维团队在选择监控工具时，发现 Prometheus 在企业级场景落地时存在易用性、扩展性的问题，告警配置和维护也相对复杂。而夜莺监控作为 Prometheus + AlertManager + Grafana组合的 all-in-one 替代方案，吸引了他们的目光。目前夜莺监控已经稳定运行了2个月，节约了80%+的机器成本，同时大幅降低了中间件的数据采集难度。

本文总结了映客直播在选型、落地适配等方面的经验，还有它们从 open-falcon 迁移到夜莺监控（Nightingale）后的落地成效，期望此文能给面临同样运维困扰的用户一些启发。

企业简介

映客，中国领先的互动社交平台，港交所直播第一股。旗下核心产品“映客APP”是中国移动直播行业的开拓者，多款语音社交产品在各自细分领域迅猛发展，覆盖在线相亲、语音交友、直播电商等领域。映客于2018年7月正式登陆港交所主板，主要产品MAU（每月活跃用户）4280万人。目前，集团总部位于北京，员工近1700人，其中50%为研发人员。

映客直播监控平台遇到痛点

映客之前使用的是 open-falcon，业务监控是内部自研基础框架上报的，随着各业务线的发展，监控项越来越多，open-falcon 的问题也越来越突出，主要包括以下几个方面：

机器资源消耗严重

open-falcon存储模块对 disk.io 要求很高，目前使用了 ssd 硬盘，disk.io.util 仍能达到 70%，且一致性哈希写流量不均，造成个别机器 disk.io 很高，数据堆积在内存中导致内存不足。每次有新项目上线，监控数据就会增多，如果内存不足就需要扩容。

新增需求无法满足

看图需求

• 查看历史原始数据，open-falcon存储会对历史数据归档，只能查看近几个小时的原始数据;
• 查询指标更灵活，open-falcon看图展示维度有限，不支持多指标计算;
• 查看图表大盘更流畅，open-falcon 的监控大盘打开慢，如果某个项目机器和series很多，经常会遇到打不开 screen 的情况，只能拆分 graph 到多个 screen 或者减少 counter 数量;

告警需求

• 更丰富的告警函数，open-falcon 告警函数少，无法配置多指标组合告警、不支持同环比告警;
• 更灵活的监控规则配置，open-falcon告警规则无法模糊匹配，只能通过tag筛选;
• 更灵活的监控屏蔽配置，open-falcon 无法根据tag对告警进行屏蔽，屏蔽只能按照机器粒度;

采集需求

• 监控采集更容易，open-falcon 不方便对接第三方系统，如 kafka、k8s 等指标采集只能自己开发对接;

调研选型

由于上述需求无法满足，我们一直在寻找新的监控解决方案，主要考虑以下几点：

• 机器资源消耗
• 采集生态完善度
• 业务需求匹配度

调研测试之后决定迁移open-falcon至夜莺监控v5版本。夜莺监控（Nightingale）是一款开源云原生监控分析系统。采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析能力。已有众多用户选择将Prometheus + AlertManager + Grafana 的开源组合方案升级为使用夜莺监控方案。我们调研下来，匹配度较高。

落地方案

整个监控平台抽象为国内和海外两个集群，有4个机房，国内有 A、B 机房，海外 C、D 机房。整体部署架构如下：

服务组件

• n9e-webapi：夜莺的配置管理模块，对告警规则、屏蔽规则、订阅规则、自愈脚本、权限等相关配置进行管理；
• n9e-server: 图表中的 ts-server、ali-server、tx-sg-server、aws-server，夜莺的告警引擎，根据用户配置的 PromQL，查询时序库，判断是否应该触发告警并发送；
• thanos: 图中的 ali-TSDB，用的 receive 模式，保存3个月原始数据，历史数据会采样之后上传到 oss,压力主要在 receive 服务；
• victoriametrics：图中的 tx-TSDB，vm性能很好，5台8c64G2T机器部署storage cpu使用30%左右，内存使用60%，硬盘使用1.3T左右,3台8c*16G机器部署insert,select服务，目前没啥压力；
• prometheus：海外机房时序存储，如果监控项不多，用Prometheus挺好的，注意动态加载配置reload，重启会很慢；

采集实践

• 机器指标：采用 telegraf 采集，加壳部署为 n9e-agent 方便后期统一部署管理，每个机器都往各自机房 server 写数据；
• 业务指标：由 sdk 直接上报，通过 falcon 的 /v1/push 接口转发至夜莺监控；
• 中间件指标：通过各自机房部署的 prometheus 进行 exporter 抓取；
• k8s容器指标：通过已有的 k8s prometheus 进行抓取，远程写入到 n9e-server；

现状和收益

当前监控平台现状

目前整个监控平台的 series 数量有5亿+（实际应该是2.5亿+，之前为业务组打上标签导致很多指标重新上报了），整个平台运行良好。

使用夜莺监控后的收益

• 节约了大量机器成本，夜莺监控比 open-falcon 节约86%的成本，整个平台机器量由原来的80台降低为20+台；
• 采集成本降低，比如采集 kafka、zk、consul 等中间件，不再需要开发工具去抓取，直接用 prometheus 采集远程写入到 n9e-server；
• 更灵活的告警和看图功能，满足目前业务需求；

落地适配经验分享

在落地过程中，为了降低研发使用难度我们做了一些适配改造，主要有以下几个方面：

采集管理

• 对telegraf采集做了优化，对不同inputs采集间隔进行了调整，如cpu,disk.io是15s采集，disk是60s；
• telegraf启用inputs.exec功能，默认会去执行/plugin/*.sh脚本，方便自定义用户采集脚本；
• telegraf增加日志关键字监控，简单的日志监控使用自定义脚本，复杂的使用mtail监控；

告警管理

• 自动按业务线添加基础监控，所有监控项都会带上busigroup，如mem_available_percent{busigroup=“ops.xxx”}，这样可以提高查询速度，且防止收到其他业务组告警；
• 所有自动添加的监控都会带上附加标签，方便后期针对性屏蔽监控；
• 根据业务需求配置多种规则模板，业务有需求自行导入；
• 用notify.py的方式增加了短信和电话告警；

看图管理

• 自动按业务线导入基础和业务监控大盘，用户选择业务组就可以看到对应大盘。

资源管理

• 根据服务树关系自动创建业务组，自动绑定业务组，自动删除已下线机器。

用户管理

• 根据权限系统，自动同步用户，自动删除离职用户，自动创建3个团队，如ops.monitor.dev，ops.monitor.sre，ops.monitor是dev+sre所有用户；
• 做完以上工作大量简化了运维和研发工作量，运维只需要关注默认告警阈值是否合理即可；

写在最后

我们非常高兴有夜莺监控（站点在n9e.github.io），并且将其应用到了我们的系统改造中，夜莺监控不仅帮我们解决了 open-falcon 成本过高和功能少的痛点，也匹配上了后续业务发展的需求。

感谢夜莺监控的各位小伙伴带给我们的支持，希望未来夜莺监控能够更新出越来越多优秀的特性，越来越好，也希望有越来越多的用户能加入到夜莺监控的社区互动当中。

作者简介

郑富强，映客-运维开发工程师，使用Python和Golang作为开发语言，关注运维新趋势。

关于夜莺监控

夜莺监控是一款开源云原生监控分析系统，与云原生生态紧密集成，提供开箱即用的企业级的监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

• Github：github.com/ccfos/nightingale
• Docs：flashcat.cloud/docs

关于快猫星云

快猫星云，一家云原生智能运维科技公司，秉承着让监控分析变简单的初心和使命，致力于打造先进的云原生监控分析平台，结合人工智能技术，提升云原生时代数字化服务的稳定性保障能力。

• 联系我们：contact-us@flashcat.cloud
• 官方网站：https://flashcat.cloud