logo
Alauda Container Platform
English
简体中文
English
简体中文
logo
Alauda Container Platform
导航

产品概览

架构
发版日志

安装

安装概述

安装准备

前提条件
下载
节点预处理
安装
global 集群灾难恢复

升级

Overview
升级前准备
升级 global 集群
升级业务集群

用户界面

灵雀控制台

概览
访问 Web 控制台
Customizing the Web Console
Customizing the Left Navigation
CLI 工具

配置

功能开关配置

集群

概述
创建本地集群
etcd 加密
自动旋转 Kubernetes 证书

实用指南

为内置注册表添加外部地址
选择容器运行时
更新公共仓库凭证

网络

介绍

架构

理解 Kube-OVN
了解 ALB
了解 MetalLB

核心概念

认证
Ingress-nginx 注解兼容性
TCP/HTTP 保持连接
ModSecurity
不同 Ingress 方式的比较
HTTP 重定向
L4/L7 超时
GatewayAPI
OTel

功能指南

创建服务
创建 Ingress
配置网关
创建 Ingress-Nginx
创建域名
创建证书
创建外部 IP 地址池
创建 BGP Peers
配置子网
配置网络策略
创建 Admin 网络策略
配置集群网络策略

如何操作

为 ALB 部署高可用 VIP
软件数据中心负载均衡方案(Alpha)
准备 Kube-OVN Underlay 物理网络
Underlay 和 Overlay 子网的自动互联
在 ALB 中使用 OAuth Proxy
创建 GatewayAPI Gateway
配置负载均衡器
如何合理分配 CPU 和内存资源
将 IPv6 流量转发到集群内的 IPv4 地址
Calico 网络支持 WireGuard 加密
Kube-OVN Overlay 网络支持 IPsec 加密
ALB 监控
Application Load Balancer (ALB) 中的负载均衡会话亲和策略

故障排除

如何解决 ARM 环境中的节点间通信问题?
查找错误原因

机器配置

概览
使用 MachineConfig 管理节点配置
节点中断策略

存储

介绍

概念

访问模式与卷模式
核心概念
Persistent Volume

功能指南

创建 CephFS 文件存储类型存储类
创建 CephRBD 块存储类
创建 TopoLVM 本地存储类
创建 NFS 共享存储类
部署 Volume Snapshot 组件
创建 PV
创建 PVCs
使用卷快照

实用指南

设置 NFS 共享存储类的子目录命名规则
通用临时卷
使用 emptyDir
第三方存储能力注解指南

故障排除

从 PVC 扩容失败中恢复

存储

Ceph 分布式存储

介绍

安装

创建标准类型集群
创建 Stretch 类型集群
架构

核心概念

核心概念

操作指南

访问存储服务
管理存储池
节点特定组件部署
添加设备/设备类
监控与告警

实用指南

配置专用集群用于分布式存储
清理分布式存储

数据容灾

文件存储灾备
块存储灾难恢复
对象存储灾备
更新优化参数
创建 ceph 对象存储用户

MinIO 对象存储

介绍
安装
架构

核心概念

核心概念

操作指南

添加存储池
Monitoring & Alerts

实用指南

数据灾难恢复

TopoLVM 本地存储

介绍
安装

操作指南

设备管理
监控与告警

实用指南

使用 Velero 备份和恢复 TopoLVM 文件系统 PVC

安全

Alauda Container Security

安全性与合规性

合规

介绍
安装

使用指南

私有镜像仓库访问配置
Image Signature Verification Policy
使用 Secrets 的镜像签名验证策略
镜像仓库验证策略
容器逃逸防护策略
Security Context Enforcement Policy
网络安全策略
Volume Security Policy

API Refiner

介绍
安装

用户与角色

用户

介绍

功能指南

管理用户角色
创建用户
用户管理

用户组

介绍

功能指南

管理用户组角色
创建本地用户组
管理本地用户组成员资格

角色

介绍

功能指南

创建角色
管理自定义角色

IDP

介绍

功能指南

LDAP 管理
OIDC 管理

故障排除

删除用户

用户策略

介绍

