你建立一个伟大的产品。你把它作为一种服务来提供。你为你的客户定义质量和性能的服务水平协议（SLA）。
现在到了确定你的监控策略的时刻了。你应该从你的系统中收集哪些指标？从哪里收集？以什么样的节奏进行？
策略1：是的，监控，我不知道 知道
- 使用基于客户的监控。没有真正的必要去监测什么。如果有什么功能不正常，你的客户肯定会让你知道。减少开发成本。偶尔会增加客户的心率。
- 只监控系统级指标。这 一切都归结为资源拥挤，不需要监控其他东西。如果你的系统很慢，检查CPU或DISK是否拥挤。如果你的系统返回很多错误，检查CPU或DISK是否拥堵。想知道为什么你的客户比你的监测发现的问题更多。
- 只监控应用层面的指标。跟踪应用程序的响应时间和错误率。不需要监控基础设施或外部服务。如果你的系统返回很多错误或开始变慢，开始挖掘错误日志，或检查个别基础设施组件的本地指标。想知道为什么你的恢复时间很高。
- 监控所有的东西。 收集所有你能掌握的指标，从任何系统层面，以任何粒度。首先专注于收集一切。以后再确定指标的相关性。产生一个指标洪水。想知道为什么你的监控系统很慢或维护费用很高。
- 不要汇总指标。每 个指标都是独立的。CPU指标只标有基础设施信息。响应时间是用API端点标记的。让人类来拼凑某个特定端点的CPU和响应时间之间的联系。想知道为什么你不能提高系统的自动化程度或实施自动修复。
策略2：监控可观察性
- SLA, SLO, SLI: 定义履行你的SLA所需的服务水平目标（SLO）。从SLO中，提取你所需要的服务水平指标（SLI）。围绕这些服务水平指标进行监测。你的SLA是否要求99.99的正常运行时间？那么99.99的正常运行时间就是你的SLO。而SLI是你跟踪正常运行时间的指标。不是所有的指标都应该是SLI。确定哪些指标真正重要，并专注于有效地收集这些指标。
- 收集业务水平指标。收 集诸如交易、采购、端到端业务流等指标。它们提供了对系统行为的整体看法，并帮助评估业务影响，如果有什么问题。
- 收集端到端测试的结果。实 施 端到端测试，尽可能多地捕捉业务流。连续或尽可能频繁地运行它们。监测其结果。把它们作为你系统中任何问题的早期指标。
- 收集应用层面的性能和质量指标。收 集指标，如响应时间、延迟、错误率。在服务实例中进行汇总。从指标中提取百分位数，如第95百分位数。依靠它们来了解你的性能和质量在请求中的分布。
- 收集关于与外部服务交互的指标。外 部可以是另一个系统组件，或由第三方实体提供的服务。收集诸如与外部服务通信的响应时间和错误率等指标。它们对于检测外部服务所提供的性能和质量的下降非常重要。
- 收集基础设施的利用率和性能指标。收 集指标以帮助你快速识别基础设施的拥堵。如CPU的使用，DISK的使用和延迟，内存的使用，NETWORK的使用和丢包。
- 跨监测层汇总指标。将 应用层面与业务层面和基础设施层面的指标联系起来。用源组件和层来标记指标，以实现指标的聚合。跨层汇总指标可以帮助你更快地了解问题，并对更复杂的事件发出警报。通常，对 "服务X的响应时间很高，cpu使用率很高 "发出警报更有用，而不是简单的 "服务X的响应时间很高"，或更嘈杂的、通常不太有用的 "CPU使用率很高"。
[监测]监测什么？在哪里？原文发表于Nerd For Techon Medium，在那里人们通过强调和回应这个故事来继续对话。
