监控和可观察性：APM、日志记录和警报最佳实践

根据 Splunk 的可观察性状态报告，拥有成熟可观察性实践的公司解决事件的速度提高了 69%。 监控会告诉您出现问题。可观察性告诉你它为什么被破坏以及去哪里寻找。花几个小时解决每个生产问题和在几分钟内解决它们之间的区别取决于您对系统进行检测、构建日志和设计警报的程度。

要点

• 可观察性的三大支柱——指标、日志和跟踪——各自回答不同的问题并共同提供完整的系统理解
• 针对症状（面向用户的影响）而不是原因（内部指标）发出警报，以减少警报疲劳并捕获新的故障模式
• 具有相关 ID 的结构化 JSON 日志记录支持跨服务搜索和重建请求流
• SLO（服务级别目标）将监控从“是否有任何问题”转变为“我们是否履行了对用户的承诺”

---

可观察性的三大支柱

可观察性建立在三种互补的数据类型之上。每个支柱都回答有关系统行为的不同问题。

指标

指标是定期收集的数值测量值。他们回答“发生了什么”问题：每秒有多少个请求？平均响应时间是多少？正在使用多少内存？

特点：

• 聚合且紧凑——数百万个事件被压缩到时间序列计数器中
• 存储成本低廉——固定大小的数据，无论流量如何
• 仪表板和警报的理想选择
• 有限的上下文 - 您知道响应时间增加，但不知道哪些特定请求很慢

关键指标类型：

• 计数器 -- 单调递增的值（总请求数、总错误数）
• Gauge -- 上升和下降的值（当前 CPU 使用率、活动连接）
• 直方图 -- 值的分布（响应时间百分位数、有效负载大小）
• 摘要 -- 客户端预先计算的百分位数

日志

日志是离散事件的带时间戳的文本记录。他们回答“发生了什么”问题：用户看到了什么错误消息？哪些参数传递给了失败的函数？问题发生时系统处于什么状态？

特点：

• 丰富的上下文——有关单个事件的任意细节
• 规模昂贵——高流量系统每小时生成千兆字节的日志
• 可搜索——通过全文搜索查找特定事件
• 需要结构——非结构化日志行很难解析和关联

痕迹

跟踪跟踪跨多个服务的单个请求。他们回答“时间花在哪里”的问题：哪个服务调用速度慢？请求路径在哪里分歧？哪个数据库查询是瓶颈？

特点：

• 显示因果关系——操作之间的父子关系
• 揭示分布式系统行为——跨服务边界的延迟
• 需要大规模采样——追踪每个请求的成本很高
• 对于微服务至关重要——没有痕迹，调试多服务流只是猜测

---

可观测性工具生态系统

选择堆栈

对于大多数成长型企业，我们建议从以下方面入手：

1. Sentry 用于错误跟踪——通过完整的堆栈跟踪、源映射和发布跟踪来捕获异常
2. Prometheus + Grafana 用于指标——开源、久经考验、广泛的集成生态系统
3. 结构化日志记录到托管服务 - Datadog Logs、AWS CloudWatch 或 Grafana Loki，具体取决于您的云提供商
4. OpenTelemetry 用于仪器仪表——适用于任何后端的供应商中立标准

对于需要单一供应商的团队来说，Datadog 提供了最佳的一体化体验，但大规模成本很高。 Grafana 的开源堆栈（Prometheus、Loki、Tempo）提供同等功能，许可成本较低，但运营负担较高。

---

结构化日志记录最佳实践

像 Error processing order 12345 for user john@example.com 这样的非结构化日志行是人类可读的，但对机器不利。结构化 JSON 日志支持对特定字段进行搜索、过滤、聚合和警报。

日志结构

每个日志条目应包括：

相关 ID

相关 ID 是在每个请求开始时生成的唯一标识符，并传递给每个下游服务调用、数据库查询和后台作业。调查问题时，按相关 ID 搜索会显示所有服务中与该特定请求相关的每个日志条目。

实现： 在 API 网关或负载均衡器处生成 UUID，将其传递到 X-Request-ID 标头中，并将其包含在每个日志条目中。在 NestJS 中，使用中间件提取或生成相关 ID 并将其存储在异步本地存储上下文中。

日志级别

一致地使用日志级别：

• DEBUG -- 详细的诊断信息，在生产中禁用，除非主动调试
• 信息 -- 重大业务事件（下订单、用户注册、付款处理）
• 警告 -- 系统处理但应调查的意外情况（重试成功、缓存未命中、已弃用的 API 调用）
• 错误 -- 影响用户体验的故障（请求失败、付款被拒绝、外部服务不可用）
• 致命 - 应用程序无法继续（数据库无法访问，缺少所需的配置）

日志保留和成本管理

日志是存储成本最高的可观察性数据。实施分层保留：

• 热存储（30天） -- 全文可检索，查询快，成本高
• 温存储（90 天） -- 压缩、查询速度较慢、成本适中
• 冷存储（1年以上） -- 归档、按需查询、低成本
• 调试日志 -- 除非积极排除故障，否则不要存储在生产环境中

---

警报设计

糟糕的警报会导致警报疲劳——团队停止响应警报，因为大多数警报都是误报或低优先级的噪音。良好的警报可以揭示需要人工干预的真正问题。

针对症状而非原因发出警报

