设计算力集群的监控与告警系统，需收集CPU、内存、网络、任务状态等关键指标，并设置告警规则（如CPU使用率超过80%时告警），请说明监控工具（如Prometheus、Grafana）及告警策略。
答案
1) 【一句话结论】
采用Prometheus作为核心监控平台（通过Exporter收集CPU、内存、网络等指标），结合Grafana实现可视化，利用Prometheus的规则引擎和Alertmanager配置告警策略（如CPU使用率超80%时触发邮件/短信通知），构建全链路监控与告警系统。
2) 【原理/概念讲解】
老师口吻解释：Prometheus是开源的监控系统和时间序列数据库，核心是通过拉取（pull）模式从目标（如容器、服务器）上的Exporter获取指标数据。这些指标以“指标名称+标签+数值”的时间序列形式存储。类比：Exporter是“传感器”，Prometheus数据库是“数据仓库”，Grafana是“仪表盘”。告警规则通过PromQL（Prometheus查询语言）定义，当指标满足条件时，由Alertmanager分发到通知渠道（如邮件、Slack）。
3) 【对比与适用场景】
| 工具 | 定义 | 核心特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Prometheus | 开源监控系统+时间序列数据库 | 拉取模式，自愈，规则引擎，Alertmanager | 大规模分布式系统（容器集群、云原生应用） | 需Exporter配合收集指标，对指标命名有规范要求 |
| Grafana | 可视化平台 | 丰富图表、告警、仪表盘 | 监控数据可视化，告警展示 | 需连接数据源（如Prometheus），配置需结合业务场景 |
4) 【示例】
告警规则（PromQL规则文件示例）：
groups:
- name: cpu-alerts
rules:
- alert: HighCpuUsage
expr: avg by (instance) (rate(node_cpu_seconds_total{mode="idle",cpu="0"}[5m])) < 20
for: 2m
labels:
severity: critical
annotations:
summary: "CPU usage is high on {{ $labels.instance }}"
description: "CPU usage has been above 80% for 2 minutes on {{ $labels.instance }}"
解释：计算每个实例的CPU空闲率（idle模式），若连续5分钟空闲率低于20%（即使用率超80%），则触发告警。
5) 【面试口播版答案】
面试官您好，针对算力集群的监控与告警，我会采用Prometheus+Grafana的组合方案。首先，部署Exporter（如node_exporter收集CPU/内存，net_exporter收集网络，自定义Exporter收集任务状态），将集群指标拉取到Prometheus服务器。接着，用Grafana搭建可视化仪表盘，展示实时指标。告警策略通过Prometheus的规则引擎（PromQL规则）定义，比如CPU使用率超80%时，由Alertmanager发送邮件/短信通知。具体配置包括：指标收集、规则文件编写、告警渠道绑定，确保集群异常能及时响应。
6) 【追问清单】
- 问：如何处理告警误报？
答：通过调整规则延迟时间（如增加2分钟延迟）、优化指标组合（如结合内存使用率）、设置告警抑制（避免重复告警）。 - 问：多集群如何统一监控？
答：使用Prometheus联邦架构（如Prometheus Federation），或集中式Prometheus服务器拉取各集群Exporter数据。 - 问：任务状态如何监控？
答：通过自定义Exporter将任务状态（运行/失败/等待）作为指标上报，Prometheus收集后用Grafana展示状态分布，告警规则检测失败率超阈值。 - 问：告警渠道有哪些？
答：支持邮件、短信、Slack、企业微信等，通过Alertmanager的接收器配置。 - 问：指标收集粒度如何选择？
答：根据业务需求，CPU/内存按秒收集，网络按分钟，任务状态按分钟，避免数据爆炸。
7) 【常见坑/雷区】
- 坑1：忽略Exporter配置，仅说用Prometheus，导致方案不适用于容器集群。
- 坑2：告警阈值设置不合理（如过低误报、过高漏报），未结合业务场景。
- 坑3：未配置告警渠道，仅说告警规则，显得方案不完整。
- 坑4：监控数据存储时间过短（如仅1天），无法分析长期趋势。
- 坑5：未考虑容器化环境下的指标收集，导致指标不全。