多租户(项目)

介绍

功能指南

创建项目
管理项目
管理项目集群
管理项目成员

审计

介绍

遥测

安装

虚拟化

虚拟化

概览

介绍
安装

镜像

介绍

操作指南

添加虚拟机镜像
更新/删除虚拟机镜像
更新/删除镜像凭据

实用指南

使用 KubeVirt 基于 ISO 创建 Windows 镜像
使用 KubeVirt 基于 ISO 创建 Linux 镜像
导出虚拟机镜像
权限说明

虚拟机

介绍

操作指南

创建虚拟机/虚拟机组
虚拟机批量操作
使用 VNC 登录虚拟机
管理密钥对
管理虚拟机
监控与告警
虚拟机快速定位

实用指南

配置 USB 主机直通
虚拟机热迁移
虚拟机恢复
在 KubeVirt 上克隆虚拟机
物理 GPU 直通环境准备
配置虚拟机的高可用性
从现有虚拟机创建虚拟机模板

问题处理

虚拟机节点正常关机下的 Pod 迁移及异常宕机恢复问题
热迁移错误信息及解决方案

网络

介绍

操作指南

配置网络

实用指南

通过网络策略实现虚拟机网络请求控制
配置 SR-IOV
配置虚拟机使用网络绑定模式以支持 IPv6

存储

介绍

操作指南

管理虚拟磁盘

备份和恢复

介绍

操作指南

使用快照

开发者

快速开始

Creating a simple application via image

构建应用

核心概念

应用类型
Custom Applications
Workload Types
理解参数
理解环境变量
理解启动命令
资源单位说明

命名空间

创建命名空间
导入 Namespace
Resource Quota
Limit Range
Pod Security Admission
Overcommit Ratio
管理命名空间成员
更新命名空间
删除/移除命名空间

创建应用

Creating applications from Image
Creating applications from Chart
通过 YAML 创建应用
通过代码创建应用
Creating applications from Operator Backed
通过 CLI 工具创建应用

应用的操作与维护

Application Rollout

安装 Alauda Container Platform Argo Rollouts
Application Blue Green Deployment
Application Canary Deployment
状态说明

KEDA(Kubernetes Event-driven Autoscaling)

KEDA Overview
Installing KEDA

实用指南

Integrating ACP Monitoring with Prometheus Plugin
在 KEDA 中暂停自动扩缩容
配置 HPA
启动和停止原生应用
配置 VerticalPodAutoscaler (VPA)
配置 CronHPA
更新原生应用
导出应用
更新和删除 Chart 应用
应用版本管理
删除原生应用
健康检查

计算组件

Deployments
DaemonSets
StatefulSets
CronJobs
任务
Pods
Containers
使用 Helm charts

配置

Configuring ConfigMap
Configuring Secrets

应用可观测

监控面板
Logs
实时事件

实用指南

设置定时任务触发规则

镜像仓库

介绍

安装

通过 YAML 安装
通过 Web UI 安装

使用指南

Common CLI Command Operations
Using Alauda Container Platform Registry in Kubernetes Clusters

S2I

介绍

安装

Installing Alauda Container Platform Builds

升级

升级 Alauda Container Platform Builds
架构

功能指南

Managing applications created from Code

How To

通过代码创建应用

节点隔离策略

引言
架构

概念

核心概念

功能指南

创建节点隔离策略
权限说明
常见问题

GitOps

介绍

安装

Installing Alauda Build of Argo CD
Installing Alauda Container Platform GitOps

升级

Upgrading Alauda Container Platform GitOps
架构

核心概念

GitOps

Argo CD 核心概念

Argo CD Introduction
Application 概念
ApplicationSet 概念
Tool
Helm 概念
Kustomize 概念
Directory 概念
Sync 概念
Health 概念

Alauda Container Platform GitOps 核心概念

介绍
Alauda Container Platform GitOps 的同步及健康检查

功能指南

创建 GitOps 应用

Creating GitOps Application
Creating GitOps ApplicationSet

GitOps 可观测

Argo CD 组件监控
GitOps 应用运维

实用指南

