Datadog：来自 50 多个 AWS 应用的可观测性经验

Source: Dev.to

请提供您希望翻译的具体文本内容，我将按照要求保留源链接并进行简体中文翻译。

Lesson 1 – Datadog 超越可观测性；它是可靠性工具

虽然我自称是 Observability practitioner（可观测性实践者），但我也是一名 SRE（站点可靠性工程师）。我的最终目标是为终端用户提供世界级的客户体验，因此我在工作中大量依赖站点可靠性工程（SRE）概念。在 SRE 的世界里，我们关注以下几个支柱：

• Architecture（架构） – 可靠性来源于稳健的架构和设计模式
• Observability（可观测性） – 跨系统的全栈可视化
• SLI/SLO & Error Budgets（服务水平指标/目标与错误预算） – 衡量客户体验
• Release & Incident Engineering（发布与事故工程） – 将运维视为软件问题来处理
• Automation（自动化） – 消除、减少、简化并实现自动化
• Resilience Engineering（弹性工程） – 混沌工程与故障测试
• People & Awareness（人员与意识） – 可靠性中的人为因素

可观测性是可靠性工程的关键支柱。我们通过实现可观测性来 测量 客户体验。当体验下降时，我们能够快速定位根本原因并予以解决——理想情况下能够及时消除问题。Datadog 支持上述所有支柱，这也是我将其视为 提升可靠性的工具，而不仅仅是可观测性工具的原因。

第2课 – Datadog是你的合作伙伴：可观测性是一段旅程

通常，我们从 保持系统运行 开始，然后使系统可观测，关联数据，最后实现 AIOps。这是一段旅程。我已经发布了完整的 AWS Observability Maturity Model V2 指南。Datadog 完全具备支持旅程中每一步的能力。

第3课 – Datadog SLO：衡量客户体验

我将可观察性视为衡量客户体验的副产品。典型的流程是：

1. 为任何应用定义 服务水平指标（SLI）。
2. 将这些 SLI 转换为 服务水平目标（SLO）。

一旦使用 Datadog 启用 应用性能监控（APM） 并拥有日志、指标和追踪，就可以构建一个 SLI 仪表盘——系统的唯一可信来源。随后，你可以在 Datadog 中将其转换为有意义的 SLO。

Datadog 提供三种类型的 SLO：

• 按计数 – 好事件 ÷ 总事件。
• 按监控正常运行时间 – 使用合成测试来评估正常运行时间。
• 按时间片 – 使用自定义正常运行时间定义。

如果你已经有 SLO，则已经在衡量客户体验，并且远远领先于竞争对手。

Lesson 4 – Datadog Real User Monitoring (RUM): Know What Your End Users Are Doing

Observability gives you insight into your system’s internal state, but you also need to know what end users are experiencing. That’s where RUM shines. It not only surfaces metrics related to end‑user experience, but features like Session Replay let you watch exactly what customers are doing. When a customer complains that something isn’t working, you’re only a few steps away from pinpointing the issue with Datadog RUM.

第5课 – 通过少量代码更改增强内置遥测

Datadog 开箱即用表现出色，但通过一些有针对性的代码更改可以释放巨大的收益：

• 将加密的重要细节注入会话，以便能够按用户、产品等过滤 RUM 数据。
• 为 APM 添加自定义仪表，在难以触及的角落获得更深入的可视性。

即使是适度的增强也能产生“魔法”般的效果。

---

第6课 – 明智使用Datadog监控

从宏观上看，Datadog 监控可分为以下类别：

为您要解决的问题选择合适的监控。

第7课 – Datadog 观察性治理评分卡

我们定义 Datadog 系统，利用 Datadog 服务目录，然后启用 Datadog 评分卡。这提供了一种自动化方式来衡量当前状态。内置功能已经很强大，您也可以通过提供的 API 进行自定义扩展。

评分卡关键维度：

