华为云Flexus+DeepSeek征文｜DeepSeek 应用监控告警体系实战：从“用户投诉才知道“到“故障前就发现“

一、引言：你的 AI 应用是"裸奔"的吗？

先问三个扎心的问题：

你的 DeepSeek 应用今天慢不慢，你是等用户投诉才知道，还是看监控知道的？
你的 MaaS 账单这个月涨了多少，你能说出是哪个功能、哪个租户烧的吗？
你的 Dify 平台多久没挂了，挂了之后多久能发现、多久能定位？

如果三个问题都答不上来，说明你的 AI 应用正在"裸奔"------不是没穿衣服，是没有眼睛和耳朵。

我见过太多 AI 项目死在"上线即裸奔"上：功能做得很炫，但没人知道它什么时候慢、为什么慢、烧了多少钱。等用户投诉才去查日志，等于让用户替你当监控------这是最贵的监控方式。

为什么 AI 应用特别需要监控？因为它的故障形态比传统应用更隐蔽：

不是"挂"，是"慢"：服务没宕机，但 TTFT 从 2s 涨到 8s，用户默默流失，你毫无察觉；
不是"错"，是"贵"：没人改代码，但思维链变长了，Token 账单翻倍，月底才傻眼；
不是"崩"，是"挤"：某个租户的批量任务占满配额，其他租户集体变慢，还以为是 MaaS 的问题。

这三种故障，靠用户投诉和人工排查根本发现不了，只有监控能看见。本文基于华为云 MaaS DeepSeek + Flexus X + Dify 的真实环境，搭建一套完整的监控告警体系，解决三个问题：

看什么：AI 应用要监控哪些指标？（传统监控 + AI 专属指标）
怎么看：Prometheus + Grafana 的落地配置，指标从哪来？
怎么报警：分级告警 + 飞书通知，让故障在用户发现之前被处理。

全文配置可直接照抄，一套下来 2 小时能跑通。

二、AI 应用监控的"两层四维"框架

传统 Web 应用的监控看 CPU/内存/磁盘就够了，但 AI 应用不一样------它多了一个模型调用层。完整的监控框架是"两层四维"：

复制代码

┌─────────────────────────────────┐
│  应用层（Flexus 实例上）          │
│  维度1：资源（CPU/内存/磁盘）     │
│  维度2：业务（请求量/延迟/成功率）│
├─────────────────────────────────┤
│  模型层（MaaS 推理服务）          │
│  维度3：调用（TTFT/TPS/Token用量）│
│  维度4：成本（按模型/租户拆分）    │
└─────────────────────────────────┘

2.1 传统四指标（应用层）

指标	含义	异常信号
CPU 使用率	应用计算负载	> 85% 持续 10 分钟
内存使用率	Dify 全家桶吃内存	> 85% 持续 10 分钟
磁盘使用率	日志/镜像/向量库	> 80% 持续 1 天
网络 IO	与 MaaS 的通信	波动大伴随延迟升高

2.2 AI 专属四指标（模型层）

这是 AI 应用独有的、传统监控看不到的：

指标	含义	为什么重要
TTFT（首 Token 延迟）	从发请求到第一个字	用户感知"快不快"的直接指标
TPS（生成速度）	每秒生成 Token 数	反映 MaaS 侧负载
思维链 Token 数	R1 的思考长度	提示词质量的"体温计"
Token 成本	按模型/租户/功能拆分	成本失控的第一道防线

AI 专属指标详解：

TTFT（Time To First Token）：从发出请求到收到第一个 Token 的时间。对话场景用户对它的感知最强烈------超过 3 秒用户就开始不耐烦。TTFT 高通常意味着 MaaS 排队（配额不足）或网络问题；
TPS（Tokens Per Second）：模型生成速度。R1 这类推理模型 TPS 天然比 V3 低（因为要生成思维链），所以 TPS 告警要按模型分桶，别混在一起；
思维链 Token 数 ：R1 独有的指标，反映提示词质量和任务复杂度。这个指标是 AI 监控和传统监控最大的区别------传统监控里没有"模型想多久"这个概念；
Token 成本 ：把 Token 消耗乘以单价就是钱。MaaS 按 Token 计费，成本监控 = 每分钟都在算钱，这是云上 AI 应用特有的。

