Flashcat导读：
对于像映客直播这样的在线直播行业，建立全面高效的运维监控体系对于直播稳定性的重要性不言而喻。映客直播运维团队在选择监控工具时，发现 Prometheus 在企业级场景落地时存在易用性、扩展性的问题，告警配置和维护也相对复杂。而夜莺监控作为 Prometheus + AlertManager + Grafana 组合的 all-in-one 替代方案，吸引了他们的目光。目前夜莺监控已经稳定运行了 2 个月，节约了 80%+ 的机器成本，同时大幅降低了中间件的数据采集难度。
本文总结了映客直播在选型、落地适配等方面的经验，还有它们从 open-falcon 迁移到夜莺监控（Nightingale）后的落地成效，期望此文能给面临同样运维困扰的用户一些启发。
核心要点
- 映客原有 open-falcon 体系在存储资源、看图、告警配置、屏蔽策略和第三方采集对接上逐渐难以满足需求。
- 新监控平台按国内和海外、多个机房拆分部署，结合 Thanos、VictoriaMetrics、Prometheus 等组件承载不同场景。
- 迁移后，平台支撑每个采集周期 5 亿级 series 上报，机器规模从原来的 80 台降低到 20+ 台，原文口径下节约 86% 成本。
- 映客的落地经验不只是换工具，还包括采集管理、告警模板、看图管理、资源管理和用户权限同步等配套适配。
企业简介
映客，中国领先的互动社交平台，港交所直播第一股。旗下核心产品“映客 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、Kubernetes 等指标采集只能自己开发对接;
调研选型
由于上述需求无法满足，我们一直在寻找新的监控解决方案，主要考虑以下几点：
- 机器资源消耗
- 采集生态完善度
- 业务需求匹配度
调研测试之后决定迁移 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；
| 模块 | 映客的选择 | 解决的问题 |
|---|---|---|
| 配置与告警管理 | n9e-webapi、n9e-server | 管理规则、屏蔽、订阅、自愈脚本和告警判断 |
| 国内时序存储 | Thanos receive 模式 | 保存原始数据并处理历史采样归档 |
| 部分机房时序存储 | VictoriaMetrics | 承载大规模 series 写入和查询 |
| 海外时序存储 | Prometheus | 监控项不多时保持简单可用 |
| 指标采集 | Telegraf/n9e-agent、Exporter、SDK、远程写入 | 覆盖机器、业务、中间件和容器指标 |
现状和收益
当前监控平台现状
目前整个监控平台的 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所有用户；
- 做完以上工作大量简化了运维和研发工作量，运维只需要关注默认告警阈值是否合理即可；
给同类团队的迁移启示
- 先明确原系统瓶颈：是资源成本、查询能力、告警能力、采集生态，还是权限和运维效率。
- 按场景选择存储组件：不同机房、不同规模可以使用不同后端，不必强求一套架构覆盖所有场景。
- 保留业务使用习惯：通过 falcon
/v1/push转发等方式降低业务侧迁移成本。 - 把标签和业务组设计好：
busigroup等标签能帮助查询、告警隔离和后续屏蔽策略。 - 把平台能力产品化：规则模板、大盘导入、用户同步、资源自动绑定，都是降低长期运维成本的关键。
写在最后
我们非常高兴有夜莺监控（站点在 n9e.github.io），并且将其应用到了我们的系统改造中，夜莺监控不仅帮我们解决了 open-falcon 成本过高和功能少的痛点，也匹配上了后续业务发展的需求。
感谢夜莺监控的各位小伙伴带给我们的支持，希望未来夜莺监控能够更新出越来越多优秀的特性，越来越好，也希望有越来越多的用户能加入到夜莺监控的社区互动当中。
作者简介
郑富强，映客-运维开发工程师，使用Python和Golang作为开发语言，关注运维新趋势。
关于夜莺监控
夜莺监控是一款开源云原生监控分析系统，与云原生生态紧密集成，提供开箱即用的企业级的监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。
- Github：github.com/ccfos/nightingale
- Docs：flashcat.cloud/docs
FAQ
Q1：映客为什么从 open-falcon 迁移到夜莺监控？ A：原系统在机器资源消耗、历史原始数据查询、多指标计算、告警函数、规则配置、屏蔽策略和第三方采集对接上逐渐难以满足需求。
Q2：迁移后最直接的收益是什么？ A：按原文口径，平台支撑每个采集周期 5 亿级 series 上报，机器量由原来的 80 台降低为 20+ 台，夜莺监控比 open-falcon 节约 86% 成本。
Q3：这个案例对其他企业的主要参考价值是什么？ A：大规模监控迁移不能只替换一个工具，还要同步设计采集、存储、标签、告警模板、看图管理、资源管理和用户权限同步。
