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

October 12, 2020 架构设计 Prometheus, Kubernetes, 监控, 架构演进 2163 字 5 分钟阅读

前情概述：

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

架构设计

跨地域的三层结构设计

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

mermaid
graph TB
    subgraph Region 地域层
        TQR@{ shape: rounded, label: "Thanos Query Region" }
    end
    subgraph Zone 可用区层
        TQZ1@{ shape: rounded, label: "Thanos Query Zone A" }
        TQZ2@{ shape: rounded, label: "Thanos Query Zone B" }
    end
    subgraph Cluster / VPC
        P1@{ shape: rounded, label: "Prometheus" }
        P2@{ shape: rounded, label: "Prometheus" }
        P3@{ shape: rounded, label: "Prometheus" }
        P4@{ shape: rounded, label: "Prometheus" }
    end
    TQR --> TQZ1
    TQR --> TQZ2
    TQZ1 --> P1
    TQZ1 --> P2
    TQZ2 --> P3
    TQZ2 --> P4

用`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对接各个边缘组件。准实时同步状态信息和后台管理策略。

mermaid
graph TB
    subgraph 监控平台
        subgraph 管理层
            SD@{ shape: rounded, label: "Self-research Service Discovery 服务发现" }
            CR@{ shape: doc, label: "Conf/Rule Sync 配置/规则同步" }
            MR@{ shape: rounded, label: "msg route agent 消息路由" }
        end
        subgraph 边缘层
            PS@{ shape: rounded, label: "P-sidcar 边缘采集管理" }
            AS@{ shape: rounded, label: "A-sidcar 告警管理" }
        end
    end
    CMDB@{ shape: hex, label: "CMDB/CICD 第三方系统" } -->|资源同步| SD
    SD -->|资源信息| PS
    CR -->|采集策略| PS
    CR -->|告警策略| AS
    CR -->|责任人信息| MR
    SD -->|告警责任人| MR
    PS -->|http_sd| P@{ shape: rounded, label: "Prometheus" }
    AS -->|配置管理| AM@{ shape: rounded, label: "Alertmanager" }
    MR -->|推送| IM@{ shape: double-circle, label: "飞书/钉钉等" }

进阶扩展

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

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

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

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

统一告警系统

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

mermaid
graph LR
    subgraph 告警配置与管理
        AC@{ shape: rounded, label: "告警配置" } -->|规则| AG@{ shape: diam, label: "告警生成" }
        SC@{ shape: rounded, label: "告警静默" }
        IN@{ shape: rounded, label: "告警抑制" }
        PM@{ shape: rounded, label: "责任人管理" }
        DM@{ shape: rounded, label: "值班管理" }
    end
    AG --> AR@{ shape: diam, label: "告警接收" }
    AR --> GP@{ shape: diam, label: "告警分组" }
    GP --> DQ@{ shape: diam, label: "告警去重" }
    DQ --> RT@{ shape: diam, label: "告警路由" }
    SC --> RT
    IN --> RT
    PM --> RT
    DM --> RT
    RT --> NT@{ shape: diam, label: "告警通知" }
    NT --> EML@{ shape: doc, label: "邮件" }
    NT --> FS@{ shape: rounded, label: "飞书" }
    NT --> DT@{ shape: rounded, label: "钉钉" }
    NT --> SMS@{ shape: doc, label: "短信" }
    NT --> PHN@{ shape: doc, label: "电话" }
    NT --> WH@{ shape: doc, label: "Webhook" }