核心观点 ：AI 应用的监控，模型层比应用层更重要。CPU 高了你还能撑一会，TTFT 飙了用户立刻就跑。

2.3 指标选型的三个原则

监控指标不是越多越好，三个原则帮你砍掉 80% 的无效指标：

原则1：只监控"用户能感知"的指标

该监控：TTFT、成功率、端到端延迟（用户直接体感）
不该监控：CPU 单核利用率、磁盘 IOPS（用户感知不到，运维才关心）

原则2：指标要有"行动关联"

每个指标必须回答"告警了然后呢？"
TTFT 高 → 查配额/加缓存/降级
成本涨 → 查租户/查调用/加缓存
答不上来"然后呢"的指标，删掉

原则3：先有"问题"再有"指标"

别先铺一堆指标再想有什么用
正确顺序：列出你最怕的 10 个故障场景 → 为每个场景设计 1-2 个指标 → 汇总去重
我见过最怕的是"用户投诉慢"，所以 TTFT 和 E2E 是第一个加的指标

2.4 监控数据从哪来？四个来源

来源	数据	接入方式
网关埋点	TTFT/TPS/Token/状态码	Prometheus 客户端（3.2 节）
实例指标	CPU/内存/磁盘	node_exporter
容器指标	Dify 各容器状态	cAdvisor
MaaS 控制台	配额/账单	手动看 or 云监控 API

最容易忽略的是 MaaS 侧 ：华为云 MaaS 控制台有配额使用量和账单明细，但它是"延迟数据"（账单 T+1）。实时的调用数据必须自己从网关埋点拿------这就是为什么网关埋点是整套监控的地基。

三、落地：Prometheus + Grafana 监控栈

3.1 架构总览

复制代码

┌──────────┐    ┌──────────────┐    ┌─────────┐
│ Dify API │───▶│ 指标暴露端点   │───▶│Prometheus│
│ 网关     │    │(/metrics)    │    │(采集存储)│
└──────────┘    └──────────────┘    └────┬────┘
                                          │
                              ┌───────────┼───────────┐
                              ▼           ▼           ▼
                        ┌─────────┐ ┌─────────┐ ┌─────────┐
                        │ Grafana │ │ 告警规则 │ │ 飞书通知 │
                        │ 可视化  │ │ (Alert) │ │ (Webhook)│
                        └─────────┘ └─────────┘ └─────────┘

3.2 第一步：在网关层暴露指标

多租户网关（上一篇文章的 FastAPI 网关）天然是埋点的最佳位置------所有请求都经过它。用 Prometheus 客户端库暴露指标：

复制代码

# metrics.py - 网关指标埋点
from prometheus_client import Counter, Histogram, Gauge, generate_latest

# 请求计数（按租户、模型、状态码分桶）
REQUESTS = Counter("maas_requests_total", "总请求数",
                   ["tenant", "model", "status"])
# 延迟直方图（TTFT 和端到端分开）
TTFT = Histogram("maas_ttft_seconds", "首Token延迟",
                 ["tenant", "model"], buckets=(0.1, 0.5, 1, 2, 5, 10))
E2E = Histogram("maas_e2e_seconds", "端到端延迟",
                ["tenant", "model"], buckets=(1, 5, 10, 30, 60, 120))
# Token 用量（成本监控的原始数据）
TOKENS = Counter("maas_tokens_total", "Token用量",
                 ["tenant", "model", "kind"])  # kind: input/output

