为什么 AI 生成的应用需要监控

当你的 AI 生成应用上线后，你需要洞察三个层面：应用健康状况、基础设施负载，以及用户体验。没有监控，内存泄漏或慢查询只有在用户投诉时才会暴露。AI 生成的代码尤其容易出现微妙的性能问题——模型写出的代码虽然能编译运行，却可能没有使用最优算法、可能泄漏数据库连接，或者可能向 OpenAI 等昂贵服务发起冗余 API 调用。将监控视为部署的核心步骤（而非事后补救），正是原型与生产级系统之间的分水岭。

本课涵盖的四大支柱：结构化日志、错误追踪、性能指标，以及自动伸缩配置。它们共同帮助你发现问题、定位根因，并自动响应负载变化。

结构化日志

普通的 print 语句既不可搜索、不可筛选，又会在容器重启时丢失。结构化日志是指以 JSON 对象的形式输出日志，并使用一致的字段（timestamp、level、route、user_id、duration_ms、status_code）。集中式聚合工具如 Loki、CloudWatch Logs 或 Datadog 可以对其进行索引和查询。

在 Python + FastAPI 中，应使用 `logging` 模块配合 JSON 格式化器，而不是依赖 `print`：

import logging
import json
from datetime import datetime, timezone

class JsonFormatter(logging.Formatter):
    def format(self, record):
        return json.dumps({
            "ts": datetime.now(timezone.utc).isoformat(),
            "level": record.levelname,
            "msg": record.getMessage(),
            "route": getattr(record, "route", None),
            "duration_ms": getattr(record, "duration_ms", None),
        })

logger = logging.getLogger("app")
handler = logging.StreamHandler()
handler.setFormatter(JsonFormatter())
logger.addHandler(handler)
logger.setLevel(logging.INFO)

现在每一行日志都是一个 JSON 对象，你的聚合工具可以按字段筛选。在 Node.js 中等价的是 `pino`；在 Go 中则使用 `zap` 或 `slog`。关键在于一致性：选定一种格式，并在所有地方统一使用——包括后台 worker 和定时任务的日志。

错误追踪

日志告诉你发生了什么；错误追踪则告诉你问题何时发生、发生的频率，并提供完整的堆栈跟踪和聚合信息。最常用的两个工具是 Sentry 和 Rollbar。它们都通过 SDK 集成，包裹你的应用、捕获未处理异常，并将重复错误归类为 issue。

对于 Node.js Express 应用，初始化只需要两行代码：

const Sentry = require("@sentry/node");
Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.2 });

对于 Python Flask，等价方案是使用 `sentry-sdk` 并集成 `FlaskIntegration`。初始化完成后，每个未处理的异常都会被自动上报，并附带完整的堆栈跟踪、请求头以及应用的发布版本。关键配置：将生产环境的 `tracesSampleRate` 设置在 0.1 到 0.3 之间——100% 采样追踪成本高昂，而且很少有必要。使用 `tags`（例如 `plan: pro`）捕获业务相关上下文，以便按用户分群筛选错误。

一个常见的错误：只在主进程中追踪错误。如果你运行后台 worker（Celery、BullMQ、Sidekiq），每个 worker 都需要独立的 SDK 初始化。否则静默 worker 中的错误永远不会暴露出来。

性能监控与四大黄金信号

Google 的「四大黄金信号」框架是任何性能仪表盘的起点。延迟：请求耗时（p50、p95、p99——不仅仅是平均值）。流量：每秒请求数。错误：失败请求的比率。饱和度：距离容量上限的接近程度（CPU、内存、队列深度）。

实践中，你可以使用 Prometheus + Grafana（自托管）或 Datadog / New Relic（SaaS 服务）来测量这些指标。对于 Kubernetes 部署，Prometheus node-exporter 和应用客户端库（例如 FastAPI 的 `prometheus-fastapi-instrumentator`、Node 的 `prom-client`）会暴露 `/metrics` 端点，由 Prometheus 每 15 秒抓取一次。Grafana 再通过告警规则将其可视化（例如当 p95 延迟持续5 分钟超过 2 秒时呼叫值班人员）。

对于 AI 密集型应用，建议添加一个自定义指标：每个请求的外部 API 成本。追踪每次请求消耗的 token 数量或花费的美元金额——这是发现由死循环或配置错误的 prompt 所导致的成本失控的唯一方法。

自动扩缩容规则

自动扩缩容会根据负载指标增加或减少计算资源。在 Kubernetes 上使用 Horizontal Pod Autoscaler (HPA)。在 AWS 上使用 ECS Service Auto Scaling 或 EC2 Auto Scaling Groups。在无服务器平台（Vercel、Cloud Run、Lambda）上，扩缩容通常是自动的，但你可以控制并发数和内存配置。

无论在哪里，核心配置都是一样的：选择一个监控指标（CPU、内存、单 Pod 请求数、队列深度）以及目标阈值。下面是一个典型的 Kubernetes HPA 配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "100"

该 HPA 在 2 到 20 个 Pod 之间扩缩容，当 CPU 超过 60% 或单 Pod 平均每秒请求数超过 100 时增加容量。将 `minReplicas: 2`（而非 1）可以避免部署和滚动更新期间的停机。`maxReplicas` 设得太低会在流量峰值时造成限流；设得太高则会导致云成本失控——应根据最昂贵的现实场景而非平均值来设定上限。

对于 AI 工作负载，单纯基于 CPU 横向扩展（scaling）具有误导性，因为瓶颈通常是等待 OpenAI 响应或数据库查询的外部 API 调用。应改为基于队列深度（task queue 中待处理请求的数量）进行扩展，或结合 CPU + 队列深度指标。此外，冷启动延迟也是一个因素：如果用户体验对延迟敏感，请始终保持至少一个预热的 pod（warm pod）处于运行状态。

总结

监控与自动伸缩并非独立的两个阶段——它们构成了一个反馈循环：指标揭示何时需要扩容；日志和错误追踪工具揭示在高负载下哪里出了问题；自动伸缩则防止问题的发生。对于 AI 生成类应用而言，其特有的风险包括失控的外部 API 成本以及模型调用带来的不可预测延迟，因此需要专门追踪这些指标。建议从简单起步：一个结构化日志记录器、一个错误追踪工具（如 Sentry）、一个基于 CPU 的基础 HPA。仅当仪表盘显示确有需要时，再逐步增加复杂度。