通过 Argo CD Dashboard 集成代码仓库
通过 Argo CD dashboard 创建 Argo CD Application
通过平台创建 Argo CD Application
如何获取 Argo CD 访问信息
故障排查

扩展

Operator
集群插件

可观测性

概览

监控

介绍
安装

架构

监控模块架构
监控组件选型指南
核心概念

操作指南

指标管理
告警管理
通知管理
监控面板管理
探针管理

实用指南

Prometheus 监控数据的备份与恢复
VictoriaMetrics 监控数据备份与恢复
从自定义命名的网络接口采集网络数据

调用链

介绍
安装
架构
核心概念

操作指南

查询追踪
查询追踪日志

实用指南

Java 应用无侵入方式接入调用链
与 TraceID 相关的业务日志

问题处理

查询不到所需的调用链
调用链数据不完整

日志

介绍
安装

架构

日志模块架构
日志组件选型指南
日志组件容量规划
概念

操作指南

日志

实用指南

如何将日志归档至第三方存储
如何对接外部 ES 存储集群

事件

介绍
Events

巡检

介绍
架构

操作指南

巡检
Component Health Status

硬件加速器

概述

介绍
功能概览
安装

应用开发

介绍

功能指南

CUDA 驱动与运行时兼容性
使用 ConfigMap 添加自定义设备

故障排除

解决 vLLM 中 “float16 is only supported on GPUs with compute capability at least xx” 错误
Paddle Autogrow 内存分配在 GPU-Manager 上的崩溃问题

配置管理

介绍

功能指南

在 GPU 节点上配置硬件加速器

资源监控

介绍

功能指南

GPU 资源监控

Alauda 服务网格

关于 Alauda Service Mesh

Alauda AI

关于 Alauda AI

Alauda DevOps

关于灵雀云 DevOps

Alauda 计量计费

关于 Alauda 成本管理

Alauda 应用服务

概览

介绍
架构
安装
升级

Alauda Database Service for MySQL

关于 Alauda Database Service for MySQL-MGR
关于 Alauda Database Service for MySQL-PXC

Alauda Cache Service for Redis OSS

关于 Alauda Cache Service for Redis OSS

Alauda Streaming Service for Kafka

About Alauda Streaming Service for Kafka

Alauda Streaming Service for RabbitMQ

关于 Alauda Streaming Service for RabbitMQ

Alauda support for PostgreSQL

关于 Alauda support for PostgreSQL

运维管理

介绍

参数模板管理

介绍

功能指南

参数模板管理

备份管理

介绍

功能指南

外部 S3 存储
备份管理

检查管理

介绍

操作指南

创建巡检任务
Exec Inspection Task
更新和删除巡检任务

实用指南

如何设置检查调度?

检查优化建议

MySQL

MySQL IO负载优化
MySQL 内存使用优化
MySQL存储空间优化
MySQL 活动线程计数优化
MySQL 行锁优化

Redis

Redis 大键
Redis中的高CPU使用率
Redis中的高内存使用

Kafka

Kafka 中的高 CPU 利用率
Kafka Rebalance 优化
Kafka内存使用优化
Kafka 存储空间优化

RabbitMQ

RabbitMQ Mnesia 数据库异常处理

警报管理

介绍

操作指南

与平台能力的关系

升级管理

介绍

操作指南

示例升级

API 参考

概览

介绍
Kubernetes API 使用指南

Advanced APIs

Alert APIs

AlertHistories [v1]
AlertHistoryMessages [v1]
AlertStatus [v2]
SilenceStatus [v2]

Event APIs

Search

Log APIs

Aggregation
Archive
Context
Search

Monitoring APIs

Indicators [monitoring.alauda.io/v1beta1]
Metrics [monitoring.alauda.io/v1beta1]
Variables [monitoring.alauda.io/v1beta1]

Kubernetes APIs

Alert APIs

AlertTemplate [alerttemplates.aiops.alauda.io/v1beta1]
PrometheusRule [prometheusrules.monitoring.coreos.com/v1]

Inspection APIs

Inspection [inspections.ait.alauda.io/v1alpha1]

