共计 5581 个字符，预计需要花费 14 分钟才能阅读完成。
作者：vivo 互联网服务器团队 - Chen Ningning
本文依据“2022 vivo 开发者大会 ” 现场演讲内容整顿而成。
通过几年的平台建设，vivo 监控平台产品矩阵日趋完善，在 vivo 终端宏大的用户群体下，承载业务运行的服务数量泛滥，监控服务体系是业务可用性保障的重要一环，监控产品全场景笼罩生产环境各个环节。从事前发现，事中告警、定位、复原，预先复盘总结，监控服务平台都提供了丰盛的工具包。从以前的程度拆分，按场景建设，到起初的垂直划分，整合对立，升高平台割裂感。同时从可观测性、AIOps、云原生等方向，监控平台也进行了建设实际。将来 vivo 监控平台将会向着全场景、一站式、全链路、智能化方向一直摸索前行。
监控服务平台是自研的、笼罩全场景的可用性保障系统。通过多年深耕，vivo 监控团队曾经成体系构筑起一整套稳定性保障系统，随着云原生可观测技术改革一直深入，监控团队如何掌舵前行？上面就平台的建设历程、思考、摸索，做一下简略介绍。
一、监控体系建设之道
1.1 监控建设历程
回顾监控建设历程，最后采纳 Zabbix，与告警核心的组合实现繁难监控。随着业务的倒退在简单监控场景和数据量一直增长的状况下，这种繁难的组合就显的顾此失彼。所以从 2018 年开始咱们开启了自研之路，最开始咱们建设了利用监控、日志监控、拨测监控解决了很大一部分监控场景没有笼罩的问题；2019 年咱们建设了根底监控、自定义监控等，实现了次要监控场景的根本笼罩；2020 年咱们在欠缺后期监控产品的同时，进一步对周边产品进行了建设；随着 AI 技术的一直成熟，咱们从 2021 年开始也进行了转型降级，先后建设了故障定位平台、对立告警平台有了这些平台后咱们发现，要想进一步晋升平台价值，数据和平台的对立至关重要；所以从 2022 年开始建设了对立监控平台，也就是将根底监控、利用监控和自定义监控进行了对立，对立监控蕴含了对立配置服务和对立检测服务。从监控的建设历程来看，咱们一路笼罩了 IaaS、PaaS、DaaS、CaaS 等平台。咱们的职能也从 DevOps 向 AIOps 迈进。
1.2 监控能力矩阵
讲了监控的倒退历程，那么这些监控产品在咱们的生产环境中是如何散布的呢？要想撑持数以万计的业务运行，须要庞杂的零碎撑持，服务器、网络环境、根底组件等，都须要监控零碎保障它的稳定性。咱们将监控的对象分为五层，在基础设施层，蕴含了网络设备、服务器、存储硬件等，这一层咱们通过 VGW 监控对网络设备进行监控，VGW 是 Vivo Gateway 的缩写，相似于 LVS；通过自定义监控，对机房进行监控；零碎服务器层，咱们定义的监控对象是服务运行依赖的环境，通过主机监控对物理机、虚拟机等监控，以后容器在云原生技术体系中，未然成为微服务运行的最佳载体，所以对容器的监控必不可少；零碎服务层，蕴含了各种数据库产品、大数据组件等，在这一层次要通过自定义监控检测、告警；业务应用层，次要有应用服务，咱们通过利用监控对业务链路信息进行监控；客户体验层，咱们定义了端上的拜访品质，由宙斯平台实现监控。后面咱们讲了监控能力矩阵，上面咱们具体介绍一下监控的范畴和整个平台的能力。
1.3 监控对象范畴
监控对象波及网络、主机、根底服务等。面对各地机房咱们做到了监控全笼罩，为满足各类环境部署诉求，咱们能够做到针对不同环境的监控。咱们反对多种采集形式，SDK 和 API 采集次要利用在自定义监控场景，Agent 次要采集主机类指标，采集上来的时序数据通过预聚合、对立的数据荡涤，而后存储在 TSDB 数据库。针对海量数据存储咱们采纳了数据降精，宽表多维多指标等计划。咱们罕用的检测算法有恒值检测、渐变检测、同比检测等，同时还反对了无数据检测、多指标组合检测，检测呈现的异样咱们会造成一个问题，问题在通过一系列的收敛后收回告警，咱们有多种告警通道，反对告警合并、认领、降级等，须要展现的指标数据咱们提供了丰盛的自定义指标看板，对应用频率高 固化场景，咱们提供了模板化配置计划。有了齐备的监控体系，那么零碎的要害指标和监控对象体量如何？
1.4 监控零碎体量
以后监控服务体系保障着 x 万 + 的主机实例，x 万 + 的 DB 实例，每天解决 x 千亿条各类指标和日志，对 x 千 + 的域名做到秒级监控，对 x 万 + 的容器实例监控，每天从对立告警收回的各类告警达到 x 十万 +，对主机实例的监控覆盖率达到 x %，监控平台通过一直的摸索实际，实现了对海量数据计算存储，以后对外围业务的告警提早在 x 秒以内，告警召回率大于 x %。
1.5 监控零碎面临挑战
尽管现阶段获得了一些成绩，然而目前依然面临很多挑战，次要分为三大类：
- 部署环境简单
对数以万计的主机和容器，实时采集 计算是一项艰难的事件；面对各地机房监控，部署过程中依赖项多，保护工作简单；对海量数据计算存储，保障监控服务稳定性、可用性难度大。
- 平台零碎繁多
以后零碎还存在割裂，用户体验不强；数据割裂，没有从底层交融在一起，对于数据组合应用造成挑战。
- 新技术挑战
首先基于容器的监控计划，对传统监控计划造成挑战，以后对 Prometheus 指标存储处在摸索阶段，临时没有规范的解决方案，然而面对快速增长的数据量，新组件的摸索试错老本绝对较高。
二、监控服务体系架构
2.1 产品架构
产品架构的能力服务层，咱们定义了采集能力、检测能力、告警能力等；性能层咱们对这些能力做了具体实现，咱们将监控分为主机、容器、DB 等 9 类场景，展现层次要由 Dashboard 提供灵便的图表配置能力，日志核心负责日志查问，挪动端能够对告警信息进行认领、屏蔽。
2.2 技术架构
技术架构层分为采集、计算、存储、可视化几大块，首先在采集层咱们通过各种采集形式进行指标采集；上报的数据次要通过 Bees-Bus 进行传输，Bees-Bus 是一款公司自研的分布式、高可用的数据收集零碎，指标通过 Bees-Bus 之后写入 Kafka，随着 Pulsar 的受关注度与使用量的显著减少，咱们也在这方面进行了肯定的摸索；计算层咱们经验了 Spark、Flink、KafkaStream 几个阶段的摸索，根本实现了计算层技术栈收归到 KafkaStream；数据次要存储在 Druid，以后有 190+ 节点的 Druid 集群。Opentsdb 和 Hive 晚期利用在主机监控场景，随着业务倒退其性能曾经不能胜任以后的写入和查问需要，所以逐渐被舍弃。
以后咱们选用了 VictoriaMetrics 作为 Prometheus 的远端存储，日志信息存储在 ES 中，目前咱们有 250+ 的 ES 节点。服务层中各类监控场景的元数据，都由对立元数据服务提供；各类检测规定、告警规定都由对立配置服务保护，对立告警服务则负责告警的收敛、合并、发送等。Grafana 则次要用作自监控告警。
2.3 交互流程
在监控架构的根底上，咱们介绍一下整体交互流程，采集规定由对立元数据服务治理，并被动下发到 VCS-Master，VCS-Master 次要用来工作下发，Agent 执行后果数据接管，工作查问和配置管理等，Agent 会定期从 VCS-Master 拉取缓存的采集规定，指标通过 Bees-Bus 双写到 Kafka，由 ETL 程序对指标数据生产，而后做荡涤和计算，最初对立写入到存储服务中，对立配置服务下发检测规定到异样检测服务，检测出的异样信息推送到 Kafka，由告警代理服务对异样信息进行富化，解决好的数据推到 Kafka，而后由对立告警服务生产解决。在存储服务之上，咱们做了一层查问网关，所有的查问会通过网关代理。
三、可用性体系构建与保障
3.1 可用性体系构建
后面说了监控服务体系整体架构，那么监控产品如何服务于业务可用性。咱们将业务稳定性在时间轴上进行宰割，不同的时段有不同的零碎保障业务可用性，以后咱们次要关注 MTTD 和 MTTR，告警提早越小发现故障的速度也就越快，零碎培修工夫越短阐明零碎复原速度越快，咱们将 MTTR 指标拆解细化而后各个击破，最终达成可用性保障要求。vivo 监控服务体系提供了，涵盖在稳定性建设中须要的故障预防、故障发现等全场景工具包，监控平台提供了产品工具，那么与运维人员，研发人员是怎么合作配合的？
3.2 零碎可用性保障
当监控对象有问题时，监控零碎就会发送告警给运维人员或业务开发，他们通过查看相干指标修复问题。应用过程中运维人员的诉求和疑难，由监控平台产品和开发协同配合解决，咱们通过经营指标，定期梳理出不合理的告警，将对应的检测规定同步给运维同学，而后制订调整计划，前期咱们打算联合智能检测，做到零配置就能检测出异样指标。通过监控开发、运维人员和业务开发一起协同配合，保障业务的可用性。
3.3 监控零碎可用性
除了保障业务可用性外，监控零碎本身的可用性保障也是一个重要的课题。为了保障 Agent 存活，咱们构建了多种维活机制，保障端上指标采集失常。数据通过 Bees-Bus 之后，会双写到两个机房，当有一个机房呈现故障，会疾速切到另一个机房，保障外围业务不受损。数据链路的每一层都有自监控。监控平台通过 Grafana 监控告警。
3.4 简单场景下依靠监控解决问题伎俩 监控能力矩阵
随着公司业务倒退，业务模型、部署架构越来越简单，让故障定位很艰难，定位问题老本高。而监控零碎在面对简单、异构、调用关系简短的零碎时就起到了重要作用。在问题发现阶段，例如多服务串联调用，如果某个阶段，呈现耗时比拟大的状况，能够通过利用监控，升高问题排查难度。在告警告诉阶段，能够通过对立告警对异样对立收敛，而后依据告警策略，告诉给运维或者开发。问题定位时，能够利用故障定位服务找到最可能呈现问题的服务。解决问题时，相似磁盘打满这种比拟常见的故障，能够通过回调作业疾速排障。复盘改良阶段，故障治理平台能够对立治理，全流程复盘，使解决过程可追溯。预防演练阶段，在服务上线前，能够对服务进行压力测试，依据指标设置容量。
四、行业改革下的监控摸索实际及将来布局
4.1 云原生：Prometheus 监控
以后行业正迎来疾速改革，咱们在云原生、AIOps、可观性等方向均进行了摸索实际。将来咱们也想紧跟行业热点，持续深挖产品价值。随着 Kubernetes 成为容器编排畛域的事实标准，Prometheus 因为对容器监控良好的适配，使其成为云原生时代，容器监控的事实标准。上面咱们介绍一下整体架构，咱们将容器监控分为容器集群监控和容器业务监控，首先对于容器集群监控，每个生产集群都有独立的监控节点，用于部署监控组件，Prometheus 依照采集指标服务划分为多组，数据存储采纳 VictoriaMetrics，咱们简称 VM，同一机房的 Prometheus 集群，均将监控数据 Remote-Write 到 VM 中，VM 配置为多正本存储。通过拨测监控，实现对 Prometheus 自监控，保障 Prometheus 异样时能收到告警信息。容器业务监控方面，Agent 部署在宿主机，并从 Cadvisor 拉取指标数据，上报到 Bees-Bus，Bees-Bus 将数据双写到两个 Kafka 集群，对立检测服务异步检测指标数据，业务监控指标数据采纳 VM 做远端存储，Dashboard 通过 Promql 语句查问展现指标数据。
4.2 AIOps：故障定位
以后业界对 AIOps 的摸索，大部分在一些细分场景，咱们也在故障定位这个方向进行了摸索。剖析过程中首先通过 CMDB 节点树，选定须要剖析的我的项目节点，而后抉择须要剖析的时段，就能够按组件和服务下钻剖析，通过计算得出每个上游服务的稳定方差，再利用 K -Means 聚类，过滤掉稳定较小的聚类，找到可能出现异常的服务或组件。剖析过程会造成一张起因链路图，不便用户疾速找到异样服务，剖析后果会举荐给用户，告知用户最可能出现异常的起因。详情查看性能能够看到被调用的上游服务、接口名、耗时等信息。
4.3 可观测性：可用性大盘
因为 CNCF 在云原生的定义中提到了 Observerbility，所以近两年可观性，成了技术圈很炽热的关键词。以后业界基于 Metrics、Logs、Traces 对可观测性造成了肯定共识。谷歌也给出了可观测的外围价值就是疾速排障。咱们认为指标、日志、追踪是实现可观测性的根底，在此基础上将三者有机交融，针对不同的场景将他们串联在一起，实现方便快捷的查找故障根因，综上咱们建设了可用性大盘，它能查看服务的健康状况，通过下钻，能够看到上下游服务依赖关系、域名健康状况、后端服务散布等。通过串联跳转等形式能够看到对应服务的日志和指标信息。
4.4 场景串联
将来咱们心愿在场景串联、可观测性、服务能力化进一步摸索，深挖产品价值。场景串联上：
- 首先咱们心愿告警可能与故障定位平台串联，帮忙用户疾速找到故障根因，缩短排查工夫；
- 告警记录可能一键转为事件，缩小数据链路中人为操作的环节，保障数据的真实性；
- 咱们心愿能与 CMDB 等平台买通，将数据价值最大化。
4.5 对立可观测
当初，vivo 监控服务体系的可观测产品没有齐全交融在一起，所以后续咱们心愿构建对立可观测平台：
- 在一元场景中，能够独自查看指标、日志、追踪信息；
- 在转化场景中，可能通过日志取得指标数据，对日志的聚合和转化失去追踪，利用调用链的剖析，取得调用范畴内的指标。通过指标、日志、追踪多个维度找到故障的源头；
- 在二元场景，咱们心愿日志和指标、日志和追踪、追踪和指标可能互相联合，聚合剖析。
4.6 能力服务化
目前监控有很多服务，在公司构建混合云平台的大背景下，监控零碎的服务应该具备以能力化的形式提供进来。将来咱们心愿指标、图表、告警等，以 API 或者独立服务的形式提供能力，例如在 CICD 服务部署过程中，就能够通过监控提供的图表能力，看到服务部署时要害指标变动状况，而不须要跳转到监控服务查看指标信息。
最初，咱们心愿监控能更好的保障业务可用性，在此基础上，咱们也心愿通过监控零碎晋升业务服务质量。