Alauda Container Platform
  • 简体中文

    • 监控模块架构

    目录

    整体架构说明监控系统数据采集与存储数据查询与可视化告警系统告警规则管理告警处理工作流实时告警状态通知系统通知配置管理通知服务器管理

    整体架构说明

    监控系统由以下核心功能模块组成：

    1. 监控系统
      • 数据采集与存储：从多个来源采集并持久化监控指标
      • 数据查询与可视化：为监控数据提供灵活的查询和可视化能力
    2. 告警系统
      • 告警规则管理：配置和管理告警策略
      • 告警触发与通知：评估告警规则并发送通知
      • 实时告警状态：提供系统当前告警状态的实时视图
    3. 通知系统
      • 通知配置：管理通知模板、联系人组和策略
      • 通知服务器：管理各种通知渠道的配置

    监控系统

    数据采集与存储

    1. Prometheus/VictoriaMetrics Operator 职责：
      • 加载并验证监控采集配置
      • 加载并验证告警规则配置
      • 将配置同步到 Prometheus/VictoriaMetrics 实例
    2. 监控数据来源：
      • Nevermore：生成与日志相关的指标
      • Warlock：生成与事件相关的指标
      • Prometheus/VictoriaMetrics：通过 ServiceMonitor 发现并采集各种 exporter 的指标

    数据查询与可视化

    1. 监控数据查询流程：

      • 浏览器发起查询请求（路径：/platform/monitoring.alauda.io/v1beta1）
      • ALB 将请求转发到 Courier 组件
      • Courier API 处理查询：
        • 内置指标：通过指标接口获取 PromQL 并执行查询
        • 自定义指标：将 PromQL 直接转发到监控组件
      • 监控面板获取数据并进行展示

    2. 监控面板管理流程：

      • 用户访问 global 集群 ALB（路径：/kubernetes/cluster_name/apis/ait.alauda.io/v1alpha2/MonitorDashboard）
      • ALB 将请求转发到 Erebus 组件
      • Erebus 将请求路由到目标监控集群
      • Warlock 组件负责：
        • 验证监控面板配置的合法性
        • 管理 MonitorDashboard CR 资源

    3. Perses 面板查询流程：

      • 用户在控制台中打开 Operations Center > Monitor > Dashboards (Perses)。

      • 控制台将面板请求发送到由 Alauda Container Platform Dashboard 部署在 global 集群中的 Perses 服务器。

      • Perses 服务器使用固定的 acp-observe 数据源，通过 observe-api 查询指标。

      • observe-api 由 Alauda Container Platform Dashboard Essentials 部署在 global 集群中，会在将查询转发到平台指标存储之前检查用户的集群、命名空间和项目权限。选定的业务集群是指标查询目标，但不会运行本地 Perses 服务器或 observe-api。

      • 平台指标存储（例如 VictoriaMetrics 或 Prometheus）将查询结果返回到面板。

        User -> Console Perses dashboard -> Perses server -> observe-api
     -> Platform metric storage -> Dashboard

    Perses 面板将 observe-api、Perses 服务器和 perses-operator 引入查询与渲染路径。Perses 服务器和 observe-api 仅运行在 global 集群中。业务集群会根据需要安装 Perses operator，以提供 PersesDashboard CRD 并存储其自身的面板资源。现有的 MonitorDashboard 功能仍然可用，并继续使用现有的 MonitorDashboard 管理路径。

    告警系统

    告警规则管理

    告警规则的配置流程：

    1. 用户访问 global 集群 ALB（路径：/kubernetes/cluster_name/apis/monitoring.coreos.com/v1/prometheusrules）
    2. 请求经过 ALB -> Erebus -> 目标集群 kube-apiserver
    3. 各组件的职责：
      • Prometheus/VictoriaMetrics Operator：
        • 验证告警规则的合法性
        • 管理 PrometheusRule CR
      • Nevermore：监听并处理日志告警指标
      • Warlock：监听并处理事件告警指标

    告警处理工作流

    1. 告警评估：
      • PrometheusRule/VMRule 定义告警规则
      • Prometheus/VictoriaMetrics 定期评估规则
    2. 告警通知：
      • 告警触发后发送到 Alertmanager
      • Alertmanager -> ALB -> Courier API
      • Courier API 负责分发通知
    3. 告警存储：
      • 告警历史记录存储在 ElasticSearch/ClickHouse 中

    实时告警状态

    1. 状态采集：
      • global 集群中的 Courier 生成指标：
        • cpaas_active_alerts：当前活动告警
        • cpaas_active_silences：当前静默配置
      • Global Prometheus 每 15 秒采集一次
    2. 状态显示：
      • 前端通过 Courier API 查询并显示实时状态

    通知系统

    通知配置管理

    通知模板、通知联系人组和通知策略的管理流程如下：

    1. 用户通过浏览器访问 global 集群的标准 API
      • 访问路径：/apis/ait.alauda.io/v1beta1/namespaces/cpaas-system
    2. 管理相关资源：
      • 通知模板：apiVersion: "ait.alauda.io/v1beta1", kind: "NotificationTemplate"
      • 通知联系人组：apiVersion: "ait.alauda.io/v1beta1", kind: "NotificationGroup"
      • 通知策略：apiVersion: "ait.alauda.io/v1beta1", kind: "Notification"
    3. Courier 负责：
      • 验证通知模板的合法性
      • 验证通知联系人组的合法性
      • 验证通知策略的合法性

    通知服务器管理

    1. 用户通过浏览器访问 global 集群的 ALB
      • 访问路径：/kubernetes/global/api/v1/namespaces/cpaas-system/secrets
    2. 管理并提交通知服务器配置
      • 资源名称：platform-email-server
    3. Courier 负责：
      • 验证通知服务器配置的合法性