Notification APIs

Notification [notifications.ait.alauda.io/v1beta1]
NotificationGroup [notificationgroups.ait.alauda.io/v1beta1]
NotificationTemplate [notificationtemplates.ait.alauda.io/v1beta1]
📝 在 GitHub 上编辑此页
上一页指标管理
下一页通知管理

#告警管理

#目录

#功能概述

平台的告警管理功能旨在帮助用户全面监控并及时发现系统异常。通过利用预装的系统告警和灵活的自定义告警能力,结合标准化的告警模板和分级管理机制,为运维人员提供完整的告警解决方案。

无论是平台管理员还是业务人员,都可以在各自权限范围内方便地配置和管理告警策略,实现对平台资源的有效监控。

#主要功能

  • 内置系统告警策略:基于常见故障诊断思路,预设丰富的告警规则,适用于 global 集群和工作负载集群。
  • 自定义告警规则:支持基于多种数据源创建告警规则,包括预设监控指标、自定义监控指标、黑盒监控项、平台日志数据和平台事件数据。
  • 告警模板管理:支持创建和管理标准化告警模板,便于快速应用于相似资源。
  • 告警通知集成:支持通过多种渠道将告警信息推送给运维人员。
  • 告警视图隔离:区分平台管理告警和业务告警,确保不同角色人员关注各自的告警信息。
  • 实时告警查看:提供实时告警,集中展示当前处于告警状态的资源数量及详细告警信息。
  • 告警历史查看:支持查看一段时间内的历史告警记录,方便运维人员和管理员分析近期监控告警情况。

#功能优势

  • 全面的监控覆盖:支持对集群、节点、计算组件等多种资源类型的监控,内置丰富的系统告警策略,无需额外配置即可使用。
  • 高效的告警管理:通过告警模板实现标准化配置,提高运维效率;告警视图分离,便于不同角色人员快速定位相关告警。
  • 及时的问题发现:自动触发告警通知,确保问题及时发现,支持多渠道告警推送,实现主动防范问题。
  • 完善的权限管理:对告警策略严格访问控制,确保告警信息安全且可管理。

#通过 UI 创建告警策略

#前提条件

  • 已配置通知策略(如需配置自动告警通知)。
  • 目标集群已安装监控组件(使用监控指标创建告警策略时必需)。
  • 目标集群已安装日志存储组件和日志采集组件(使用日志和事件创建告警策略时必需)。

#操作步骤

  1. 进入 运维中心 > 告警 > 告警策略。
  2. 点击 创建告警策略。
  3. 配置基础信息。

#选择告警类型

资源告警

  • 按资源类型分类的告警类型(例如命名空间下的 deployment 状态)。
  • 资源选择说明:
    • 未选择参数时默认为“任意”,支持自动关联新添加的资源。
    • 选择“全选”时,仅适用于当前资源。
    • 选择多个命名空间时,资源名称支持正则表达式(如 cert.*)。

事件告警

  • 按具体事件分类的告警类型(例如 Pod 状态异常)。
  • 默认选择指定资源下的所有资源,支持自动关联新添加的资源。

#配置告警规则

点击 添加告警规则,根据告警类型配置以下参数:

资源告警参数

参数描述
ExpressionPrometheus 格式的监控指标算法,例如 rate(node_network_receive_bytes{instance="$server",device!~"lo"}[5m])
Metric Unit自定义监控指标单位,可手动输入或从平台预设单位中选择
Legend Parameter控制图表中曲线对应的名称,格式为 {{.LabelName}},例如 {{.hostname}}
Time Range日志/事件查询的时间窗口
Log Content日志内容查询字段(如 Error),多个查询字段之间用 OR 连接
Event Reason事件原因查询字段(Reason,如 BackOff、Pulling、Failed 等),多个查询字段之间用 OR 连接
Trigger Condition由比较运算符、告警阈值和持续时间(可选)组成的条件。根据实时值/日志数量/事件数量与告警阈值的比较及实时值在告警阈值范围内的持续时间判断是否触发告警。
alert Level分为四个等级:Critical、Serious、Warning 和 Info。可根据告警规则对业务的影响,为对应资源设置合理的告警等级。

