一、建设背景及问题随着分布式云原生、容器化、微服务、大数据技术的成熟和普及，生产系统架构正朝着微服务、容器化方向转型，这给监控运维带来了以下问题和挑战：大量分布式新技术和缺乏监控标准：如容器、pod、部署在K8s、微服务的API网关、熔断器、服务治理等，急需梳理出这类分布式新技术的监控标准。环境的动态性变得更强：分布式对象是动态变化的，例如容器和Pod的创建、销毁和迁移。传统的监控工具无法处理云环境中对象的动态发现和更新，也无法提前配置。监控数据量激增：监控指标数量随着容器规模的增长呈爆发式增长，海量监控对象的高频采集和处理成为新的挑战。业务架构趋于复杂：在云原生应用架构下，原本单一的系统变成了众多微服务的协同，单个用户请求会经过多个微服务应用，形成复杂的调用链路，这就导致了难度排查和定位问题。带来了困难和挑战。分布式系统的可观察性分为指标（指标）、链接和日志。指标监控是基于基础指标数据（如CPU、内存、响应时间、调用量等），是一种比较传统、应用广泛的监控方式；链接跟踪解决了服务之间复杂的调用以及性能和耗时分析问题；日志监控监控系统运行过程数据：如关键统计信息、警告、错误等，这三种方式共同完成对分布式系统的整体监控。链路监控和日志监控是分布式日志中心的建设范畴。本文主要关注分布式系统的指标监控。下面所说的分布式监控仅限于分布式指标监控类。统一监控平台目前使用的Zabbix、ITM、Nagios等传统监控工具在容器云等分布式动态环境中难以实现监控。因此，迫切需要采用一种新技术来解决分布式系统的监控问题。开展分布式监控，需要重点解决以下问题：分布式监控标准的梳理和制定；分布式系统监控工具的选择；分布式监控管理平台的设计与开发。维护和管理分布式监控标准，驱动和管理分布式监控工具。下面我们一一介绍。2、分布式标准的制定在梳理分布式监测标准的过程中，我们采用以下四个原则，制作出如下图所示的分布式指标体系：重点丰富的监测标准。统一监控标准：无论传统平台还是容器云平台，对同一类对象的监控标准必须统一，确保指标全覆盖。相似对标：对于同类型的监控对象，需要对原相似类型的监控对象进行对标。例如，新推出的开源中间件需要对标传统的WebLogic监控标准。持续优化：敏捷迭代，对原有监控规范不断补充完善。分布式指标体系层次图明确了各个层次和各个组成部分的监控指标。由于篇幅原因，这里就不展开了。3.平台概述分布式监控平台是统一监控平台的一个子系统，负责对分布式和云原生系统的监控。该平台主要分为四个层次：监控工具层、存储层、处理层和管理平台层。监控对象的自动发现、数据采集、告警判断、性能数据存储在本地，同时实时发送给存储层的Kafka，为后续的数据分析提供数据源。处理层负责连接监控管理层和工具层，主要包括工具驱动、实时数据处理、告警处理、Prometheus本地数据实时查询四个功能模块。工具管理与驱动：将监控管理层的指令转换为PrometheusOperator接口API，驱动相应的Prometheus工具，如自动发现配置、采集指标配置、采集频率、告警配置（指标、阈值、告警时长）、告警级别、性能数据存储配置等实时数据处理：对性能数据进行实时时间戳转换、异常清洗、数据格式化和标准化处理、InfluxDB存储格式适配等，最终发送到InfluxDB中存储层，用于历史存储，供后续监控视图展示和问题定位查询使用。告警处理：通过搭建AlertManager集群和自研告警处理模块，两者相互配合，实现告警的统一集中处理。Prometheus本地数据实时查询：接收管理平台请求，获取对应的Prometheus本地性能数据，按需提取字段，样本点稀释，数据聚合等。管理平台层由接口层，指标&指标实现管理组成，策略管理、规则管理、标签管理、工具管理、驱动管理、监控评估、监控视图展示、告警管理。接口层提供统一的入口，实现监控信息的全貌展示，提供便捷的管理支持和任务分发。四、平台关键技术点1、构建高可用、高性能、可扩展的分布式监控工具考察了业界众多开源监控系统，如Prometheus、OpenFalcon、Nightingale，最终选择Prometheus，因为它原生支持K8s监控：具备k8s对象服务和分布式系统对象的发现能力，k8核心组件和众多提供Prometheus集合接口。性能强大：采用go语言开发，v3版本支持每秒千万级指标的采集和存储，可以满足一定规模的k8s集群的监控需求。良好的查询能力：PromQL提供了大量的数据计算函数，需要的聚合数据可以通过PromQL进行查询。不依赖外部存储：自带高性能本地时序数据库，实现采集数据本地存储，并可连接第三方存储实现历史数据存储。当然，Prometheus也有它的缺点，那就是：Prometheus不支持集群部署，单机处理能力有限，缺乏高可用和可扩展性。Prometheus本地存储能力有限，无法满足长时间范围内历史数据的存储和查询。缺乏平台化和自助管理能力，不支持通过API进行监控配置（尤其是监控目标的管理和告警规则的管理），没有多实例管理的手段。针对Prometheus的不足，我们做了一些扩展和整合：缺乏高可用：在分布式监控集群中，每个Prometheus监控实例以主备方式部署，同一个监控对象同时有两个Prometheus进行监控，任何PrometheusInstance故障都不会影响监控系统的整体功能。不支持集群，单机处理能力受限：设计实现基于标签的可扩展机制，支持K8s下Prometheus工具实例动态增删和独立部署，动态调整分配采集目标，实现可扩展监控能力。支持功能分区和水平扩展。所谓功能分区，就是不同的Prometheus负责监控不同的对象。比如PrometheusA负责监控K8s组件，PrometheusB负责监控部署在容器云上的应用。水平扩张是一个极端的例子。一个采集任务的目标数量也变得非常庞大。这时候功能分区就不能有效处理了。可以进行水平分区，将同一任务的不同实例的采集任务划分到不同的Prometheus中。本地存储容量有限：将Prometheus性能数据实时写入Kafka，再通过Flink流式计算实时消费到InfluxDB。利用InfluxDB的分布式可扩展性，解决了单个Prometheus本地存储的局限性。缺乏平台和自助管理能力：引入PrometheusOperator以API方式管理Prometheus、监控规则、监控对象、AlertManager等K8s监控资源。开发分布式监控管理平台，提供图形化监控标准配置管理界面，实现自助式、自动分发。详情将在后面的章节中介绍。2.标准化和自助服务建立标准化的分布式监控标准管理模式。基于标签在K8s和Prometheus中的重要作用（K8s基于标签分类管理资源对象；PromQL基于标签做数据聚合；PrometheusOperator基于标签匹配监控对象和监控规则），所以一套分布式的管理模型具体包括监控标签、监控工具、指标实现、指标、监控策略、监控规则，如下图所示。通过分布式监控平台的实现，实现了同类对象的标准化监控。分布式监控标准模型图，打通运维和研发壁垒，实现代码即监控。监控管理员提前内置监控规则。开发上线时，实现监控只需要做两点：自研应用提供指标采集接口，公共开源组件以sidecar方式部署相应的exporter暴露采集接口；productionServiceyml配置具体对象类型标签信息（nginx、tomcat、Kafka、Javaapplication、goapplication、Redis等）。驱动模块根据Serviceyml驱动Prometheus，实现生产对象的配置和发现，并根据预设规则进行监控。示例如下图所示：标准化和自助配置下发监控规则流程示例图3集中统一管理集中告警处理集群搭建：搭建AlertManager告警处理集群，实现告警集中统一管理。告警的初步处理是通过AlertManager的分组、抑制、静音实现的，但是AlertManager现有的功能不满足以下实际生产需求：告警持续2小时未恢复，更高-级别告警再次产生（告警升级）；告警转化为Syslog接入统一监控平台；同一告警连续发生时，半小时内只产生一次告警（告警压缩）；集群和应用系统维度的汇总告警；根据具体场景进行根因定位，比如主节点宕机导致其上的K8s核心组件不可用，产生主节点宕机根因告警（alarmrootcauselocation）。报警二次处理模块：基于Go语言自研高性能报警处理模块，提供webhook接口供AlertManger调用。接口实现的功能包括：丰富的告警字段、告警压缩、告警升级、告警汇总、告警根因提示、告警转syslog并发送至统一监控平台。Adapter改造：基于开源的PrometheusKafkaAdapter进行改造，保证海量性能数据实时写入Kafka，用于后续的数据分析和数据价值利用，如动态基线计算、异常检测等。Adapter工作图适配当前KafkaSASL/PLAINTEXT认证方式，对采集数据进行压缩以节省带宽，调优Kafka写入性能参数以应对大并发数据量的实时写入。设计Adapter主备模式，避免数据重复。如果主Adapter的健康检查能够通过，并且主Adapter对应的Prometheus运行正常，则使用主Adapter向Kafka传输数据，备Adapter停止工作；如果主Adapter或者主Adapter对应的Prometheus健康检查失败，则使用备Adapter传递数据，并通知管理员Prometheus和主Adapter失败。流处理模块：基于Flink自研的流处理模块，保证海量性能数据的实时处理和存储。流处理的内容包括：时间戳处理（Prometheus默认使用UTC时间）、异常数据清洗、数据格式化和标准化处理、InfluxDB存储格式适配。告警和性能数据集中处理架构图5.总结在平台建设中，我们借鉴了同行和互联网企业容器云K8s的相关建设经验，基于开源技术自主研发，构建了一个立体的、集中的、平台化的基于、标准化的分布式监控平台和系统具有以下特点：自动发现：动态环境的自动发现和监控；高性能：海量对象秒级采集处理，T级数据日常处理，弹性扩展；自动化&自助服务：避免针对特定的监控对象，一项一项地手动配置，灵活性差，容易误操作和漏操作，维护成本高；研发运维打通：监控迁移到设计开发阶段，研发暴露指标&自配置生产yml和策略实现分布式监控；自主可控：基于开源的Prometheus技术自主研发。目前分布式监控平台已于11月初在G-line投产，实现对G-line容器云生产集群的全面监控，实现海量对象秒级处理，平均处理T级数据每天，报警准确率和召回率均为100%，系统运行稳定，监控效果达到预期。六、后续工作展望平台一期建设实现了对容器云和基于云的应用和服务的监控。下一步将扩展分布式监控的管理范围，实现分布式数据库、全栈云管理平台、分布式消息传递。监控和管理。监控自助能力建设，封装部分自助监控场景：如监控在线和离线、监控规则修改、个性化监控配置等。监控评估功能展示分布式系统的监控覆盖率和标准化率。以量化的方式，以评价促改革，形成闭环。分布式监控工具的自我优化，比如Prometheus的自动负载均衡，基于一些预警数据，智能扩缩Prometheus实例数量，自动分配采集对象，达到最佳的监控能力。与自动化运维运营平台联动，实现部分场景的自动化处置。
