移动至上、大道至简！汽车之家第3代云监控AutoCMP建设之路

总篇95篇 2020年 第19篇

前言

汽车之家监控系统已历经2代建设，第1代技术方案是分布式部署Zabbix，以“能用”为主；第2代是围绕运维需求，基于小米开源监控项目Open-Falcon的二次开发，以“可用”为主；第3代，我们凭借之家在监控领域的技术实力与知识储备，跳脱固化思维、独立思考，立志为用户提供“好用”的监控。

背景

步入2020年，汽车之家在研发效能提升、技术持续突破、业务转型升级上的需求极其迫切，当我们在规划下一代监控系统时，以下因素是我们必须要面对的：

下一代监控系统如何能帮助之家进一步提升研发效能？

大多数研发人员的日常工作就是撸代码、查故障。如今之家已有90%线上业务部署在容器里，容器因为具备极好的伸缩与自愈能力，研发人员排查源站故障的耗时已大幅降低。排障耗时的基数已然降低，还有哪些低效空间可以挤压并消灭呢

技术不仅能实现业务意图更能通过技术突破释放技术红利赋能业务，下一代监控系统的技术突破点在哪？

各个互联网公司都有自己的监控系统，这些系统各有技术特色。之家的应用运维架构已经步入云原生生态，下一代监控系统必然绕不开云原生生态，我们该怎么利用云原生突破呢

之家将向汽车生态圈供给云计算能力，下一代监控系统如何脱颖而出？

目前，汽车之家利用AI人工智能、Bigdata大数据、Cloud云计算，以流量、销售线索、内容及数据等赋能汽车生态系统中各个参与方，加速迈向智能平台3.0时代。监控系统做为云计算必备功能之一，面对的是一片红海，我们该如何在众多厂商中体现自身价值呢

策略

基于上述大背景的思考，AutoCMP进行了应对升级：

研发效能提升方面：移动至上，告警随时查看、故障随手处理

我们发现在开会、外出、居家等场景下，很多故障从告警接收到处理完毕的用时远长于用户在电脑前处理用时。过去这些场景，我们只是给告警接收人的手机发送短信或钉钉通知，但受限于短信和钉钉通知的格式与字数限制，告警接收人难以快速掌握故障覆盖范围和处理进展，一般情况仍需拨通VPN连接PC端访问云监控查看。因此，我们在之家移动办公平台“汽车人”里推出“掌上监控”，让用户能通过手机，全面掌握URL、应用、源站等各维度健康状态

技术持续突破方面：融合云原生时代和分布式时代最流行的技术栈

之前经典主机监控使用小米开源的open-falcon，用户自定义、容器应用监控使用SoundCloud开源的prometheus，每增加同一需求功能时，都得用open-falcon与prometheus各实现一次。第3代架构以prometheus为核心，同时将经典主机的数据通过改造open-falcon的tranfer组件将数据打到prometheus中，实现时序数据存储的统一，并在此基础上二次开发告警组件（judge）、数据转发组件（gateway）、图形数据查询组件（query)等

业务转型升级方面：大道至简，主要围绕研发角色视角而非运维角色视角

复杂很简单、简单却并不简单，当业内几乎所有监控系统都在堆栈、堆功能的时候，我们认为大道至简，再精尖的技术，对用户而言需要得到的只是应该自己关心的告警和该告警的故障点。所以我们 建设了以应用为中心的全方位监控 ，所有告警对象都与应用及部署环境紧密关联，且应用监控配置自动化，应用发布即完成配置， 无接入成本 。同时考虑到之前两代监控里大量默认基础监控都是运维定义的，实际上研发无需关注，为此我们减少了大量的默认基础监控项

实现

1.以移动化为核心的研发效能提升方面

云监控的移动化，产品上依托于云平台整体的移动化，技术上依托于之家移动办公平台“汽车人”的小程序架构。用户可以在“汽车人”里一键拨VPN查看告警详情，并且可以关联其他云服务的移动化，进行上下负载、源站扩容等排障操作

2.以云原生技术为核心的技术突破和以研发视角为核心的业务转型升级方面

2.1 设计监控系统时序数据库prometheus多副本存储架构，保障存储系统的稳定性

生产中某些公司使用prometheus引入“联邦”解决多副本存储，从而保证系统存储的稳定性，之家前期也是采用联邦的形式(prometheus->prometheus)，后来业务数据增长过快，联邦多副本存储架构处理能力不再能满足生产环境，例如：第一个prometheus数据量为600万/min，则第二个prometheus每分钟定时通过http一次性拉取600万数据。原因：数据量过大，拉取数据超时，单机某点处理数据能力故障，造成数据中断，告警异常等线上故障

我们的设计采用gateway->双prometheus不仅解决多副本存储架构，还解决了由pormetheus->prometheus单机数据同步异常的问题，从而保证存储系统的稳定性，例如：10个gateway 60万--->rpc持续传输---->两个prometheus，数据上传时间分散在每分钟内，降低某一时刻数据处理压力），通过所有数据时间戳在gateway生成、prometheus不再生成数据时间戳，解决多副本存储时间的一致性

2.2 引入远端存储组件influxDB，保障近一年内的监控数据可查

prometheus设计初衷实时数据，其自带的时序数据库将数据保存到本地磁盘，但本地存储的容量毕竟有限，所以引入远端存储组件influxdb。保障近一年内的监控数据可查

2.3 时序数据库prometheus副本节点上容器，目前运行稳定

目前prometheus采用的双节点模式为（物理机节点+容器节点)，通过容器组相关技术人员支持，使用有状态时序数据库prometheus副本作为一个pod在k8s集群中运行，目前运行相对稳定

效果

AutoCMP上线后，已经接入之家全部应用监控，大幅降低了非现场排障时间、应用配置时间，增加了监控信息可查询时间，使得故障更易发现和定位

后续

1.排障线索的基础数据关联不足，需要与监控系统的上游系统共同努力，丰富基础数据

2.AI在监控中使用还有巨大潜力，大多数容器故障并不影响业务，我们希望通过AI进行降噪并定位故障