事件告警参数

参数描述
Time Range事件查询的时间窗口
Event Monitoring Item支持监控事件等级或事件原因,多个字段之间用 OR 连接
Trigger Condition基于事件数量进行比较判断
alert Level与资源告警等级定义相同

#其他配置

  1. 选择一个或多个已创建的通知策略。
  2. 配置告警发送间隔。
    • 全局:使用平台默认配置。
    • 自定义:可根据告警等级设置不同的发送间隔。
    • 选择“不重复”时,仅在告警触发和恢复时发送通知。

#其他说明

  1. 在告警规则的“更多”选项中,可设置标签和注释。
  2. 标签和注释的配置请参考 Prometheus Alerting Rules Documentation。
  3. 注意:标签中不要使用 $value 变量,否则可能导致告警异常。

#通过 CLI 创建资源告警

#前提条件

  • 已配置通知策略(如需配置自动告警通知)。
  • 目标集群已安装监控组件(使用监控指标创建告警策略时必需)。
  • 目标集群已安装日志存储组件和日志采集组件(使用日志和事件创建告警策略时必需)。

#操作步骤

  1. 新建 YAML 配置文件,命名为 example-alerting-rule.yaml。

  2. 在 YAML 文件中添加 PrometheusRule 资源并提交。以下示例创建了一个名为 policy 的新告警策略:

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      annotations:
        alert.cpaas.io/cluster: global # 告警所在集群名称
        alert.cpaas.io/kind: Cluster # 资源类型
        alert.cpaas.io/name: global # 资源对象,支持单个、多选(用 | 分隔)或任意(.*)
        alert.cpaas.io/namespace: cpaas-system # 告警对象所在命名空间,支持单个、多选(用 | 分隔)或任意(.*)
        alert.cpaas.io/notifications: '["test"]'
        alert.cpaas.io/repeat-config: '{"Critical":"never","High":"5m","Medium":"5m","Low":"5m"}'
        alert.cpaas.io/rules.description: '{}'
        alert.cpaas.io/rules.disabled: '[]'
        alert.cpaas.io/subkind: ''
        cpaas.io/description: ''
        cpaas.io/display-name: policy # 告警策略展示名称
      labels:
        alert.cpaas.io/owner: System
        alert.cpaas.io/project: cpaas-system
        cpaas.io/source: Platform
        prometheus: kube-prometheus
        rule.cpaas.io/cluster: global
        rule.cpaas.io/name: policy
        rule.cpaas.io/namespace: cpaas-system
      name: policy
      namespace: cpaas-system
    spec:
      groups:
        - name: general # 告警规则组名称
          rules:
            - alert: cluster.pod.status.phase.not.running-tx1ob-e998f0b94854ee1eade5ae79279e005a
              annotations:
                alert_current_value: '{{ $value }}' # 当前值通知,保持默认
              expr: (count(min by(pod)(kube_pod_container_status_ready{}) !=1) or on() vector(0))>2
              for: 30s # 持续时间
              labels:
                alert_cluster: global # 告警所在集群名称
                alert_for: 30s # 持续时间
                alert_indicator: cluster.pod.status.phase.not.running # 告警规则指标名称(自定义告警指标名称为 custom)
                alert_indicator_aggregate_range: '30' # 告警规则聚合时间,单位秒
                alert_indicator_blackbox_name: '' # 黑盒监控项名称
                alert_indicator_comparison: '>' # 告警规则比较方式
                alert_indicator_query: '' # 告警规则日志查询(仅日志告警)
                alert_indicator_threshold: '2' # 告警规则阈值
                alert_indicator_unit: '' # 告警规则指标单位
                alert_involved_object_kind: Cluster # 告警规则所属对象类型:Cluster|Node|Deployment|Daemonset|Statefulset|Middleware|Microservice|Storage|VirtualMachine
                alert_involved_object_name: global # 告警规则所属对象名称
                alert_involved_object_namespace: '' # 告警规则所属对象命名空间
                alert_name: cluster.pod.status.phase.not.running-tx1ob # 告警规则名称
                alert_namespace: cpaas-system # 告警规则所在命名空间
                alert_project: cpaas-system # 告警规则所属对象项目名称
                alert_resource: policy # 告警规则所在告警策略名称
                alert_source: Platform # 告警规则所在告警策略数据类型:Platform-平台数据 Business-业务数据
                severity: High # 告警规则严重级别:Critical-严重、High-较严重、Medium-警告、Low-提示

