指标 | 描述 | 目标阈值 | 告警触发
——–|——|———-|———-
延迟 (p50) | 中位响应时间 | 3 秒
延迟 (p95) | 95 百分位响应时间 | 8 秒
延迟 (p99) | 99 百分位响应时间 | 15 秒
Token 使用量 | 每次请求的总 token 数 | 每周跟踪趋势 | > 10% 突增
错误率 | 每分钟失败请求数 | 2%
工具调用成功率 | 成功的工具调用比例 | > 99% | < 95%
每次请求成本 | API 和基础设施总成本 | 根据预算 | > 20% 增长
实施实时仪表板,将这些指标与历史趋势并排显示。使用移动平均等聚合函数来平滑瞬态尖峰,同时捕捉持续性问题。
3. 日志与审计追踪
结构化日志实现了高效的搜索和分析:
“`json
{
“timestamp”: “2026-10-01T00:00:00Z”,
“agent_id”: “production-agent-01”,
“session_id”: “abc-123”,
“trace_id”: “xyz-789”,
“level”: “info”,
“event”: “tool_called”,
“tool”: “search_web”,
“parameters”: {“query”: “…”, “limit”: 5},
“result”: {“status”: “success”, “results_count”: 3},
“latency_ms”: 1234,
“tokens”: {“input”: 500, “output”: 150},
“cost_usd”: 0.015
}
“`
审计追踪最佳实践:
记录所有用户交互,并对 PII(个人身份信息)进行脱敏
记录工具执行及脱敏后的参数
跟踪配置变更和访问事件
维护不可变日志,采用追加只写存储
实施符合法规要求的保留策略
工具监控
工具是智能体架构中最复杂的层级,需要专门的监控策略。
成功/失败追踪
全面监控工具执行结果:
按工具的成功率 :计算成功与失败的调用比例
失败模式分析 :识别常见错误类型和复发模式
延迟分布 :按工具跟踪响应时间百分位数
资源利用率 :监控工具调用期间的 CPU、内存和网络使用
成功率持续下降的工具通常表明上游服务退化或配置漂移。
速率限制管理
实施智能速率限制处理:
配额追踪 :监控 API 消耗相对于提供商限制的用量
自适应限流 :在触及限制前自动降低请求频率
缓存策略 :存储频繁查询结果以减少冗余调用
回退机制 :在主提供商限制达到时切换到替代提供商
速率限制违规会导致级联故障。主动管理可以防止突然的性能退化。
凭据与访问监控
通过分层控制确保工具访问安全:
凭据轮换计划 :按计划定期自动轮换 API 密钥
访问模式分析 :检测来自异常来源的异常凭据使用
权限范围限制 :为每个工具授予最低必要权限
审计日志 :记录所有凭据访问和使用事件
错误处理与恢复
健壮的错误处理将脆弱的智能体转化为弹性系统。
优雅降级策略
设计智能体使其优雅失败而非灾难性崩溃:
1. 指数退避重试 :对瞬态故障以递增延迟重试
2. 回退执行 :主操作失败时执行备选操作
3. 缓存响应 :在适当情况下返回之前成功的结果
4. 用户沟通 :清晰说明发生了什么以及接下来会做什么
降级模式示例:
“`python
async def execute_with_fallback(request, primary_tool, fallback_tool):
try:
result = await primary_tool.execute(request)
return result
except ToolTimeoutError:
return await fallback_tool.execute_cached(request)
except ValidationError:
return await fallback_tool.with_corrections(request)
“`
错误分类框架
对错误进行分类以确定适当的响应:
类别 | 示例 | 响应策略
———|——|———-
瞬态错误 | 网络超时、速率限制 | 带退避的重试
永久错误 | 无效输入、权限拒绝 | 快速失败,记录供审查
部分错误 | 部分工具成功,其他失败 | 聚合结果,继续执行
系统性错误 | 提供商宕机、配置错误 | 升级处理,激活回退
熔断器模式
为关键依赖项实施熔断器:
闭合状态 :正常运行,请求正常通过
打开状态 :熔断触发,请求快速失败而不调用依赖项
半开状态 :允许少量请求测试恢复情况
熔断触发阈值:
错误率超过 30 秒内 50%
延迟超过正常基线的 2 倍
重复检测到特定错误模式
通过可观测性优化成本
理解资金流向可实现有效的成本管理。
Token 使用分析
监控 token 消耗以识别优化机会:
输入 token 比例 :跟踪哪些提示词消耗的 token 最多
输出冗余度 :衡量输出长度与实际用处的关系
对话增长 :检测上下文窗口低效膨胀的会话
模型选择影响 :比较不同模型层级的成本
优化技巧:
将对话历史压缩为摘要
简单查询使用更经济的模型
为重复模式实现响应缓存
为每次操作设置最大 token 预算
成本分摊策略
按组织维度分解成本:
智能体级别归因 :将成本归属到特定的智能体部署
会话追踪 :将支出归属到用户会话
工具成本细分 :识别高成本的工具依赖
基于时间的分析 :发现高峰使用期以进行容量规划
预算告警配置
设置主动成本监控:
每日支出上限 :超出每日预算时告警
周度趋势分析 :将当前周与历史平均值进行比较
按智能体的预算 :为单个智能体分配预算
异常检测 :自动标记异常支出模式
安全监控
在生产系统中,安全与可观测性密不可分。
异常检测方法
通过多种信号监控可疑活动:
提示词模式分析 :检测异常输入序列或注入尝试
工具使用异常 :标记偏离正常模式的工具调用
地理不可能性 :当会话同时出现在相距遥远的地点时发出警报
时间异常 :检测非工作时间访问或高频请求
审计追踪要求
维护全面的安全日志:
所有智能体之间的通信
带有完整参数集的工具执行
凭据访问和轮换事件
配置和权限变更
用户认证和授权事件
事件响应流程
为安全事件准备系统化响应:
1. 检测 :在异常阈值上自动告警
2. 隔离 :立即隔离受损组件
3. 取证 :保留日志和执行链路供分析
4. 沟通 :按严重程度分类通知利益相关者
5. 恢复 :从已知良好的备份中恢复
6. 事后复盘 :记录经验教训和预防措施
SmaugBrain 可观测性功能
SmaugBrain 为每次部署提供企业级可观测性:
智能体级别遥测
执行链路 :完整的请求生命周期可视化
工具调用指标 :按工具的成功率和延迟分析
Token 分析 :详细的输入/输出 token 跟踪
成本归因 :按智能体和会话实时计算成本
仪表板与可视化
实时监控 :显示系统健康的实时仪表板
历史趋势 :多周性能对比
自定义指标 :定义和跟踪组织特定的 KPI
导出功能 :CSV 和 JSON 导出以供进一步分析
日志管理
集中收集 :聚合所有智能体的日志
结构化解析 :自动提取关键字段
高级搜索 :使用自然语言或结构化过滤器查询日志
保留策略 :根据合规要求配置可变的日志保留
合规与报告
审计导出 :为安全审查生成报告
监管合规 :内置常见法规的模板
数据保留验证 :自动检查是否遵守保留政策
访问审计 :完整的谁访问了哪些数据的审计记录
实施路线图
按照以下分阶段方法部署可观测性:
阶段 1:基础(第 1-2 周)
[ ] 设置集中式日志基础设施
[ ] 在所有智能体代码中实施结构化日志
[ ] 配置基础指标收集(延迟、错误、token)
[ ] 创建包含关键 KPI 的基础仪表板
[ ] 针对严重故障建立告警机制
阶段 2:链路追踪(第 3-4 周)
[ ] 部署分布式链路追踪系统
[ ] 对所有智能体入口和出口点进行插桩
[ ] 跨服务添加链路上下文传播
[ ] 创建基于链路的调试工作流
[ ] 构建常见失败模式的可视化
阶段 3:成本优化(第 5-6 周)
[ ] 实施 token 使用跟踪
[ ] 设置按智能体和会话的成本分摊
[ ] 创建预算告警和报告
[ ] 建立优化建议机制
[ ] 编写成本优化手册
阶段 4:安全集成(第 7-8 周)
[ ] 部署异常检测系统
[ ] 配置安全审计日志
[ ] 实施事件响应自动化
[ ] 开展安全审查演练
[ ] 完善合规文档
阶段 5:持续改进(持续进行)
[ ] 每周可观测性审查会议
[ ] 每月成本优化审查
[ ] 每季度安全审计更新
[ ] 持续优化仪表板
[ ] 团队培训与知识共享
生产可观测性最佳实践
1. 为可调试性而设计
从第一天起就将可观测性融入架构:
在所有请求头中包含链路 ID
记录结构化数据,而非仅文本
实现健康检查端点
添加优雅关闭钩子以确保日志完整刷写
2. 平衡可见性与隐私
在保持有用日志的同时保护敏感信息:
自动对 PII(姓名、邮箱、地址)进行脱敏
对敏感标识符进行哈希或令牌化处理
实施数据保留策略
定期审计日志访问
3. 建立有意义的告警
通过良好校准的阈值避免告警疲劳:
基于业务影响而非仅技术指标设置告警
需要满足多个条件才触发
在告警中包含可操作的补救步骤
每季度审查和调整阈值
4. 实践基于手册的响应
为常见事件记录操作流程:
为频繁告警类型创建操作手册
直接从告警通知链接到操作手册
通过演练定期测试操作手册
每次事件后更新操作手册
5. 培育可观测性文化
让监控成为每个人的责任:
培训开发者掌握日志记录最佳实践
将可观测性纳入代码审查检查清单
表彰提升可靠性的团队
在整个组织范围内分享事后复盘
常见问题
问:我如何为 AI 智能体选择正确的可观测性技术栈?
答:根据你的规模和专业知识进行评估。小团队可能更倾向于使用 Datadog 或 New Relic 等托管解决方案。拥有现有基础设施的大型组织可以利用 OpenTelemetry 配合自定义仪表板。从简单开始,随着需求增长逐步扩展。
问:最初最重要的跟踪指标有哪些?
答:专注于五个关键指标:请求延迟(p50、p95)、错误率、每次请求的 token 使用量、工具调用成功率和每次智能体会话的成本。这些指标可立即提供系统健康状况和经济性的可见性。
问:如何在可观测性日志中处理敏感数据?
答:在日志层实施自动 PII 检测和脱敏。使用正则表达式、命名实体识别或专门的库在数据进入日志之前识别并掩盖敏感信息。切勿记录凭据、token 或个人数据。
问:监控多智能体系统的最佳方法是什么?
答:使用带有跨多个智能体的关联 ID 的分布式链路追踪。实施智能体间通信日志,跟踪共享资源争用,并监控智能体间依赖链。服务网格有助于可视化这些关系。
问:我应该多久审查一次可观测性数据?
答:每日运营审查用于处理即时问题,每周趋势分析用于优化机会,每月战略审查用于容量规划和架构决策。
问:我能否在现有智能体上事后添加可观测性?
答:可以,但你将丢失历史上下文。立即开始插桩,并使用模拟流量或回放存储的日志来建立基线。优先处理关键路径。
问:如何在可观测性开销与智能体性能之间取得平衡?
答:对高流量操作使用采样(采样 10% 的请求),实施异步日志以避免阻塞,采用分层监控——关键路径完全可见,其他路径使用轻量级插桩。
问:可观测性与智能体可靠性之间的关系是什么?
答:可观测性通过使系统行为透明来实现可靠性。你无法改进、调试或优化你无法衡量的事物。全面的可观测性是生产级可靠性的先决条件。
结论
有效的可观测性将 AI 智能体部署从不确定的黑盒转变为透明、可控的系统。通过实施全面的链路追踪、结构化指标、自动告警和成本监控,你获得了维持生产可靠性并控制支出的所需可见性。
SmaugBrain 为构建生产就绪的 AI 智能体系统提供可观测性基础。从基础指标开始,扩展到分布式链路追踪,并随着部署复杂性的增长不断优化你的监控系统。
了解更多关于 SmaugBrain 可观测性和监控功能的信息,请访问 https://www.smaugbrain.com/
—
*本指南定期更新,以反映 AI 智能体可观测性和生产监控中新兴的最佳实践。*
—
使用 SmaugBrain 构建生产就绪的 AI 智能体。了解更多关于 SmaugBrain 。
Cookie Consent We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Manage your cookie preferences below:
Essential cookies enable basic functions and are necessary for the proper function of the website.
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
These cookies are used for managing login functionality on this website.
wordpress_logged_in
Used to store logged-in users.
Persistent
wordpress_sec
Used to track the user across multiple sessions.
15 days
wordpress_test_cookie
Used to determine if cookies are enabled.
Session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days