经过几年的平台建设，vivo监控平台的产品矩阵日趋完善。vivo终端庞大的用户群下，承载业务运营的服务众多，而监控服务系统是业务可用性保障的重要一环，监控产品全场景覆盖生产环境的方方面面。监控服务平台提供了丰富的事前发现、事中告警、定位、恢复、事后回顾总结的工具包。从之前的横向拆分、场景化建设，到后来的纵向拆分、融合统一，减少了平台的碎片化感。同时，监控平台也在可观察性、AIOps、云原生等方面进行了搭建和实践。未来，vivo监控平台将朝着全场景、一站式、全链路、智能化的方向不断探索和前行。监控服务平台是自主研发的覆盖全场景的可用性保障体系。经过多年深耕细作，vivo监控团队系统地构建了一套完整的稳定性保障体系。随着云原生可观察技术变革的不断深入，监控团队如何前行？下面简单介绍平台的建设过程、思考和探索。1.监控系统搭建方式1.1监控搭建过程回顾监控搭建过程，最初是使用Zabbix结合报警中心实现简单的监控。随着业务的发展和监控场景的复杂化以及数据量的增加，这种简单的组合变得过于捉襟见肘。于是从2018年开始，我们开始了自研之路。一开始我们构建了应用监控、日志监控、拨测监控，解决了很大一部分监控场景没有覆盖的问题；2019年我们做了基础监控和自定义监控。等，完成了主要监控场景的基本覆盖；2020年，在完善早期监控产品的同时，进一步打造周边产品；随着AI技术的不断成熟，我们从2021年开始也进行了转型升级，先后搭建了故障定位平台和统一告警平台，我们发现为了进一步提升平台的价值，数据和数据的统一平台很重要；所以从2022年开始，我们开始搭建统一的监控平台，就是统一基础监控、应用监控和自定义监控，统一监控包括统一配置服务和统一检测服务。从监控建设过程来看，一路走来涵盖了IaaS、PaaS、DaaS、CaaS等平台。我们的职能也在从DevOps转向AIOps。1.2监控能力矩阵描述了监控的发展历史，那么这些监控产品在我们的生产环境中是如何分布的呢？为了支撑数以万计的业务运营，需要复杂的系统支持。服务器、网络环境、基础组件都需要监控系统来保证其稳定性。我们将监控对象分为五层。在基础设施层，包括网络设备、服务器、存储硬件等。在这一层，我们通过VGW监控来监控网络设备。VGW是VivoGateway的缩写，类似LVS；通过自定义监控，对机房进行监控；在系统服务器层，我们定义的监控对象是服务运行所依赖的环境，通过主机监控来监控物理机、虚拟机等。当前容器已经成为微服务运行的最佳载体，因此对容器的监控必不可少；系统服务层包括各种数据库产品、大数据组件等，在这一层主要通过自定义监控检测告警；业务应用层，主要是应用服务，我们通过应用监控来监控业务链路信息；在客户体验层，我们定义端接入质量，由Zeus平台监控。前面我们讲了监控能力矩阵，下面详细介绍一下监控的范围和整个平台的能力。1.3监控对象范围监控对象包括网络、主机和基础服务。面向各地的机房，实现了全监控覆盖。为了满足各种环境的部署需求，我们可以监控不同的环境。我们支持多种收集方式。SDK和API采集主要用于自定义监控场景。Agent主要收集主机类型的指标。将采集到的时序数据进行预聚合，统一数据清洗，然后存储到TSDB数据库中。针对海量数据存储，我们采用了数据归约、宽表、多维度、多指标等解决方案。我们常用的检测算法有常值检测、突变检测、同比检测等，同时还支持无数据检测和多指标组合检测。我们在检测异常的时候会形成一个问题。经过一系列收敛后，就会发出告警。我们有多种告警通道，支持告警合并、认领、升级等。我们为需要展示的指标数据提供丰富的自定义指标仪表盘，针对使用频率高的场景提供模板化的配置方案.一个完整的监控系统，系统的关键指标和监控对象的规模有哪些？1.4监控系统量目前监控服务系统每天保障x万+个主机实例，x万+个DB实例，每天处理x千亿条各类指标和日志，秒级监控x千+个域名。监控x万+个容器实例，每天统一告警发出的各种告警达到x00万+，主机实例监控覆盖率达到x%。通过不断的探索和实践，监控平台实现了海量数据的计算和存储，目前核心业务的告警延迟在x秒以内，告警召回率大于x%。1.5监测体系面临挑战。现阶段虽然取得了一些成绩，但仍面临诸多挑战，主要分为三类：部署环境复杂，对于数以万计的主机和容器，实时获取和计算是一项艰巨的任务;面对各个机房的监控，部署过程中依赖较多，维护工作复杂；海量数据的计算和存储，难以保证监控服务的稳定性和可用性。有很多平台和系统。目前的系统还是碎片化的，用户体验不强；数据是碎片化的，没有从底层整合，这对数据的结合使用提出了挑战。新的技术挑战首先，基于容器的监控方案对传统监控方案提出了挑战。目前Prometheus指标存储处于探索阶段，暂时没有标准方案。然而，面对快速增长的数据量，探索新组件的试错成本相对较高。2.监控服务系统架构2.1产品架构在产品架构的能力服务层，我们定义了采集能力、检测能力、告警能力等；我们在功能层实现了这些能力，我们把监控分为主机、容器和DB。9类场景，展示层主要由具有灵活图表配置能力的Dashboard提供，日志中心负责日志查询，移动端可以对告警信息进行认领和屏蔽。2.2技术架构技术架构层分为采集、计算、存储、可视化。首先，我们在采集层通过各种采集方式采集指标；上报数据主要通过Bees-Bus传输，Bees-Bus是公司自研的分布式高可用数据采集系统，指标通过Bees-Bus写入Kafka。随着Pulsar的关注度和使用量的显着增加，我们也在这方面进行了一定的探索；我们在Spark、Flink、KafkaStream经历了几个阶段的探索，基本实现了将计算层技术栈集合到KafkaStream中；数据主要存储在Druid中，目前Druid集群中有190+个节点。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.可用性体系建设与保障3.1可用性体系建设前面提到了监控服务系统的整体架构，那么监控产品是如何服务于业务可用性的。我们在时间轴上划分业务稳定性。不同的系统保障不同时期的业务可用性。目前我们主要关注MTTD和MTTR。告警延时越小，故障发现越快，系统维护时间越短。系统恢复越快，我们将MTTR指标拆解细化，逐一分解，最终满足可用性保障要求。vivo监控服务系统提供全场景工具包，涵盖维稳建设所需的故障预防和故障发现。监控平台提供了产品工具，那么运维人员和研发人员如何配合呢？3.2系统可用性保证当监控对象出现问题时，监控系统会向运维人员或业务开发人员发出告警，他们会通过查看相关指标来解决问题。运维人员在使用过程中的诉求和疑问，通过监控平台产品与开发的协同解决。我们通过运维指标定期梳理不合理的告警，将相应的检测规则同步给运维同学，进而制定调整方案。后期计划结合智能检测，零配置检测异常指标。通过监控开发，运维人员和业务开发人员协同工作，保证业务可用性。3.3监控系统可用性除了保证服务可用性外，监控系统本身的可用性保证也是一个重要问题。为了保证Agent的存活，我们构建了多种维护机制来保证端上指标的正常采集。数据经过Bees-Bus后，会双写到两个机房。当一个机房出现故障时，会迅速切换到另一个机房，确保核心业务不受损。数据链路的每一层都是自我监控的。监控平台通过Grafana监控告警。3.4依靠监控解决复杂场景问题监控能力矩阵随着公司业务的发展，业务模型和部署架构越来越复杂，故障定位难度大，成本高。面对复杂、异构、冗长的调用系统，监控系统发挥着重要作用。在问题发现阶段，比如多服务串口调用，如果某个阶段耗时较长，可以通过应用监控来降低排查难度。在告警通知阶段，可以通过统一告警统一收敛异常，然后根据告警策略通知运维或开发。在定位问题时，可以使用故障定位服务，找到最有可能导致问题的服务。解决问题时，可以通过回调作业快速排除磁盘满等常见故障。检讨改进阶段，可统一管理故障管理平台，全程检讨，实现解决过程可追溯。在预防演练阶段，在业务上线前，可以对业务进行压力测试，根据指标设置容量。4.行业变革下的监控探索实践与未来规划4.1云原生：Prometheus监控当前行业正在发生快速变化。我们在云原生、AIOps、可观察性等方向进行了探索和实践。未来，我们也想紧跟行业热点，继续深挖产品价值。随着Kubernetes成为容器编排领域的事实标准，Prometheus也因为对容器监控的良好适配，成为云原生时代容器监控的事实标准。下面介绍一下整体架构。我们把容器监控分为容器集群监控和容器业务监控。首先，对于容器集群监控，每个生产集群都有一个独立的监控节点，用于部署监控组件。Prometheus根据采集目标服务划分为多个组，数据存储采用VictoriaMetrics，我们简称VM，同一机房的Prometheus集群将监控数据Remote-Write到VM，配置VM作为多副本存储。通过拨号监控，实现Prometheus的自我监控，当Prometheus异常时可以收到告警信息。在容器业务监控方面，Agent部署在宿主机上，从Cadvisor拉取指标数据，上报给Bees-Bus。Bees-Bus将数据双写到两个Kafka集群中。统一检测服务异步检测指标数据和业务监控指标数据。Dashboard使用VM作为远程存储，通过Promql语句查询和展示指标数据。4.2AIOps：故障定位目前业界对AIOps的探索多在一些细分场景，我们也在故障定位方向进行了探索。在分析过程中，首先通过CMDB节点树选择需要分析的项目节点，然后选择需要分析的时间段，然后按组件和服务进行下钻分析，计算每个下游服务的波动方差，然后使用K-Means聚类，过滤掉波动小的集群，找出可能异常的服务或组件。分析过程会形成原因链接图，方便用户快速查找异常服务。将分析结果推荐给用户，并告知用户最有可能出现异常的原因。通过详情查看功能，可以看到调用的下游服务、接口名称、耗时等信息。4.3Observability：可用性市场自从CNCF在云原生的定义中提到了Observability之后，Observability就成为近两年技术圈非常热门的关键词。目前业界对基于Metrics、Logs、Traces的可观察性已经形成了一定的共识。谷歌还赋予observable核心价值是快速故障排除。我们认为指标、日志和痕迹是可观察性的基础。在此基础上，我们将三者有机的结合起来，针对不同的场景将它们联系在一起，方便快捷的找到故障根源。综上所述，我们构建了可用性Dashboard，可以查看服务的健康状态。通过下钻，可以看到上下游服务的依赖关系、域名的健康状态、后端服务的分布情况。可以通过串口跳转等方式查看对应服务的日志和指标信息。4.4场景连接未来我们希望进一步挖掘场景连接、可观察性、服务能力，深挖产品价值。场景对接：首先希望告警能够与故障定位平台对接，帮助用户快速找到故障根源，缩短排查时间；可将报警记录一键转化为事件，减少数据链路中的人工操作，保证数据的真实性；我们希望对接CMDB等平台，实现数据价值最大化。4.5统一可观察性现在vivo监控服务系统的可观察产品还没有完全集成，所以我们希望未来能搭建一个统一的可观察平台：在一维场景下，可以分别查看指标、日志、跟踪信息;在转化场景中，可以通过日志获取指标数据，跟踪日志的聚合转化，利用调用链的分析获取调用范围内的指标。通过指标、日志、多维度跟踪，查找故障源头；在二元场景下，我们希望日志和指标、日志和痕迹、痕迹和指标相互结合进行聚合分析。4.6Capabilitiesasaservice目前有很多监控服务。在公司建设混合云平台的背景下，监控系统的服务要有能力地提供。未来我们希望可以将指标、图表、告警等作为API或者独立的服务来提供。例如在CICD服务部署过程中，可以通过监控提供的图表能力，查看服务部署过程中关键指标的变化，而无需跳转到监控服务查看指标信息。最后，我们希望监控能够更好的保证业务的可用性。在此基础上，我们也希望通过监控系统来提升业务服务质量。