#通过 CLI 创建事件告警

#前提条件

  • 已配置通知策略(如需配置自动告警通知)。
  • 目标集群已安装监控组件(使用监控指标创建告警策略时必需)。
  • 目标集群已安装日志存储组件和日志采集组件(使用日志和事件创建告警策略时必需)。

#操作步骤

  1. 新建 YAML 配置文件,命名为 example-alerting-rule.yaml。

  2. 在 YAML 文件中添加 PrometheusRule 资源并提交。以下示例创建了一个名为 policy2 的新告警策略:

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      annotations:
        alert.cpaas.io/cluster: global
        alert.cpaas.io/events.scope:
          '[{"names":["argocd-gitops-redis-ha-haproxy"],"kind":"Deployment","operator":"=","namespaces":["*"]}]'
          # names: 事件告警的资源名称;若名称为空,operator 无效。
          # kind: 触发事件告警的资源类型。
          # namespace: 触发事件告警的资源所属命名空间。空数组表示非命名空间资源;当 ns 为 ['*'] 时表示所有命名空间。
          # operator: 选择器 =, !=, =~, !~
        alert.cpaas.io/kind: Event # 告警类型,Event(事件告警)
        alert.cpaas.io/name: '' # 资源告警使用,事件告警为空
        alert.cpaas.io/namespace: cpaas-system
        alert.cpaas.io/notifications: '["acp-qwtest"]'
        alert.cpaas.io/repeat-config: '{"Critical":"never","High":"5m","Medium":"5m","Low":"5m"}'
        alert.cpaas.io/rules.description: '{}'
        alert.cpaas.io/rules.disabled: '[]'
        cpaas.io/description: ''
        cpaas.io/display-name: policy2
      labels:
        alert.cpaas.io/owner: System
        alert.cpaas.io/project: cpaas-system
        cpaas.io/source: Platform
        prometheus: kube-prometheus
        rule.cpaas.io/cluster: global
        rule.cpaas.io/name: policy2
        rule.cpaas.io/namespace: cpaas-system
      name: policy2
      namespace: cpaas-system
    spec:
      groups:
        - name: general
          rules:
            - alert: cluster.event.count-6sial-34c9a378e3b6dda8401c2d728994ce2f
              # 6sial-34c9a378e3b6dda8401c2d728994ce2f 可自定义以保证唯一性
              annotations:
                alert_current_value: '{{ $value }}' # 当前值通知,保持默认
              expr: round(((avg
                by(kind,namespace,name,reason)(increase(cpaas_event_count{namespace=~".*",id="policy2-cluster.event.count-6sial"}[300s])))
                + (avg
                by(kind,namespace,name,reason)(abs(increase(cpaas_event_count{namespace=~".*",id="policy2-cluster.event.count-6sial"}[300s])))))
                / 2)>2
              # policy2 中的 id 需为告警策略名称;6sial 必须与前置告警规则名称匹配
              for: 15s # 持续时间
              labels:
                alert_cluster: global # 告警所在集群名称
                alert_for: 15s # 持续时间
                alert_indicator: cluster.event.count # 告警规则指标名称(自定义告警指标名称为 custom)
                alert_indicator_aggregate_range: '300' # 告警规则聚合时间,单位秒
                alert_indicator_blackbox_name: ''
                alert_indicator_comparison: '>' # 告警规则比较方式
                alert_indicator_event_reason: ScalingReplicaSet # 事件原因
                alert_indicator_threshold: '2' # 告警规则阈值
                alert_indicator_unit: pieces # 告警规则指标单位,事件告警保持不变
                alert_involved_object_kind: Event
                alert_involved_object_options: Single
                alert_name: cluster.event.count-6sial # 告警规则名称
                alert_namespace: cpaas-system # 告警规则所在命名空间
                alert_project: cpaas-system # 告警规则所属对象项目名称
                alert_repeat_interval: 5m
                alert_resource: policy2 # 告警规则所在告警策略名称
                alert_source: Platform # 告警规则所在告警策略数据类型:Platform-平台数据 Business-业务数据
                severity: High # 告警规则严重级别:Critical-严重、High-较严重、Medium-警告、Low-提示