def record_usage(tenant: str, model: str, status: int, ttft: float, e2e: float, tokens: dict):
    REQUESTS.labels(tenant, model, status).inc()
    TTFT.labels(tenant, model).observe(ttft)
    E2E.labels(tenant, model).observe(e2e)
    TOKENS.labels(tenant, model, "input").inc(tokens.get("input", 0))
    TOKENS.labels(tenant, model, "output").inc(tokens.get("output", 0))

# 在 FastAPI 里挂一个 /metrics 端点给 Prometheus 抓取
@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type="text/plain")

3.3 第二步：Prometheus 采集配置

复制代码

# prometheus.yml
global:
  scrape_interval: 15s        # 采集频率
  evaluation_interval: 15s    # 告警评估频率

scrape_configs:
  - job_name: "flexus-gateway"
    static_configs:
      - targets: ["127.0.0.1:8000"]   # 网关 /metrics
  - job_name: "flexus-node"
    static_configs:
      - targets: ["127.0.0.1:9100"]   # node_exporter（CPU/内存/磁盘）

Docker 方式部署（在 Flexus 上）：

复制代码

# docker-compose 追加监控服务
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom_data:/prometheus
    ports: ["9090:9090"]

  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change-me
    volumes:
      - grafana_data:/var/lib/grafana

3.4 第三步：Grafana 仪表盘

Grafana 连上 Prometheus 数据源后，建三个核心面板：

复制代码

面板1：实时监控（刷新 30s）
  - 请求量（按租户堆叠柱状图）
  - TTFT P95（按租户折线）
  - TPS（按模型折线）

面板2：健康总览（自动刷新）
  - 成功率（最近 1 小时）
  - 429/5xx 数量
  - Flexus CPU/内存水位

面板3：成本看板（每日）
  - Token 消耗（按租户/模型饼图）
  - 预估成本（按日柱状图）
  - 成本 Top 5 租户

查询示例（Grafana PromQL）：

复制代码

# TTFT P95（按租户）
histogram_quantile(0.95, sum(rate(maas_ttft_seconds_bucket[5m])) by (le, tenant))

# 每小时 Token 消耗
sum(increase(maas_tokens_total[1h])) by (tenant)

# 成功率
sum(rate(maas_requests_total{status=~"2.."}[5m]))
/ sum(rate(maas_requests_total[5m]))

3.5 Dify 侧的监控补充

网关指标解决了"模型调用"的监控，Dify 平台本身的健康也要盯。Dify 是 Docker 编排的，几个补充手段：

1. 容器健康监控（cAdvisor）

复制代码

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports: ["8080:8080"]
    privileged: true

采集容器级指标（每个 Dify 容器的 CPU/内存/重启次数），Prometheus 加一个 job 抓 127.0.0.1:8080/metrics 即可。

2. Dify 日志监控

Dify 容器的日志是排查问题的第一现场。推荐 ELK 太重，轻量方案是 Loki：

复制代码

  loki:
    image: grafana/loki:latest
    ports: ["3100:3100"]

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - ./promtail.yml:/etc/promtail/promtail.yml

Grafana 加 Loki 数据源后，就能在仪表盘里直接搜 Dify 日志，指标和日志联动（点一条慢请求看它对应的日志），排查效率翻倍。

3. Dify 自带的可观测性

Dify 1.x 之后内置了部分可观测能力（应用运行日志、Token 统计），在控制台"运维"页面可以看。它和自建监控的关系是：Dify 自带看"单应用"，自建监控看"全链路"，两者互补。

四、告警规则：分级响应，别让告警变成"狼来了"

4.1 告警分级标准

告警最怕"全都报"------最终变成没人看。分级是关键：

级别	定义	响应要求	例子
P0 红色	服务不可用/数据泄露	立即处理，电话/群@所有人	网关 5xx > 50%、Dify 宕机
P1 橙色	体验严重劣化	15 分钟内响应	TTFT P95 > 10s、成功率 < 95%
P2 黄色	趋势恶化	当日处理	内存 > 85%、磁盘 > 80%
P3 蓝色	成本/质量预警	周会讨论	成本日环比 +30%、思维链暴涨

