监控系统企业架构演进史-跨地域混合云

前情概述：

在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。 前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。 在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。

架构设计

跨地域的三层结构设计

设计三层区域结构，同时规范区域命名标签化来实现快速辨识服务的地域详细信息。 在第三层中的Cluster和VPC是同级，分别代表集群内或者某网段的隔离服务。

flowchart TD
    TQR["Thanos Query<br/>地域层"] --> TQZ1["Thanos Query<br/>可用区A"]
    TQR --> TQZ2["Thanos Query<br/>可用区B"]
    TQZ1 --> P["Prometheus<br/>集群/VPC x4"]
    TQZ2 --> P
    classDef src fill:#bbdefb,stroke:#2196F3,color:#1B5E20
    classDef proc fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef store fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class TQR src
    class TQZ1,TQZ2 proc
    class P store

地域层 Thanos Query 向下汇聚各可用区，可用区再向下对接各集群/VPC 内的 Prometheus。

用Thanos Query实现前期的层级架构

利用Thanos内的GRPC通讯协议和聚合查询能力来实现递级数据汇聚到最上层Thanos Query组件，再聚合计算时间线结果集前端展示。

引入Thanos Query Frontend完成统一前端查询入口

Thanos Query Frontend组件有以下配置能力优化查询，需根据实际情况调整：

• 时间线的纵向切割查询 比如查15天的数据，由于样本量的数据庞大，会在原始数据读取到内存时导致OOM问题。通过纵向切割比如把15天的聚合查询逻辑拆分成每6小时的聚合查询。 Thanos Query组件就会得到4 * 15个并发查询去完成样本查询并聚合成不同时间段的结果集再拼接展示，且每完成一个子查询聚合均及时释放内存高效优化了资源利用率。

• 查询结果集缓存 通过对查询语句和时间周期的HASH KEY缓存结果集到内存或者Redis以重复利用，减轻上游压力。

利用Kubernetes赋予更具弹性的冗余能力

自研架构组件

在基于原生开源项目的基础架构下，已基本实现对跨地域混合云的能力。但是要做到企业日常管理还远远不够，需要完善管理架构和前台能力才称得上企业服务。

基础设计逻辑

为了让整个架构具备灵活性和通用性，分别设计了几个组件：

• Self-research service discovery 用于对接第三方系统，比如CMDB，CICD等收集业务系统和资产信息，并计算各个业务系统和基建关联关系，通过地域信息来调度资源信息同步给P-sidcar组件。
• P-sidcar用于在边缘管理Prometheus，从 Self-research service discovery得到就近采集器的信息，以http_sd方式给Prometheus发现exporter采集的同时实现精细化label注入。
• msg route agent 用于对接飞书、钉钉等通讯服务，同时从Conf/Rule Sync同步告警的责任人以实现高效的最后一公里定向信息推送。
• A-sidcar 用于对Alertmanger集群的配置管理，并准实时同步抑制策略来对告警实现更精确的管理。
• Conf/Rule Sync对接各个边缘组件。准实时同步状态信息和后台管理策略。

flowchart TD
    CMDB@{ shape: hex, label: "CMDB/CICD<br/>第三方系统" } -->|资源同步| SD["服务发现<br/>+ 责任人路由"]
    CR@{ shape: doc, label: "Conf/Rule Sync<br/>配置规则同步" } --> EDGE["边缘 sidecar<br/>采集 + 告警管理"]
    SD --> EDGE
    EDGE -->|http_sd + 配置管理| P["Prometheus<br/>+ Alertmanager"]
    SD -->|推送| IM["飞书/钉钉等"]
    classDef src fill:#bbdefb,stroke:#2196F3,color:#1B5E20
    classDef proc fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef spec fill:#f3e5f5,stroke:#9C27B0,color:#4A148C
    classDef store fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class CMDB src
    class SD,EDGE proc
    class CR,IM spec
    class P store

第三方系统经服务发现向边缘分发资源与采集策略，告警策略与责任人由配置同步组件下发，最终推送至 IM 平台。

进阶扩展

底座设计尽量精而简，又不能失去灵活性。在此之上通过自研前台服务、中间件和边缘组件逐步丰富企业能力。

• 服务发现组件主打和各种三方系统对接，不限于CMDB/CICD系统，还可以对接工单系统或作业系统。
• 告警组件逐步升级为统一告警系统平台，和服务发现组件联动实现更高级的动态调度告警能力。
• 配置同步组件和Grafana逐步融合成前台系统，集管理和展示一体。

整个系统的用户侧切面逻辑如下图

到这个阶段，平台已经具备一定的复杂性了，但是对用户而言需要简化他们的理解。

统一告警系统

基本上监控平台发展到一定阶段，告警风暴问题必然会开始困扰企业内部各个技术支撑部门。告警收敛治理就会优先提上日程。 这个时候，告警的组件就可以从一开始的只是告警定向推送能力逐步丰富周边能力了。

flowchart TD
    CFG["告警配置<br/>静默/抑制<br/>责任人/值班"] -->|规则| AG@{ shape: diam, label: "告警生成" }
    AG --> RC@{ shape: diam, label: "接收/分组<br/>去重" }
    RC --> RT@{ shape: diam, label: "告警路由" }
    RT --> NT@{ shape: diam, label: "告警通知" }
    NT --> CH["邮件/飞书<br/>钉钉/短信<br/>电话/Webhook"]
    classDef src fill:#bbdefb,stroke:#2196F3,color:#1B5E20
    classDef spec fill:#f3e5f5,stroke:#9C27B0,color:#4A148C
    classDef store fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class CFG src
    class AG,RC,RT,NT spec
    class CH store

告警配置与治理策略（静默、抑制、责任人、值班）汇入告警生成，经分组去重与路由后，由通知环节分发到各消息渠道。