#通过告警模板创建告警策略

告警模板是针对相似资源的告警规则和通知策略的组合。通过告警模板,可以方便快捷地为平台上的集群、节点或计算组件创建告警策略。

#前提条件

  • 已配置通知策略(如需配置自动告警通知)。
  • 目标集群已安装监控组件(使用监控指标创建告警策略时必需)。

#操作步骤

#创建告警模板

  1. 在左侧导航栏点击 运维中心 > 告警 > 告警模板。
  2. 点击 创建告警模板。
  3. 配置告警模板的基础信息。
  4. 在 告警规则 区域,点击 添加告警规则,根据以下参数说明添加告警规则:
参数描述
ExpressionPrometheus 格式的监控指标算法,例如 rate(node_network_receive_bytes{instance="$server",device!~"lo"}[5m])
Metric Unit自定义监控指标单位,可手动输入或从平台预设单位中选择
Legend Parameter控制图表中曲线对应的名称,格式为 {{.LabelName}},例如 {{.hostname}}
Time Range日志/事件查询的时间窗口
Log Content日志内容查询字段(如 Error),多个查询字段之间用 OR 连接
Event Reason事件原因查询字段(Reason,如 BackOff、Pulling、Failed 等),多个查询字段之间用 OR 连接
Trigger Condition由比较运算符、告警阈值和持续时间(可选)组成的条件。
alert Level分为四个等级:Critical、Serious、Warning 和 Info。可根据告警规则对业务的影响,为对应资源设置合理的告警等级。
  1. 点击 创建。

#使用告警模板创建告警策略

  1. 在左侧导航栏点击 运维中心 > 告警 > 告警策略。 提示:可通过顶部导航栏切换目标集群。
  2. 点击 创建告警策略 按钮旁的展开按钮 > 模板创建告警策略。
  3. 配置部分参数,参考以下说明:
参数描述
模板名称选择要使用的告警模板名称。模板按集群、节点和计算组件分类。选择模板后,可查看告警模板中设置的告警规则、通知策略等信息。
资源类型选择模板是针对 集群、节点 还是 计算组件 的告警策略模板;对应的资源名称将显示。
  1. 点击 创建。

#设置告警静默

支持对集群、节点和计算组件的告警进行静默设置。通过对特定告警策略设置静默,可以控制该告警策略下所有规则在静默时间段内触发时不发送通知消息。支持永久静默和自定义时间静默。

例如:平台升级或维护时,许多资源可能出现异常状态,导致大量告警触发,运维人员在升级或维护完成前频繁收到告警通知。对告警策略设置静默可避免此类情况。

注意:静默状态持续到静默结束时间后,静默设置将自动清除。

#通过 UI 设置

  1. 在左侧导航栏点击 运维中心 > 告警 > 告警策略。

  2. 点击要静默的告警策略右侧的操作按钮 > 设置静默。

  3. 切换 告警静默 开关至开启状态。

    提示:该开关控制静默设置是否生效。取消静默只需关闭开关。

  4. 根据以下说明配置相关参数:

    提示:若未选择静默范围或资源名称,默认为 任意,表示后续的 删除/添加 资源操作将对应 删除静默/添加静默 告警策略;选择“全选”时,仅对当前选中资源范围生效,后续的 删除/添加 资源操作不再处理。

    参数描述
    静默范围静默设置生效的资源范围。
    资源名称静默设置针对的资源对象名称。
    静默时间告警静默的时间范围。告警将在静默时间开始时进入静默状态,若静默结束时间后告警策略仍处于告警状态或再次触发告警,则恢复发送告警通知。永久:静默设置持续到告警策略被删除。自定义:自定义静默开始和结束时间,时间间隔不得少于 5 分钟。
  5. 点击 设置。

    提示:从设置静默到静默开始这段时间内,告警策略的静默状态为 静默等待,此期间策略内规则触发告警时正常发送通知;静默开始至结束期间,告警策略静默状态为 静默中,策略内规则触发告警时不发送通知。