4.2 Prometheus 告警规则示例

复制代码

# alert_rules.yml
groups:
  - name: maas-alerts
    rules:
      # P0：网关大面积失败
      - alert: GatewayDown
        expr: |
          sum(rate(maas_requests_total{status=~"5.."}[5m]))
          / sum(rate(maas_requests_total[5m])) > 0.5
        for: 3m
        labels: { severity: P0 }
        annotations:
          summary: "网关 5xx 率超 50%"

      # P1：TTFT 劣化
      - alert: TTFTHigh
        expr: |
          histogram_quantile(0.95,
            sum(rate(maas_ttft_seconds_bucket[5m])) by (le)) > 10
        for: 5m
        labels: { severity: P1 }
        annotations:
          summary: "TTFT P95 超 10 秒"

      # P2：内存告急
      - alert: MemoryHigh
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15
        for: 10m
        labels: { severity: P2 }

      # P3：成本异常
      - alert: CostSpike
        expr: |
          sum(increase(maas_tokens_total[1h]))
          / sum(increase(maas_tokens_total[1h] offset 24h)) > 1.3
        for: 2h
        labels: { severity: P3 }
        annotations:
          summary: "Token 消耗较昨日同期增长超 30%"

4.3 飞书通知接入

告警要"叫得醒人"。用飞书自定义机器人（Webhook）：

复制代码

# alert_feishu.py - 飞书告警推送
import requests

FEISHU_WEBHOOK = "https://open.feishu.cn/open-apis/bot/v2/hook/your-token"

def send_alert(severity: str, title: str, content: str):
    color = {"P0": "red", "P1": "orange", "P2": "yellow", "P3": "blue"}[severity]
    payload = {
        "msg_type": "interactive",
        "card": {
            "header": {"title": {"tag": "plain_text", "content": f"[{severity}] {title}"},
                       "template": color},
            "elements": [{"tag": "markdown", "content": content}],
        },
    }
    requests.post(FEISHU_WEBHOOK, json=payload)

# 用法
send_alert("P1", "TTFT 劣化", "**现象**：TTFT P95 达 12s\\n**租户**：tenant_a\\n**建议**：检查 MaaS 配额或扩容")

配置要点 ：

告警合并：同一规则 30 分钟内只发一次（避免轰炸）；
静默时段：P2/P3 夜间只记录不推送，P0/P1 全天推送；
值班人：P0/P1 推送时 @ 当日值班人。

4.4 告警联动：每个告警都带 Runbook

告警推送里最该有的东西是"接下来怎么办"。给每条告警配一段 Runbook（处置手册），值班人照着做就行：

复制代码

{
  "alert": "TTFT P95 超 10s",
  "severity": "P1",
  "runbook": [
    "1. 打开 Grafana 面板『TTFT by Tenant』，看是全体还是单个租户",
    "2. 全体 → 检查 MaaS 配额（控制台看 QPS 余量），必要时升配额",
    "3. 单个租户 → 查该租户调用日志，看是否批量任务占满",
    "4. 批量任务 → 加队列限速（见多租户文章 5.4 节）",
    "5. 15 分钟后复查，未恢复升级 P0"
  ],
  "oncall": "@张三",
  "escalation": "30 分钟未处理 → @李四"
}

Runbook 的价值：把"值班人临场发挥"变成"按手册执行"，新人也能处理 P1 故障。Runbook 应该和告警规则一一对应，每次故障复盘后更新。

4.5 告警通知的进阶玩法

飞书 webhook 只是基础，进阶玩法能大幅提升告警的"战斗力"：

1. 告警去重与聚合

同一个故障可能触发 5 条告警（TTFT 高、成功率低、5xx 多），别让值班人收 5 条。用 Prometheus 的 alertmanager 做聚合：

