了解监控应用程序的SLO
确定对你的应用程序真正重要的性能指标，可以使你的团队生活得更轻松，并在整个企业中明确表达你的标准。
为了正确地管理和监控一个应用程序，你需要一个目标来定义你的位置和你的表现，以便你可以随着时间的推移进行调整和改进。这个参考点被称为服务水平目标（SLO）。花点时间来定义清晰的SLO将使服务所有者以及依赖你的服务的内部或外部用户的生活更轻松。
然而，在你定义SLO之前，你需要一个客观的、量化的指标，你可以看一下，以确定你的应用程序的性能或可靠性。这些指标被称为服务水平指标（SLI）。
[也在InfoWorld上：为什么你应该使用微服务架构]
服务水平指标-SLI
确定你应该为你的SLI使用什么指标的一个好方法是思考在你的应用程序的性能方面，什么直接影响你的用户的幸福。这可能包括诸如延迟、可用性和应用程序的准确性等内容。另一方面，CPU利用率将是一个糟糕的SLI，因为你的用户并不真正关心你的服务器的CPU是如何工作的，只要它不影响他们对你的应用程序的体验。
此外，你选择的SLI将取决于你所运行的应用程序的类型。对于一个典型的请求/响应型应用，你可能会关注可用性、请求延迟和每秒成功请求的能力。你可能会关注可用性和数据存储所提供的数据的一致性。对于一个数据管道，你的SLI可能是预期的数据是否被返回，以及数据被处理的时间，特别是在最终的一致性模型中。
服务水平目标-SLO
SLO是在一段时期内为SLI测量的性能阈值。这是衡量SLI的标准，以确定性能是否达到预期。一个好的SLO将定义你的应用程序所需要的性能水平，但不能高于必要的水平。这是一个关键点，需要随着时间的推移进行一些测试。如果你的用户对99%的可用性感到满意，那么就没有理由进行大规模的投资，以达到99.999%的可用性。
一些关于延迟的SLO的例子可以是第95百分位数的延迟，这将告诉你用户发出的最慢的5%的请求的延迟。这比简单的延迟平均数要好得多，因为后者很容易被异常值歪曲。
另一个提供更细化的选择是测量请求的总数和超过合理阈值（如一秒钟）的请求数。超过基线的请求的百分比将有助于确定你的用户不耐烦地等待数据返回、等待页面渲染或等待一个动作完成的频率。
一旦你确定了你现实的性能目标，你就需要弄清楚你将用于测量的时间段。SLO的两个常见的时间段是基于日历的测量，从一个设定的日期到另一个日期，如一个月的开始和结束。另一种风格是滚动窗口，从当前日期开始，按设定的天数回看。
服务水平协议--SLA
服务水平协议（SLA）是简单的SLO，在服务提供商和客户之间有一个附加的协议，规定了如果没有达到SLO的某种形式的后果。这通常是在两个不同的企业之间看到的，作为供应商和客户，违反SLA的财务后果。SLA也可以在公司内部使用，其中某些服务可能依赖于由不同团队控制的其他服务来实现产品的功能。
为什么使用SLO？
所以，现在你已经对什么是服务水平目标有了一定的了解，你可能想知道为什么你应该花时间来创建它们并使用它们。最明显的原因是，花时间弄清楚什么是真正重要的绩效，可以使你的团队生活得更轻松，并在整个企业中明确表达你的标准。有成千上万种不同的方法可以跟踪你的应用程序所产生的指标，但如果你把它分解成对用户有明显影响的东西，你就可以清除很多干扰和噪音。
在InfluxData，我们关注的是时间序列数据。因此，我们有大量的数据，涵盖了我们系统的许多方面。虽然高度细化的指标有其操作价值，但这些指标并不能很好地反映客户体验，而且肯定会让服务所有者想得到更多。因此，我们采取的方法是检查每个微服务及其消费者，建立合理的成功标准和可实现的目标。
由此产生的结果是一致的测量，我们可以应用于整个车队，提供对可用性和错误率的洞察力，作为客户体验的代理。这不仅有利于服务所有者作为实现卓越运营和告知错误预算的手段，而且可以让企业的各个层面深入了解我们的工程组织。
这些是我们运营的一项服务的下面的仪表板背后的目标。你会看到，它很容易理解，一目了然，提供有价值的指标，可用于警报和错误预算，并说明这项服务的目标是99.9%的可用性。通过在整个公司提供这些数据，我们可以加速服务的交付。反过来，这导致客户在我们的平台上开发他们的应用程序时，可以高速地 "达到令人敬畏的程度"。
需要注意的一件事是，SLO不一定要在第一次实施时就做到完美。SLO始终是一项正在进行中的工作，可以随着你获得更多的数据和了解更多的用户需求和期望而进行迭代。记住，实施SLO的最有价值的事情是在监控你的应用程序方面的总体思维方式的转变。 相关的：
