在遗留监控领域中,您可能会关注资源消耗(如CPU、磁盘和内存),因为这些指标很容易获取,并且与可用性和性能有基本的关联。如果您像我一样从事持续改进实践,那么您很快就会收集到大量的细粒度资源指标,并需要维护一系列错综复杂的相关规则,以理解它们。

现在你在DevOps可观察性世界,你需要的不止这些。原因如下:

  • 某些类型的资源消耗不能(或不应该)在云环境中进行测量。
  • 工作负载可能变化很大,因此很难设置阈值。
  • 您需要在度量的内容和度量方式上有更多的灵活性。
  • 你需要快速而简洁地与各种各样的人交流你的地位。

最重要的是,IT环境正在扩展(此处考虑微服务),因此您需要简化收集的内容,同时使其更相关。如果你不这么做,你的参数存储将从巨大变成荒谬,这将增加你的行政工作,而不会增加价值。

采用不同的方法来衡量速度和质量

你的客户(包括内部和外部)都希望技术能够提供快速和高质量的响应;他们不关心细节。如果你想在他们的条件下达到他们的期望(你应该做到,因为他们是雇佣你的人),那么你应该专注于测量响应时间(速度)和错误(质量)。此外,您需要将其归结为一个单一的、易于理解的数字,以显示您的运维团队和工程团队应该将注意力集中在哪里,并使非技术涉众能够直观地理解当前的状态,以便他们能够做出关键的业务决策。

这一点很重要,因为业务并不关心某些进程比之前多消耗了2%的CPU——它关心的是客户的体验。这意味着你要衡量和沟通两个关键因素:速度和质量。

这就是服务水平指标(SLI)和服务水平目标(SLO)发挥作用的地方。您将通过识别技术和非技术涉众都可以理解的SLI度量来使用它们来满足业务的期望。然后你将以简单百分比的形式设定一个目标(SLO),显示你满足速度和质量要求的频率。

例如,以下数据来自我的一个客户的名为b2b网关的微服务。他们一直在收集错误量的数据,就像这样:

显示错误量的仪表盘

底部的绿线是客户的警报阈值。如您所见,不断地针对该服务断言警报。因此,他们的行动小组不再关注这个警报。这是一个很好的低质量警报噪音被忽略的例子。

您可以通过花大量时间尝试设置不同的阈值或查看与常规算法的奇异偏差来处理这个遗留问题,但这仍然没有衡量速度和质量这两个关键因素。幸运的是,从这里到那里只需要简单的两步。

第一步:确定一个SLI来测量质量——没有错误的事务占总事务的百分比。在New Relic仪表板中,你的查询应该是这样的:

SELECT count(*), WHERE error IS False FROM Transaction WHERE appName ='b2b-gateway' TIMESERIES MAX SINCE 1 day ago . * FROM Transaction SELECT count(*), WHERE error IS False

SLO成功率98%

这条线的向下下降显示了最重要的问题。紫色的水平线表示98%的成功率(你的SLO)。任何低于这个阈值的问题都需要警告。在这里有4种情况下,您的错误SLI低于98%的阈值(违反了您的SLO),因此您将在一天内收到4个警报(与之相反,24 * 7声明的一个警报,每个人都忽略它)。

您刚刚实现了一个巨大的目标:在一个简单的操作中,您创建了一个高度相关、易于理解的业务指标(“我们98%的事务都是无错误的”)。此外,您已经将妨害警报转化为具有实际业务影响的有价值警报。很明显,错误的增加会对用户体验产生直接影响。

通过更改SLI阈值,您可以很容易地使该度量具有或多或少的重要性。例如,如果它仍然太吵,你可以将其设置为97%,或者如果你需要改进,你可以将其设置为99%。

第二步:速度=响应时间,所以让我们把它添加到混合中。

继续这个示例,让我们假设b2b网关的响应时间阈值应该是100毫秒(0.1秒)。(请关注我们即将发布的关于如何设置SLO阈值的博客文章。)

要修改您的查询以包含响应时间,请将其更改为如下所示:

SELECT count(*) FROM Transaction, WHERE error IS False and duration < 0.1 WHERE appName ='b2b-gateway' TIMESERIES MAX SINCE 1 day ago . * FROM Transaction, WHERE error IS False and duration < 0.1

问题与阈值的截图

再一次,向下的下降显示了最重要的问题,紫色的线显示了98%的阈值。当考虑性能因素时,您可以看到该服务的表现并没有您想象的那么好。质量很好,但服务没有达到其速度要求。这不是通过查看一组资源消耗指标所能看到的。这对于消除IT(其资源消耗指标是“完全正常的”)和业务(他们听说了缓慢的服务)之间的根本脱节大有帮助——这是一个巨大的胜利。

最后,让我们回顾一下通过衡量速度和质量而不是资源消耗所获得的收获:

强大的业务定位:您有一个容易且直观地理解的指标,它真正地将业务需求与交付它们的技术连接起来。这样的度量标准使您更容易找到您的业务涉众并说:“嘿,平均而言,我们只在94%的时间内满足我们的性能义务,所以我们需要做出一些更改。”

故障指标明确:你的SLI将突出对业务有影响的问题。这意味着您将更快地吸引人们对实际问题的注意,这将使您在更快地修复它们并减少它们的范围和严重性方面领先一步。别忘了这也能减少警觉性疲劳。

简单性:您的sli和sls(响应时间和质量)很容易理解,并且可以根据需要轻松修改。

“这很好,”你可能会说,“但接下来我该做什么呢?”首先在您的环境中选择一些服务,实现基于SLI/ slo的可观察性,并将结果与现有的监视进行比较。几周后,您可能会看到SLO捕获的问题更少、更关键,甚至可能突出现有监视遗漏的问题。

了解更多关于为可衡量的成功建立你的团队.