17.3.6 目标生命周期管理与告警联动

目标生命周期管理覆盖目标从发现、抓取、失联、恢复到最终剔除的全过程，需要与告警联动形成闭环。核心目标是降低误报、缩短恢复时间并提升告警可解释性。

0. 原理草图：目标状态与告警联动链路

1. 目标状态与生命周期
- Pending：目标被发现但尚未抓取成功，多见于新上线或网络未通。
- Up：抓取成功，目标可用，记录 up=1。
- Down：抓取失败，记录 up=0，可能是网络、权限、Exporter异常或服务宕机。
- Stale：目标消失或不再被发现，时序进入过期状态，需防止触发错误告警。

2. 目标健康判定与告警触发（PromQL 示例）

# 基础可用性：服务不可用
up{job="node"} == 0

# 目标消失：注册中心异常或配置移除
absent(up{job="node"})

# 目标波动：5分钟内状态变化次数
changes(up{job="node"}[5m]) > 3

3. 生命周期与告警联动策略（含规则示例）

# /etc/prometheus/rules/target_lifecycle.yml
groups:
- name: target.lifecycle
  rules:
  - alert: ServiceDown
    expr: up{job="node"} == 0
    for: 2m
    labels:
      severity: critical
      scene: lifecycle
    annotations:
      summary: "Node不可用 {{ $labels.instance }}"
      description: "抓取失败超过2分钟，可能服务宕机或网络故障"

  - alert: TargetMissing
    expr: absent(up{job="node"})
    for: 3m
    labels:
      severity: warning
      scene: lifecycle
    annotations:
      summary: "目标消失 {{ $labels.job }}"
      description: "目标已不在发现列表，可能注册中心异常或配置移除"

  - alert: TargetFlapping
    expr: changes(up{job="node"}[5m]) > 3
    for: 1m
    labels:
      severity: warning
      scene: lifecycle
    annotations:
      summary: "目标抖动 {{ $labels.instance }}"
      description: "5分钟内状态变化>3，需排查不稳定原因"

4. Alertmanager联动要点（含路由/抑制/静默示例）

# /etc/alertmanager/alertmanager.yml
route:
  group_by: ["job","service","env"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  receiver: "oncall"
  routes:
  - matchers:
    - env="staging"
    receiver: "silent"
  - matchers:
    - severity="critical"
    receiver: "oncall"

receivers:
- name: "oncall"
  webhook_configs:
  - url: "http://ops-webhook.local/alert"
- name: "silent"

inhibit_rules:
- source_matchers: ["alertname=ServiceDown"]
  target_matchers: ["alertname=TargetFlapping"]
  equal: ["job","instance"]

5. 安装与命令示例（规则加载与验证）

# 1) 安装 promtool（随 Prometheus 安装包）
# 2) 放置规则文件
sudo mkdir -p /etc/prometheus/rules/
sudo cp target_lifecycle.yml /etc/prometheus/rules/

# 3) 主配置引用规则
sudo tee /etc/prometheus/prometheus.yml >/dev/null <<'EOF'
global:
  scrape_interval: 15s
rule_files:
  - /etc/prometheus/rules/*.yml
scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["127.0.0.1:9100"]
EOF

# 4) 规则语法检查
promtool check rules /etc/prometheus/rules/target_lifecycle.yml

# 5) 重载 Prometheus（HTTP reload）
curl -X POST http://127.0.0.1:9090/-/reload

命令解释：
- promtool check rules：验证规则语法与表达式可解析。
- /-/reload：无重启加载新规则，降低变更风险。

6. 排错清单（按生命周期）

# 目标状态查看（Prometheus UI 查询）
# 访问 http://<prometheus>:9090/targets

# 抓取失败常见定位
# 1) 网络
curl -sS http://<target>:9100/metrics | head
# 2) 端口监听
ss -lntp | grep 9100
# 3) 防火墙
sudo iptables -L -n | grep 9100
# 4) 标签漂移
# 在 /targets 页面核对 job/instance 标签是否变化

# 目标消失排查：服务发现源是否正常
# 若基于文件发现:
ls -l /etc/prometheus/file_sd/
cat /etc/prometheus/file_sd/targets.json

7. 典型生命周期示例（文件发现 + 下线流程）

// /etc/prometheus/file_sd/targets.json
[
  {
    "targets": ["10.0.0.21:9100","10.0.0.22:9100"],
    "labels": { "job":"node", "service":"core", "env":"prod" }
  }
]

下线流程：
1) 从服务发现源移除目标（更新 targets.json）。
2) curl -X POST http://prometheus:9090/-/reload 触发重载。
3) 在 Alertmanager 设置维护静默，避免下线告警误报。

8. 练习
1) 新增一个临时目标，观察状态从 Pending → Up 的变化，并记录 up 指标。
2) 停止 exporter 服务，验证 ServiceDown 触发，恢复后告警自动恢复。
3) 删除 targets.json 中的某个目标，验证 TargetMissing 的告警逻辑。
4) 修改标签 service_id，观察告警是否发生抖动并调整规则稳定性。