复制代码

# alertmanager.yml
route:
  group_by: ["alertname", "tenant"]   # 按告警名+租户聚合
  group_wait: 30s                     # 30 秒内相同告警合并
  group_interval: 5m                  # 聚合后 5 分钟检查一次
  repeat_interval: 4h                 # 同告警 4 小时才重复提醒

receivers:
  - name: "feishu"
    webhook_configs:
      - url: "https://open.feishu.cn/open-apis/bot/v2/hook/your-token"

2. 告警升级链路

P1 告警 15 分钟没人确认 → 自动升级 P0 并 @ 更高级别的人：

复制代码

告警发出 → 等待确认（15 分钟）
  ├─ 确认了 → 进入处理流程
  └─ 没确认 → 升级：@技术负责人 + 电话通知
        └─ 再 15 分钟 → 升级：@CTO

3. 告警状态看板

在 Grafana 或飞书群里建一个"告警状态"看板：当前有哪些未处理告警、处理了多久、谁在处理。让告警从"一次性消息"变成"可跟踪的工作项"。

五、AI 专属监控实践：思维链与成本

5.1 思维链监控：提示词的"体温计"

R1 应用的思维链长度直接反映提示词质量。上一篇文章讲过优化提示词，这篇讲怎么持续监控它：

复制代码

健康范围：平均思维链 < 1500 Token
预警线：> 2500 Token（提示词可能被改坏）
危险线：> 4000 Token（成本爆炸，立即排查）

典型场景 ：某次发版后思维链从 1200 飙到 3500，排查发现是有人把提示词里的"最多输出 400 字"删了。监控思维链 = 给提示词上了保险，谁改坏了立刻现形。

思维链监控的落地方式：R1 的响应里有思维链 Token 数（usage 字段的 reasoning_tokens），网关把它打点进 TOKENS 计数器（kind=reasoning）。然后在 Grafana 建面板：

复制代码

# 平均思维链长度（按模型）
sum(rate(maas_tokens_total{kind="reasoning"}[1h]))
/ sum(rate(maas_requests_total{model="deepseek-r1"}[1h]))

联动告警：平均思维链 > 2500 持续 2 小时 → P2 告警，附上"最近提示词变更记录"链接------提示词谁改的、改了啥，Git 记录一查便知。

5.2 成本监控：让每一分钱有迹可循

成本监控的落地：网关把 Token 用量按 tenant × model × 功能 打点（3.2 节的 TOKENS 计数器），Grafana 做三个视图：

复制代码

视图1（实时）：当前小时 Token 消耗速率
视图2（日报）：按租户拆分的日消耗
视图3（环比）：与 7 天前的对比，异常波动自动标红

省钱闭环 ：发现 tenant_b 的 Token 消耗占 40% 且还在涨 → 查它的调用分布 → 发现是某个循环调用没加缓存 → 加缓存 → 成本回落。监控不是目的，省钱才是。

成本监控的三种拆分维度：

复制代码

维度1：按租户拆分 → 谁烧的钱最多？（对账/收费依据）
维度2：按模型拆分 → R1 和 V3 各占多少？（模型选型依据）
维度3：按功能拆分 → 哪个 Agent 最烧钱？（功能优化依据）

成本预警的阈值设计（结合业务量，别拍脑袋）：

指标	预警阈值	说明
日成本环比	> +30%	可能有人改了提示词/循环调用
单租户成本占比	> 40%	该租户可能需要单独配额
思维链成本占比	> 50%	提示词太开放，该优化了
缓存命中率	< 20%	缓存策略失效，白白烧钱

成本报表自动化 ：每天 9 点定时任务把昨日成本报表推到飞书群（用 4.3 的 webhook 改造一下），管理层和技术都看得到------成本透明，浪费就无处藏身。

5.3 告警疲劳治理

告警系统最大的敌人不是故障，是"告警太多没人看"。三个治理手段：

