有效的监控不仅仅是收集指标；它还包括在出现问题时收到通知。Prometheus 拥有强大且内置的告警系统，它允许你使用与绘图相同的 PromQL 查询语言来定义告警条件。当告警的条件满足时，它会进入“触发”（firing）状态。
在这个 Lab 中，你将学习 Prometheus 告警的基础知识。你将从一个预先配置好的、运行着 Prometheus 和 Node Exporter 的环境中开始。你的任务是创建一个独立的告警规则文件，定义一条规则来检测高 CPU 使用率，配置 Prometheus 来加载该文件，最后，模拟高 CPU 负载，观察你的告警在 Prometheus UI 中触发。
在这一步，你将熟悉 Lab 环境。设置脚本已经为你启动了两个 Docker 容器：一个用于 Prometheus，一个用于 Node Exporter。
首先，我们来验证两个容器都在运行。打开一个终端并执行 docker ps 命令：
docker ps你应该会看到类似以下的输出，显示 prometheus 和 node-exporter 容器处于“Up”状态。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
... prom/prometheus "/bin/prometheus --c…" 15 seconds ago Up 14 seconds 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp prometheus
... prom/node-exporter "/bin/node_exporter …" 16 seconds ago Up 15 seconds 0.0.0.0:9100->9100/tcp, :::9100->9100/tcp node-exporternode-exporter 容器暴露了关于宿主系统（我们的 Lab 虚拟机）的指标，而 prometheus 容器被配置为抓取（scrape，收集）这些指标。
现在，我们来检查 Prometheus UI。要访问它：
+ (New Tab) 按钮9090当新标签页打开时，你应该会看到 Prometheus 表达式浏览器（Expression Browser）的着陆页。从顶部导航菜单导航到 Status -> Targets。你应该会看到 node_exporter Job 处于绿色的 "UP" 状态，这确认了 Prometheus 正在成功地从它那里收集数据。这个连接是我们告警规则的基础。
在这一步，你将创建一个专用的文件来存放你的告警规则。将规则与主要的 Prometheus 配置分开存放是更好的组织实践。
我们将在你的项目目录下创建一个名为 alert-rules.yml 的文件。使用 nano 编辑器来创建和编辑该文件：
nano ~/project/alert-rules.yml现在，将以下 YAML 内容复制并粘贴到 nano 编辑器中。这定义了一个规则组，其中包含一个在 CPU 使用率高时触发的告警。
groups:
- name: node_alerts
rules:
- alert: HighCpuLoad
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 10
for: 1m
labels:
severity: warning
annotations:
summary: "High CPU load on {{ $labels.instance }}"
description: "CPU load is > 10% (current value: {{ $value }}%)"我们来解析一下这个规则：
groups: 规则被组织到组中。组中的所有规则按顺序进行评估。alert: 我们告警的名称，HighCpuLoad。expr: 被评估的 PromQL 表达式。如果它返回一个值，则触发告警。在这里，我们计算过去 1 分钟内非空闲 CPU 时间的百分比。如果它大于 10%，则条件满足。for: 此子句指定条件必须连续持续一定时间（1 分钟）后，告警才会变为“Firing”（触发）状态。这可以防止告警因短暂的峰值而触发。annotations: 这些为告警添加了人类可读的信息。summary 和 description 是标准的注解。你可以使用模板变量，如 {{ $labels.instance }} 和 {{ $value }}，将动态数据包含在你的告警消息中。粘贴内容后，按 Ctrl+X，然后按 Y，最后按 Enter 保存文件并退出 nano。
在这一步，你将指示 Prometheus 加载新的规则文件，并使用更新后的配置重启容器。
首先，你需要编辑主配置文件 prometheus.yml，以包含对你的规则文件的引用。使用 nano 打开它：
nano ~/project/prometheus.yml在 global 部分下添加 rule_files 指令。修改后文件应如下所示：
global:
scrape_interval: 15s
rule_files:
- "alert-rules.yml"
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ["prometheus:9090"]
- job_name: "node_exporter"
static_configs:
- targets: ["node-exporter:9100"]保存文件并退出 nano（Ctrl+X，Y，Enter）。
配置更新后，你必须重启 Prometheus 容器以应用更改。首先，停止并移除旧容器：
docker stop prometheusdocker rm prometheus最后，运行一个新的 Prometheus 容器。此命令与设置脚本中的命令相似，但它包含第二个 -v 标志，用于将你的 alert-rules.yml 文件挂载到容器中。
docker run -d --name prometheus -p 9090:9090 \
--network monitoring \
-v /home/labex/project/prometheus.yml:/etc/prometheus/prometheus.yml \
-v /home/labex/project/alert-rules.yml:/etc/prometheus/alert-rules.yml \
prom/prometheus此命令确保主配置和告警规则都在 Prometheus 容器内部可用。
在这一步，你将确认 Prometheus 已成功加载你的新告警规则。
返回浏览器中的 Prometheus UI 标签页（如果需要，可以打开端口 9090 上的新 Web 服务标签页）。如果页面没有加载，请等待几秒钟让新容器启动，然后刷新页面。
在顶部导航栏中，点击 Alerts 菜单项。
你现在应该在列表中看到你的 HighCpuLoad 告警。该告警将位于 Inactive（非活动）部分，并以绿色背景显示。这是预期状态，因为系统当前的 CPU 负载较低，所以告警的表达式（expr）评估结果为 false。
理解告警的三种状态非常重要：
for 持续时间尚未过去。Prometheus 正在等待确认条件是否持续存在。for 持续时间。在生产环境中，此时 Prometheus 会将告警发送给 Alertmanager。你的告警目前处于非活动状态，这是正确的。在下一步中，我们将使其触发。
在这一最后一步，你将故意增加系统上的 CPU 负载，以测试你的告警是否能正确触发。
我们可以使用一个简单的无限 shell 循环来生成 CPU 负载。在你的终端中，运行以下命令。末尾的 & 会使进程在后台运行，这样你就可以继续使用终端。
while true; do true; done &此命令启动一个消耗单个 CPU 核心 100% 的进程。现在，快速切换回 Prometheus UI 中的 Alerts 页面（可通过端口 9090 上的 Web 服务标签页访问）。
你将观察到 HighCpuLoad 告警的状态发生变化：
for 子句中指定的 1m 持续时间。
看到告警触发后，你可以停止负载生成。返回终端并运行以下命令来终止后台循环进程：
重要提示： 为了节省 LabEx 虚拟机服务器资源，请确保运行以下命令停止负载生成。
kill $!停止负载后，再次观察 Prometheus UI。告警很快将返回 Inactive（绿色）状态，完成测试周期。
恭喜你！你已成功配置并测试了一个 Prometheus 告警。
在这个实验中，你学会了如何：
这是告警体系的第一部分。下一步（超出了本实验的范围）是设置一个 Alertmanager 实例。Prometheus 会将触发的告警发送给 Alertmanager，然后 Alertmanager 负责去重、分组并将它们路由到实际的通知渠道，如电子邮件、Slack 或 PagerDuty。
