配置告警

TensorFusion 自带一组告警规则，覆盖 GPU 用满、分配失败、资源池容量不足和 GPU 闲置。controller 负责计算规则，把触发的告警发给 Alertmanager；Alertmanager 由 Helm chart 一并安装。默认安装下 Alertmanager 只有一个不通知任何人的接收器。本页先把它接到你的通知渠道，再说明怎么改阈值、加规则。

告警是怎么工作的

1. 每条规则是一条针对 GreptimeDB 指标表的 SQL 查询，controller 每隔 evaluationInterval 执行一次。
2. 查询返回的每一行是一个待定告警。同一行连续出现 consecutiveCount 次后，告警才真正触发。
3. controller 把触发和恢复的告警推给 Alertmanager，由 Alertmanager 分组、去重，并通知接收器。

规则写在 Helm value dynamicConfig.alertRules 里，Alertmanager 的配置写在 alert.alertManagerConfig 里。

前置条件

• 用 Helm 安装了 TensorFusion。chart 默认开启规则计算（controller.command 里的 -enable-alert）和 Alertmanager（alert.enabled: true）。
• 手头有当前 release 的 values 文件。可以这样导出：helm -n tensor-fusion-sys get values tensor-fusion-sys -o yaml > values.yaml。
• 有一个 Alertmanager 能通知到的目标：webhook 地址、Slack、PagerDuty、邮件，或其他 Alertmanager 接收器。
• 想用基于 GPU 和 worker 实际用量的规则，需要先打开 hypervisor 的 vector sidecar，见采集 hypervisor 指标和日志。哪些规则依赖它，见内置规则。

步骤 1：配置接收器

新建 alert-values.yaml。下面的例子把所有告警发到一个 webhook，P0 告警另外发到第二个：

