Datadog 监控最佳实践 - 如何排查性能问题
本文是Datadog“高效监控”系列的第3篇，前面两篇请参考：
监控系统的职责并不仅限于故障症状检测。一旦您的监控系统告警了，那下一个工作就是通过查看各类监控数据，诊断问题原因。通常，这是监控中最不结构化（无法有章可循）的方面，主要由直觉驱动、由“猜测-检查”驱动。这篇文章描述了一种更直接的方法，可以帮助您更有效地找到并纠正根本原因。
本系列文章源自我们为客户监控大型基础设施的经验。它还借鉴了Brendan Gregg、Rob Ewaschuk 和 Baron Schwartz 的工作。
数据概述
主要有三类监控数据可以帮助您排查根因。数据类型以及收集的最佳实践在本系列的第一篇文中有详细介绍，简而言之：
- 工作指标 通过测量系统的有用输出来表明系统的高层视角的健康状况
- 资源指标 量化系统所依赖的资源的利用率、饱和度、错误或可用性
- 事件 描述系统中离散的、不频繁发生的事件，例如代码更改、内部警报和扩缩容事件
总的来说，工作指标将显示最严重的症状，因此应该生成最严重的警报。但其他指标类型对于调查这些症状的原因非常有价值。为了使您的系统可观察，您需要足够全面的度量手段来全面了解每个系统的健康状况和功能。
逐层往下看，都可以看做是资源
基础设施的大多数组件都可以被视为资源。从顶层视角来看，每个产生有用工作的系统都可能依赖于其他系统。例如，LAMP 堆栈中的 Apache 服务器依赖 MySQL 数据库作为支持其工作的资源。再往下一层，是 MySQL 内部的那些 DB 独属的资源，比如有限的客户端连接池。较低层仍然是运行MySQL的服务器的物理资源，例如CPU、内存和磁盘。
思考哪些系统输出有用的工作，以及哪些资源支持该工作，可以帮助您快速找到任何问题的根源。了解这些层次结构有助于您构建系统如何交互的心理模型，这样在问题发生时，您可以快速专注于那些关键诊断指标。当警报通知您可能存在问题时，以下过程将帮助您系统地进行调查。
1. 从工作指标开始排查
首先问问自己：“有问题吗？我该如何描述它呢？”如果您一开始没有清楚地描述问题，那么当您深入系统以诊断问题时很容易迷失方向。
接下来检查出现问题的最高级别系统的工作指标（work metrics）。这些指标通常会指出问题的根源，或者至少为您的调查确定方向。例如，如果成功率低于设定的阈值，则深入研究错误指标，尤其是返回的错误类型，通常有助于缩小调查的重点。或者，如果延迟很高，并且外部系统的请求量也很高，则可能系统负担过重。
2. 检查资源指标
如果您通过检查顶级工作指标尚未找到问题的原因，那么接下来检查系统使用的资源 - 物理资源以及充当系统资源的软件或外部服务。如果您已经为每个系统设置了仪表板（如下所述），那么您应该能够快速查找并仔细研究相关资源的指标。这些资源不可用吗？它们的利用率高还是饱和？如果是这样，请递归到这些资源并开始在步骤 1 中调查每个资源。
3. 是否有变更？
接下来考虑可能与您的指标相关的警报和其他事件。如果在问题开始发生之前不久就注册了代码发布、内部警报或其他事件，请调查它们是否可能与问题有关。
4. 修复它（且不要忘记它）
一旦确定了导致问题的原因，请予以纠正。当症状消失时，您的调查就完成了 - 您现在可以考虑如何更改系统以避免将来出现类似问题。如果您没有快速诊断问题所需的数据，请向系统添加更多工具，以确保这些指标和事件可供未来的响应人员使用。
提前构建仪表盘
在故障期间，每一分钟都至关重要。为了加快调查速度并让您专注于手头的任务，请提前设置仪表板以帮助您观察每个系统的当前和最近状态。您可能希望为高级应用程序指标设置一个仪表板，并为每个子系统设置一个仪表板。每个系统的仪表板应该呈现该系统的工作指标，以及系统本身的资源指标和它所依赖的子系统的关键指标。如果事件数据可用，则将相关事件叠加在图表上以进行相关性分析。
结论：遵循指标监控框架
遵守标准化的监控框架可以让您更系统地调查问题：
- 对于基础设施中的每个系统，提前设置一个仪表板，显示其所有关键指标，并覆盖相关事件。
- 通过从出现症状的最高级别系统开始，检查其工作和资源指标以及任何相关事件来调查问题的原因。
- 如果检测到有问题的资源，请对资源（及其组成资源）应用相同的调查模式，直到发现并纠正根本问题。
我们希望了解您将此框架应用于自己的监控实践时的经验。
原文：https://www.datadoghq.com/blog/monitoring-101-investigation/
