Alauda Container Platform
  • 简体中文

    • 监控模块架构

    目录

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

    总体架构说明

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

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

    监控系统

    数据采集与存储

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

    数据查询与可视化

    1. 监控数据查询流程：

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

    2. 监控 dashboard 管理流程：

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

    3. Perses dashboard 查询流程：

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

      • 控制台通过 Alauda Container Platform Dashboard for Perses 向部署在 global 集群中的 Perses server 发送 dashboard 请求。

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

      • 部署在 global 集群中的 Alauda Container Platform Dashboard Essentials 提供的 observe-api 会先检查用户的 cluster、namespace 和 project 权限，然后再将查询转发到平台指标存储。所选的 workload cluster 是指标查询目标，但它不会运行本地的 Perses server 或 observe-api。

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

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

      Perses dashboards 在查询和渲染路径中引入了 observe-api、Perses server 和 perses-operator。Perses server 和 observe-api 仅运行在 global 集群中。workload cluster 可按需安装 Perses operator，以提供 PersesDashboard CRD 并保存其自身的 dashboard 资源。现有的 MonitorDashboard 能力仍然可用，并继续使用现有的 MonitorDashboard 管理路径。

    告警系统

    告警规则管理

    告警规则配置流程如下：

    1. 用户访问 global 集群的 ALB（Path: /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. 管理相关资源：
      • Notification Template: apiVersion: "ait.alauda.io/v1beta1", kind: "NotificationTemplate"
      • Notification Contact Group: apiVersion: "ait.alauda.io/v1beta1", kind: "NotificationGroup"
      • Notification Policy: 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 负责：
      • 校验通知服务器配置的合法性