阈值要设"体感相关"的值：别设 CPU > 50% 这种无关痛痒的告警，用户感知不到的指标不告警；
告警要带"下一步"：每条告警写清"看哪个面板、查哪个日志、联系谁"；
每周复盘 ：统计本周告警，把"永远不准的"和"永远不看的"删掉，保持告警的"稀缺性"------告警越少，每条越值钱。

5.4 容量规划：用监控数据预测未来

监控不只用于"发现问题"，还能"预测问题"。把历史监控数据做趋势分析，提前规划容量：

复制代码

方法：取最近 30 天的请求量数据，做线性回归
预测：30 天后请求量 = 当前 × 增长率
行动：增长率 > 20%/月 → 提前升 Flexus 规格或调整 MaaS 配额

关键指标 ：看"峰值增长率"而不是"平均增长率"------促销季的峰值才是压垮系统的元凶。监控数据存够 3 个月后，容量规划就有依据了，从"被动扩容"变成"按数据扩容"。

5.5 监控指标速查表（建议打印贴在工位）

指标	来源	健康值	告警值	告警后第一步
CPU 使用率	node_exporter	< 70%	> 85% 10min	看是否有批量任务
内存使用率	node_exporter	< 75%	> 85% 10min	考虑升 Flexus 规格
磁盘使用率	node_exporter	< 60%	> 80% 1天	清理日志/镜像
请求成功率	网关	> 99.5%	< 99% 5min	看 5xx 分布
TTFT P95	网关	< 3s	> 8s 5min	查配额/排队
端到端 P95	网关	< 30s	> 60s 5min	查思维链长度
429 比例	网关	< 1%	> 5% 10min	升配额/加限流
思维链 Token	网关	< 1500	> 2500 2h	查提示词变更
Token 成本	网关	平稳	日环比 > 30%	查租户调用分布
缓存命中率	网关	> 20%	< 10% 1天	查缓存 key 设计

这张表是整套监控的"操作手册"------每个指标都对应一个动作，值班人不用思考，照着做就行。

5.6 日志与链路追踪：指标告诉你"出事了"，日志告诉你"为什么"

指标是"是什么"（what），日志是"为什么"（why）。一套完整的监控体系必须两者都有：

日志规范（网关层强制）：

复制代码

{
  "ts": "2026-09-06T10:00:00+08:00",
  "trace_id": "8f3a2b1c...",        // 全链路追踪 ID
  "tenant": "tenant_a",
  "model": "deepseek-r1",
  "action": "chat_completion",
  "ttft_ms": 3200,
  "e2e_ms": 52000,
  "reasoning_tokens": 1842,
  "output_tokens": 356,
  "status": 200
}

关键字段是 trace_id ：它把"一次请求"串起来------网关日志、Dify 日志、MaaS 调用记录，全都带同一个 ID。出问题时 grep trace_id 一条龙看完整链路：

复制代码

