映客直播使用夜莺监控,支撑5亿时间线节省8成费用

郑富强 2022年5月25日
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
  • Proposal & Issues: github.com/ccfos/nightingale/issues
  • Docs: n9e.github.io

关于快猫星云

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

联系我们

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