基于症状的警报（良好）：“/api/orders 错误率超过 1%，持续 5 分钟”——这直接表明用户影响，无论根本原因如何。

基于原因的警报（不良）：“数据库 CPU 超过 90%”——这可能会也可能不会影响用户。数据库可能可以很好地处理 95% 的 CPU，也可能可以处理 50% 的 CPU 但完全死锁。

基于原因的指标属于用于调查的仪表板，而不是警报规则。

警报严重级别

减少警报噪音

1. 与组相关的警报 - 如果数据库出现故障，您会收到一个“数据库不可用”警报，而不是来自依赖于该数据库的每个服务的 50 个警报
2. 需要持续违规——“CPU 高于 90% 持续 5 分钟”而不是“CPU 高于 90% 持续 1 秒”以避免瞬时峰值
3. 自动解决——当情况解决时，警报应自动清除
4. 每周警报审查 -- 审查所有发出的警报，识别并修复或消除那些不需要人工操作的警报
5. 待命反馈循环 - 每次待命轮换后，工程师都会记录哪些警报是可操作的以及哪些需要调整

---

SLO：服务级别目标

SLO 将监控从被动式（“出了问题，修复它”）转变为主动式（“我们正在消耗错误预算，让我们在用户注意到之前进行调查”）。

定义 SLO

SLO 定义服务的目标可靠性。它包括：

• SLI（服务水平指示器） -- 正在测量的指标（请求成功率、延迟百分位）
• 目标 -- 定义可接受性能的阈值（99.9% 成功率，P95 低于 200 毫秒）
• 窗口 -- 评估目标的时间段（滚动 30 天）

电子商务平台的 SLO 示例

|服务 |英伟达™目标|错误预算（30 天）| |---|---|---|---| |产品API |成功回复（非 5xx）| 99.9% | 43 分钟停机时间 | |结帐 |交易成功| 99.95% | 21 分钟停机时间 | |搜索 | 500 毫秒内返回结果 | 99% | 7.2小时反应缓慢| |管理仪表板 |页面加载时间不到 3 秒 | 95% | 36小时慢速加载|

错误预算

错误预算是 SLO 目标的倒数。 99.9% 的 SLO 允许 0.1% 的错误——每月大约 43 分钟的停机时间。当错误预算耗尽时，团队会将重点从功能转移到可靠性工作。

错误预算为工程和产品团队之间提供了一种共享语言。两个团队不必争论服务是否“足够可靠”，而是可以准确地了解剩余的错误预算，并就发布新功能与投资稳定性做出数据驱动的决策。

---

常见问题

大规模可观测性的成本是多少？

可观测性成本范围从开源堆栈（Prometheus、Grafana、Loki）每台主机每月 10-50 美元到商业解决方案（Datadog、New Relic）每台主机每月 30-100 美元以上。最大的成本驱动因素是日志量——通过采样调试日志、压缩存储的日志和设置适当的保留期限来优化。对于大多数少于 50 台服务器的企业，成本为每月 500-2,000 美元。

我应该使用 OpenTelemetry 还是特定于供应商的代理？

使用开放遥测。它是仪器仪表的行业标准，受到每个主要可观测性供应商的支持，并防止供应商锁定。您可以切换后端（例如，从 Datadog 切换到 Grafana），而无需重新检测代码。特定于供应商的代理有时会提供更深入的集成，但可移植性的权衡并不值得。

如何设置对 NestJS 应用程序的监控？

在 NestJS 中，使用拦截器进行请求计时，使用异常过滤器进行错误跟踪，使用中间件进行相关 ID 传播。将 Sentry 与 @sentry/nestjs 集成以进行错误跟踪。使用 /metrics 端点上公开的 prom-client 库导出 Prometheus 指标。使用结构化日志记录，并为 JSON 输出配置 nestjs-pino 或 winston。

监控和可观察性有什么区别？

监控会告诉您预定义的事情何时出错（CPU 高、错误率上升、磁盘已满）。可观察性使您可以提出有关系统行为的新问题，而无需部署新的工具。当您可以从外部输出（指标、日志、跟踪）了解系统的内部状态时，系统就是可观察的。在实践中，良好的监控是可观察性的一个子集。

我如何说服我的团队投资于可观察性？

跟踪可观察性改进前后生产事件的平均解决时间 (MTTR)。具有良好可观察性的团队通常可以将 MTTR 降低 60-70%。将节省的时间乘以工程成本即可显示投资回报率。还可以跟踪通过监控与用户报告检测到的事件数量——主动检测可以建立客户信任。

---

下一步是什么

如果您一无所有，请从错误跟踪（Sentry）开始——它通过捕获生产错误并发出警报来提供最直接的价值。接下来，添加具有相关 ID 的结构化日志记录。然后使用 Prometheus 和 Grafana 仪表板实现指标收集。最后，当您有多个服务时，请添加分布式跟踪。

有关完整的性能工程背景，请参阅我们关于扩展您的业务平台 的支柱指南。要优化您监控的基础设施，请阅读我们的基础设施扩展指南。

ECOSIRE 为在 Odoo ERP 和自定义架构上运行的业务平台实现可观察性堆栈。 联系我们的 DevOps 团队 进行监控和可观察性评估。

---

由 ECOSIRE 发布 — 通过 Odoo ERP、Shopify 电子商务 和 OpenClaw AI 等人工智能驱动的解决方案帮助企业扩展规模。