# 按 trace_id 追踪一次慢请求
grep "8f3a2b1c" /var/log/gateway/*.log     # 网关侧耗时
grep "8f3a2b1c" /var/log/dify/*.log        # Dify 侧处理
# 配合 Loki 在 Grafana 里可视化搜索更方便

没有 trace_id 的痛 ：告警说"TTFT 高"，你只能看聚合数据猜，不知道具体是哪个请求慢、慢在哪一段。加一个 trace_id，故障定位从"猜"变成"查"。

5.7 常见问题 FAQ

Q1：监控栈本身挂了怎么办？

监控系统也是系统，也会挂。三个缓解：① 监控容器设置 restart: always；② Prometheus 数据落盘（--storage.tsdb.retention.time=30d），挂了不丢历史；③ 关键告警（如网关宕机）用独立通道（比如云厂商的云监控），避免"监控自己先死"。

Q2：没有 Grafana 经验，会不会很难上手？

Grafana 的入门门槛很低------连上数据源、选指标、拖面板，半小时能做出第一个仪表盘。网上有大量中文教程，照着抄就行。真正难的是"设计指标"，而本文已经给了完整的指标清单（5.5 节速查表），照着建就行。

Q3：告警会不会太多，打扰同事？

会，所以分级（4.1 节）和聚合（4.5 节）是必须的。原则：P2/P3 白天推、晚上静默；P0/P1 全天推、合并发。告警数每周复盘，控制在"每周 < 20 条"是健康状态。

Q4：多租户场景下，告警怎么避免"一个租户出事，全员收到"？

按租户分桶的指标天然支持：告警规则里 by (tenant) 分组，推送时只 @ 该租户的负责人。全局告警（如网关宕机）才全员推送。

Q5：监控数据要存多久？

指标至少存 30 天（容量规划需要 3 个月趋势，建议 90 天）；日志存 7 天（排查用）；成本账单存 1 年（对账用）。Flexus 磁盘不够就挂云硬盘或把 Prometheus 数据放对象存储。

Q6：自建监控和华为云托管监控怎么选？

3 人以下团队用托管（省运维）；有专职运维用自建（更灵活）；最佳实践是混合：实例级指标用托管，模型调用级指标自建埋点。

六、实战复盘：一次真实故障的监控全过程

6.1 故障时间线

用一次真实发生的 MaaS 抖动事件，看监控体系如何工作：

复制代码

14:02  Grafana 告警：TTFT P95 突破 8s（P1 橙色）
14:05  值班人收到飞书推送，查看 TTFT 面板
14:08  发现 TTFT 只在 tenant_b 上飙升，其他租户正常
14:10  查 tenant_b 的调用日志：大量 2000 字以上的长文档分析
14:15  判断：tenant_b 在跑批量任务，占满了共享配额
14:20  操作：给 tenant_b 的批量任务加队列限速（5.4 节方案）
14:30  TTFT 回落至 2s，告警自动恢复

6.2 监控数据如何支撑这次定位

时间线看着简单，背后是监控指标的功劳。逐条对应：

复制代码

"TTFT 只在 tenant_b 飙升" ← 指标按租户分桶（3.2 节设计）
"大量 2000 字长文档分析" ← 网关日志按租户检索（Loki）
"占满共享配额" ← MaaS 控制台的配额监控
"加队列限速" ← 多租户文章的预案（有 Runbook 才能 8 分钟搞定）

如果没有按租户分桶 ，这次故障会变成：全体 TTFT 高 → 以为 MaaS 挂了 → 提单给华为云 → 半天后查明是 tenant_b 自己刷的------指标分桶粒度，决定了故障定位速度。

6.3 复盘：监控体系的三个价值

发现早：用户投诉前 20 分钟就发现（14:02 vs 用户 14:20 才可能投诉）；
定位准：按租户分桶的指标让问题 6 分钟内锁定到 tenant_b；
恢复快：因为有预案（队列限速），8 分钟解决问题。

如果没有监控 ：14:20 用户开始投诉 → 14:40 才有人排查 → 15:00 才定位 → 15:30 才恢复。监控让故障时间从 90 分钟压缩到 28 分钟。

6.4 不同规模团队的监控方案

监控方案没有银弹，按团队规模选合适档位：

规模	方案	投入	说明
个人开发者	日志 + 手动看	0.5 天	看 Dify 自带日志 + MaaS 控制台
小团队（3-10人）	Prometheus + Grafana + 飞书	2 天	本文方案，性价比最高
中大型团队	加 Loki 日志 + 告警 Runbook + 值班	1 周	指标+日志联动，多人协作
企业级	接入统一监控平台（如华为云 AOM）	按需	与云上资源打通，免自建

华为云用户的捷径 ：如果不想自建 Prometheus，华为云有托管的监控服务（云监控 CES / AOM），Flexus 的 CPU/内存指标开箱即用，把网关的 /metrics 接入即可，省去运维 Prometheus 本身的工作量。自建和托管的选择标准：有没有专人维护监控系统。没有就选托管。

6.5 复盘清单

每次故障后，回答四个问题：

复制代码

□ 1. 监控为什么没更早发现？（指标盲区？阈值太宽？）
□ 2. 告警链路哪里断了？（推送失败？没人值班？）
□ 3. 定位为什么慢？（指标分桶不够细？日志缺失？）
□ 4. 下次如何更快？（补指标？加预案？写 runbook？）

持续改进：监控体系是"养"出来的，不是"搭"出来的。每次故障都让监控更聪明一点。

6.6 监控的投入产出账

有人觉得"搭监控浪费时间"，算笔账就明白了：

复制代码

投入：2 小时搭建 + 每周 1 小时维护 ≈ 每月 6 小时
产出（按一次 P1 故障算）：
  无监控：故障 90 分钟 × 平均 3 人排查 = 4.5 人时
  有监控：故障 28 分钟 × 平均 1 人处置 = 0.5 人时
  单次节省 ≈ 4 人时
  每月按 2 次故障算 ≈ 节省 8 人时

成本监控的额外产出：
  及时发现成本异常（如思维链暴涨），每月省 10-20% 的 MaaS 费用
  按月 3000 元账单算，每月省 300-600 元

结论：监控是 ROI 最高的"基础设施投资"，没有之一。

别把监控当成本，把它当保险------平时感觉不到，出事才知道多值钱。

数据不会说谎，监控就是数据给你的"第二双眼睛"------它看见你看不见的异常。

七、总结

7.1 核心结论

AI 应用监控 = 传统四指标 + AI 专属四指标，模型层比应用层更重要；
网关是埋点的最佳位置，所有请求都经过它，指标最全；
Prometheus + Grafana 2 小时能跑通，成本几乎为零（都跑在 Flexus 上）；
告警分级是灵魂：P0 立即、P1 15 分钟、P2 当日、P3 周会，别让"狼来了"毁掉告警；
监控是省钱工具：思维链和 Token 成本监控，直接转化为真金白银的节省。

7.2 落地路线图：2 小时跑通

别被上面的内容吓到，实际落地只要 2 小时：

复制代码

第 1 小时：搭建监控栈
  0-20 分钟  网关加 /metrics 埋点（3.2 节代码）
  20-40 分钟 Prometheus + Grafana 起容器（3.3 节）
  40-60 分钟 导入 3 个核心面板（3.4 节）

第 2 小时：配置告警
  0-20 分钟  写 4 条核心告警规则（4.2 节）
  20-40 分钟 接飞书 webhook（4.3 节）
  40-60 分钟 配置告警分级 + Runbook（4.4 节）

之后持续迭代：每周看一次面板，每月复盘告警

上线后的第一周建议 ：把告警阈值调"宽松"一点（宁可不报也别误报），等系统稳定了再收紧------先让监控跑起来，再让监控变聪明。

7.3 一张图记住本文

复制代码

用户 → 网关（埋点）→ MaaS
              │
              ▼
        Prometheus（采集+告警规则）
              │
        ┌─────┴─────┐
        ▼           ▼
    Grafana     飞书机器人
    （可视化）    （分级推送）

7.4 最后的话

AI 应用跑得再快，没有监控就是"盲飞"。给应用装上眼睛和耳朵，让故障在用户发现之前就被处理------这才是从"能用"到"可靠"的分水岭。

本文所有配置基于华为云 MaaS DeepSeek + Flexus X + Dify 真实环境，可直接照抄。如果你也在搭 AI 监控，欢迎在评论区分享你的指标设计------监控踩过的坑，大家绕着走。

八、参考资源

写在最后：监控的意义不是"看到问题"，而是"在用户看到问题之前看到问题"。如果这套监控体系帮你少熬了几个夜，点赞收藏是对我最大的鼓励！🚀