alert:
  alertManagerConfig:
    global: {}
    route:
      receiver: ops-webhook
      group_by: [alertname, instance]
      group_wait: 10s
      group_interval: 5m
      repeat_interval: 3h
      routes:
        - matchers: ['severity="P0"']
          receiver: oncall-webhook
    receivers:
      - name: ops-webhook
        webhook_configs:
          - url: https://alerts.example.com/tensor-fusion
      - name: oncall-webhook
        webhook_configs:
          - url: https://alerts.example.com/oncall
    templates:
      - /etc/alertmanager/*.tmpl

alertManagerConfig 的内容会原样写进 alertmanager.yml，任何合法的 Alertmanager 配置都可以用。这份配置保存在 ConfigMap 里，往里面写 API key 或 SMTP 密码之前请考虑到这一点。

每条告警都带下面这些标签和注解，可以用在路由和通知模板里：

步骤 2：调整或新增规则（可选）

dynamicConfig.alertRules 是一个列表，而 Helm 对列表是整体替换。哪怕只改一条规则，也要把 chart values.yaml 里的完整列表复制到自己的 values 文件里再改。只写一条的话，其余规则会全部消失。

一条规则长这样：

dynamicConfig:
  alertRules:
    - name: GPUVRAMFull
      query: |
        SELECT node, pool, uuid, avg(memory_percentage) AS memory_used
        FROM tf_gpu_usage
        WHERE memory_percentage > {{ .Threshold }} AND {{ .Conditions }}
        GROUP BY node, pool, uuid
      threshold: 97
      evaluationInterval: 30s
      consecutiveCount: 2
      severity: P1
      summary: "GPU VRAM Full, used {{ .memory_used }}% on {{ .node }} {{ .uuid }}"
      description: "GPU {{ .uuid }} on Node {{ .node }} in Pool {{ .pool }} has VRAM usage above {{ .Threshold }}%"
      alertTargetInstance: "{{ .uuid }}"
      runbookURL: "https://tensor-fusion.ai/docs/tensor-fusion-engine/troubleshooting/handbook"
    # ... 其余规则

新写的查询先在 GreptimeDB 里试一遍，把模板变量换成实际的值，方法见查询指标和日志。

步骤 3：应用修改

helm upgrade tensor-fusion-sys tensor-fusion \
  --repo https://download.tensor-fusion.ai \
  --namespace tensor-fusion-sys \
  --version <chart-version> \
  -f values.yaml -f alert-values.yaml

# Alertmanager 只在启动时读取配置
kubectl -n tensor-fusion-sys rollout restart statefulset/tensor-fusion-sys-alert-manager

# 仅在改了 dynamicConfig.alertRules 时需要
kubectl -n tensor-fusion-sys rollout restart deploy/tensor-fusion-sys-controller

chart 版本填当前正在用的版本，这样这条命令不会带来别的变化。helm -n tensor-fusion-sys list 可以查到。

验证

1. 打开 Alertmanager 界面：

   kubectl -n tensor-fusion-sys port-forward svc/alert-manager 9093:9093

   浏览器访问 http://localhost:9093，在 Status 页能看到刚才应用的配置。

2. 用 controller 调用的同一个 API 发一条测试告警：

   curl -X POST http://localhost:9093/api/v2/alerts \
     -H 'Content-Type: application/json' \
     -d '[{"labels":{"alertname":"TestAlert","severity":"P1","job":"tensor-fusion","instance":"test"},"annotations":{"summary":"Test alert from TensorFusion setup"}}]'

   告警会出现在 Alerts 页，过了 group_wait 之后接收器收到通知。

3. 确认 controller 执行规则时没有报错：

   kubectl -n tensor-fusion-sys logs deploy/tensor-fusion-sys-controller -c controller | grep -i "failed to evaluate rule"

   没有输出说明每条查询都执行成功。只有 leader 副本会计算规则，controller 有多个副本时要对每个 Pod 执行一遍。

内置规则

具体的查询和阈值以 chart 的 values.yaml 为准。

使用自己的 Alertmanager

想把告警发到已有的 Alertmanager，就关掉自带的那个，并把地址传给 controller。controller.command 是列表，需要把默认参数重写一遍，再加上自己的：

alert:
  enabled: false
controller:
  command:
    - /manager
    - -metrics-bind-address
    - :9000
    - -leader-elect
    - -enable-auto-scale
    - -enable-alert
    - -enable-auto-expander
    - -alert-manager-addr=http://alertmanager.monitoring.svc.cluster.local:9093

地址必须以 http:// 或 https:// 开头，controller 会自己在后面拼上 /api/v2/alerts。

TensorFusion 没有装在 tensor-fusion-sys 命名空间时，也要设置这个参数。它的默认值是 http://alert-manager.tensor-fusion-sys.svc.cluster.local:9093，换了命名空间后，不设置的话 controller 连不上自带的 Alertmanager。

想彻底关闭告警，再把列表里的 -enable-alert 去掉。

限制

• 规则的状态保存在 controller 内存里。controller 重启后，连续次数从零开始计；之前已触发的告警不会收到明确的恢复通知，由 Alertmanager 自行过期。
• 用 chart 安装时，controller 只在启动时加载规则。每次修改后都要重启，见步骤 3。
• hypervisor 大约每分钟写一次用量指标。针对 tf_gpu_usage 或 tf_worker_usage 的规则如果 evaluationInterval 短于这个间隔，某些窗口里会一行数据都没有。这类规则该触发却没触发时，把它的 evaluationInterval 调到 1m 或更长。
• 没有 hypervisor 指标时，上表标“是”的规则无法正常工作，其中 EmptyGPU 可能把所有 GPU 节点都报出来。请打开 sidecar，或者删掉这些规则。
• 规则只能查询 GreptimeDB。hypervisor Pod 崩溃这类事件不在覆盖范围内，Kubernetes 事件和 Pod 状态请用集群自己的监控来盯。

下一步

• 查询指标和日志：了解规则可以查询哪些表。
• 指标参考：每张表的全部字段。
• 问题处理手册：告警触发后怎么排查。