• Observability Best Practices – 确保服务通过验证部署跟踪、日志摄取和日志‑追踪关联来发出正确的信号。
• Ownership & Documentation – 确认每个服务都有明确的所有者（团队、联系人、代码仓库、文档），以实现快速升级和有效的事件响应。
• Production Readiness – 通过检查最近的部署、活跃的监控、值班覆盖以及已定义的 SLO，验证服务是否具备运营准备。

Lesson 8 – Build Incident Management with Datadog On‑Call & Incident Management

Datadog On‑Call 是一个用于事件和升级管理的一站式平台。您可以定义团队、值班轮班和升级策略。它处理值班警报并提供有用的指标。最初您可能会看到大量噪音，但随着时间的推移，您可以将其削减到最低限度。如果您已经在使用 Datadog，则无需单独的值班管理解决方案。

(原文在此处被截断；核心信息保持完整。)

Datadog Observability Lessons for AWS

Lesson 9 – Datadog Synthetic Tests

• Purpose: 主动测试您的 AWS 基础设施。
• Why it matters: 只有在终端用户使用系统时才会产生遥测数据。合成测试模拟这些用户，即使流量低也能提供可见性。
• Key points:
  • 不仅是简单的 URL 检查——您可以自动化全栈冒烟测试。
  • Datadog 在全球提供众多测试地点，您可以从任何区域运行测试。

Lesson 10 – Datadog CI Visibility & Software Changes

• Purpose: 追踪开发人员的工作。
• How it works: 将 CI/CD 流水线集成，使 Datadog 能够感知团队何时将代码部署到生产环境。
• Benefits:
  • 在 Datadog APM 中实现部署‑版本跟踪。
  • 对比不同发布之间的响应时间。
  • 主动利用洞察采取行动。

Lesson 11 – Datadog Workflow Automations

• Purpose: 自动化补救方案。
• Features:
  • 构建可由监控触发的复杂补救工作流。
  • 向“自动化你的工作”迈出的第一步。
  • 与几乎所有 AWS 服务集成，帮助您自动化 AWS 基础设施及其他运营工作流。

Lesson 12 – Datadog Code Security

• Purpose: 保护基于 AWS 的系统。
• Capabilities:
  • SCA – 库（软件组成分析）
  • SAST – 静态代码分析
  • IAST – 运行时代码分析
  • Secret Scanning – 检测泄露的密钥
  • IaC Scanning – 基础设施即代码安全
• How to start: 将代码库与 Datadog Code Security 集成——这是利用其防护功能的第一步。

Lesson 13 – Datadog AI Observability

• Purpose: 衡量整个堆栈的 AI/LLM 性能。
• Why it matters: 现代系统日益嵌入大语言模型；您需要全栈 AI 可观测性来监控延迟、错误和资源使用情况。

Lesson 14 – Datadog Bits AI (SRE Agent)

• Purpose: 提供一个随叫随到的同事，加速根因分析。
• Highlights:
  • 将 RCA 时间缩短至几分钟。
  • 利用完整遥测、内部系统状态、终端用户活动和代码行为快速定位问题。
  • 在信号关联方面优于手动调查。

Lesson 15 – Datadog UI

• Purpose: 为每位利益相关者提供业务级可视性。
• Features:
  • 简洁直观的界面，抽象掉复杂性。
  • 为 SRE、开发者、高层管理者和 CTO 定制的角色视图。
  • 实现组织范围的透明度和数据驱动的决策制定。

结束语

以下是我在使用 Datadog 与 AWS 时学到的一些关键经验。虽然还有很多其他体会，但这份列表涵盖了最具影响力的功能：

• 可观测性合作伙伴： Datadog 为 AWS 提供深度、内置的集成。
• 免费试用： 可先开启 14 天的 Datadog 试用。
• 成本与价值： 虽然费用不低，但它带来的可靠性和运营杠杆往往值得每一分钱——尤其在需要大规模可视化和可靠性时。

尝试一下 Datadog，看看它如何改变你的 AWS 可观测性策略。