#通过 CLI 设置

  1. 指定要设置静默的告警策略资源名称,执行以下命令:

    kubectl edit PrometheusRule <TheNameOfThealertPolicyYouWantToSet>
  2. 按示例修改资源,添加静默注解并提交。

    ---
    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      annotations:
        alert.cpaas.io/cluster: global
        alert.cpaas.io/kind: Node
        alert.cpaas.io/name: 0.0.0.0
        alert.cpaas.io/namespace: cpaas-system
        alert.cpaas.io/notifications: '[]'
        alert.cpaas.io/rules.description: '{}'
        alert.cpaas.io/rules.disabled: '[]'
        alert.cpaas.io/rules.version: '23'
        alert.cpaas.io/silence.config:
          '{"startsAt":"2025-02-08T08:01:37Z","endsAt":"2025-02-22T08:01:37Z","creator":"leizhu@alauda.io","resources":{"nodes":[{"name":"192.168.36.11","ip":"192.168.36.11"},{"name":"192.168.36.12","ip":"192.168.36.12"},{"name":"192.168.36.13","ip":"192.168.36.13"}]}}'
          # 节点级告警策略的静默配置,包括开始时间、结束时间、创建者等;若静默范围包含特定节点,请按示例追加 resources.node 信息。若需对所有资源静默,无需 resources 字段。
        # alert.cpaas.io/silence.config: '{"startsAt":"2025-02-08T08:04:50Z","endsAt":"2199-12-31T00:00:00Z","creator":"leizhu@alauda.io","name":["alb-operator-ctl","apollo"],"namespace":["cpaas-system"]}'
        # 工作负载级告警策略的静默配置,包括开始时间、结束时间、创建者等;若静默范围包含特定工作负载,请按示例追加 name 和 namespace 信息。若需对所有资源静默,无需 name 和 namespace 字段。
        # 设置 endsAt 字段为 2199-12-31T00:00:00Z 表示永久静默。
        alert.cpaas.io/subkind: ''
        cpaas.io/creator: leizhu@alauda.io
        cpaas.io/description: ''
        cpaas.io/display-name: policy3
        cpaas.io/updated-at: 2025-02-08T08:01:42Z
      labels:
      ## 排除无关信息

#配置告警规则的建议

更多的告警规则并不总是更好。冗余或复杂的告警规则可能导致告警风暴,增加维护负担。建议您在配置告警规则前阅读以下指导,确保自定义规则既能达到预期目的,又保持高效。

  • 尽量使用最少的新规则:仅创建满足您具体需求的规则。通过使用最少数量的规则,可以在监控环境中构建更易管理和集中的告警系统。
  • 关注症状而非原因:创建通知用户症状的规则,而非症状的根本原因。这样,当相关症状出现时,用户能收到告警,并可进一步调查触发告警的根因。此策略可显著减少需创建的规则总数。
  • 变更前规划和评估需求:首先明确哪些症状重要,以及当症状发生时希望用户采取的行动。然后评估现有规则,决定是否可通过修改它们实现目标,而无需为每个症状创建新规则。通过修改现有规则和谨慎创建新规则,有助于简化告警系统。
  • 提供清晰的告警信息:创建告警信息时,包含症状描述、可能原因和建议操作。信息应清晰简洁,提供排查步骤或相关信息链接,帮助用户快速评估情况并做出响应。
  • 合理设置严重级别:为规则分配严重级别,指示用户在症状触发告警时应如何响应。例如,将严重级别设为 Critical,表示相关人员需立即采取行动。通过设定严重级别,帮助用户判断告警响应优先级,确保紧急问题得到及时处理。