有时最简单的问题会引发最热烈的讨论。比如:空载燕子的空速是多少?我们今晚吃什么?或者，正如我们在本期节目中所发现的Grafana大帐篷“即使是可观测性?
在“Grafana’s Big Tent”的这一集中，主持人Mat Ryer、Matt Toback和Tom Wilkie致力于讨论和辩论可观察性的概念，他们讨论了可观察性的传统和非传统定义，评估了可观察性的方法，并分享了监视和警报SLOs的最佳实践。
对了，他们还提供了一个关于母酱的快速烹饪课程。
注:为了篇幅和清晰度，本文已经过编辑。
可观测性是什么?
汤姆·威尔基:关于可观察性我们还能说些什么呢?我认为在现代可观察性市场中，许多人会谈论度量、日志和轨迹，但它绝对不是度量、日志和轨迹。我不认为可观察性是任何一种技术或工具。
马特·Toback:它和之前的版本有什么不同吗?可观察性作为一个新术语与监视不同吗?
汤姆:我想是的，因为监控几乎总是关于时间序列，关于指标，关于数字。可观察性并不一定是关于这个。我认为监控是其中的一部分。
垫黑麦:但你还是想知道你的系统发生了什么，对吧?当你有一个简单的程序时，这是很容易的，因为它没有做那么多，而且很明显可以看到发生了什么。但是随着系统变得越来越大，越来越多的人使用它们，它们变得越来越复杂，这就产生了一些新问题有时我们会突然被隐藏起来，不知道真正发生了什么。所以可观察性也必须是一种能让我们了解内部发生了什么的东西。
汤姆:可观察性有一个系统定义，我觉得这个定义没什么用。这是一种从外部输出推断系统内部状态的能力。我认为这可能是一个有用的定义，是什么使一个系统可观察，但不一定描述什么是可观察性本身。
马特:我想我也很纠结，你什么时候知道发生了什么?什么时候产生了可观察性?
汤姆:我用了3-4年的这个短语来描述我所做的工作——我认为我所做的一些工作就是可观察性——但它帮助人们理解他们的应用程序和基础设施的行为。所以我的应用程序会做一些事情，通常是我没有预料到的事情，我想了解这些事情是什么以及为什么会发生。我需要工具、技术、实践、团队和人来帮助我做到这一点。对我来说，这就是可观察性。
马特:对我来说，这是你在这些不同的事情之间轻松地跳跃。你说的是度量、日志和跟踪;我想我只是把它看作是不同粒度的数据，或者不同的数据以不同的方式呈现，它们是相互关联的。
汤姆:我想这是一个烹饪类比。也许度量、日志和跟踪是母酱。
垫:什么是母亲酱汁?
马特:有四种母酱，对吗?
汤姆:我以为有五个…
马特:有五个吗?
汤姆:快，谷歌“妈妈酱”!
[编者注:事实上，有五种母酱——béchamel, velouté， espagnole，荷兰酱和番茄酱。]
可观察性和使用vs.红色的四个黄金信号
汤姆:在谷歌，他们有一个叫做“四个黄金信号”的东西，就像每一个微服务你都应该监控四个东西。您应该监视请求率、错误率、延迟(处理请求所需时间的分布)和该服务的饱和度。
我在谷歌待了几年，这是他们教给你的东西之一。当我离开的时候，我忘记了饱和度。我只是忘记了。所以我们创造了这个短语作为一种文字游戏，与USE方法(利用率，饱和度，错误)相对抗，将其称为RED方法:速率，错误和持续时间。这是针对每个微服务的，请确保您导出了这三个指标。
有一种特殊风格的指示板，您可以在一个图上绘制请求率和错误率，在另一个图上绘制延迟，然后对微服务体系结构进行宽度优先遍历，以布局每一行。我喜欢的一件事是公司的所有服务，所有的仪表盘都是这样的。所以我可以深入研究任何服务，并开始了解它的架构以及哪里出现了错误，哪里出现了延迟。然后，当然，有人提醒我关于饱和度，我说，“它不符合这个模型。”
“我们仍在学习最好的方法是什么，以及如何最好地监控事情。当然，随着(这些系统)越来越成熟，这也会越来越自动化。”
——汤姆·威尔基
垫:嗯，这是一个有趣的观点。如果你有一个经常使用的通用方法，你就可以用通用的方式来表示数据，这显然是有好处的。但是系统本身可能是如此的不同;就像你说的，它并不总是合适的。视情况而定。
汤姆:我的意思是，一个很好的例子——RED方法对于企业消息总线风格的体系结构来说是绝对无用的。因为你衡量请求和错误的是什么?消息的持续时间是什么意思?我觉得不同的系统需要不同的理念。
垫:这是否意味着它是为每个项目定制的呢?
汤姆:我希望不是这样!否则，这将变得非常困难。我希望有一些通用的方法可以应用于多个系统，它们可能共享一个公共的体系结构。但是，我认为我们仍然在学习最好的方法是什么以及如何最好地监控事情。当然，随着它变得越来越成熟，它也变得越来越自动化。
对SLOs的监视和跟踪问题
汤姆:有一种观点认为，你唯一应该警惕的是你的sla或slo。因为SLA实际上是打击SLO的协议，如果不这样做会受到惩罚。作为工程师，我们真正关心的是什么是SLO;我们的目标是什么，我们要衡量什么，它对用户体验的影响是什么，我们如何执行它?有一个学派认为这应该是你监控的唯一内容。我的例子在这里是实用的，它和磁盘空间。您应该始终监视磁盘空间，因为它非常容易监视，而且将磁盘填满的后果非常糟糕，所以为什么不呢?
马特:我想谈谈痕迹，因为我觉得两年前你坐在斯德哥尔摩，你会说，“痕迹是这个，痕迹是那个，痕迹是惊人的。没有人使用它们。如果你不做完所有的事情，那就没什么用了。”所以再加上两年，我们有没有更好的地方，或者我们只是互相推推搡搡，说，“是啊，是啊，痕迹…”
汤姆:这是一个非常有趣的观点，马特，因为就像我之前说的，可观察性的好处是转换成本非常低，这意味着你可以创新负载。我认为，当你开始谈论追踪时，这个论点就站不住脚了，因为在我看来，采用追踪的成本仍然太高。
马特:做副驾驶员跟踪集成吗?
垫:我不这么认为，但你知道，我打赌如果你开始写东西-我打赌如果我开始把我的代码仪器化，副驾驶会帮我做。
汤姆:但在分布式跟踪的问题上，我觉得我们目前还没有达到可观察性的承诺。也就是说，追踪的价值仍然非常非常高。我们一直在努力提高系统的性能，人们对仪表板的加载速度和查询成功的速度有着很高的期望。如果没有分布式跟踪，我们不可能达到我们已经达到的延迟。因为这都是长尾效应。不幸的是，在我看来，要获得这些高质量的痕迹需要付出太多的努力。但当你这样做的时候，你就可以控制你的长尾巴。
一旦你有了高质量的跟踪，那么很多事情都成为可能。您可以开始做一些事情，比如检查您的SLOs是否很好地筑巢。如果您有具有不同SLO的相互依赖的系统，您知道它们之间的依赖关系，然后您可以检查您的SLO是否比您所依赖的某个系统更紧。你可以做所有这些伟大的事情，所以它是非常有价值的。但是收养它并不像我想的那么容易
提醒陷阱和最佳实践
垫:所以当你谈到这些数据时，Grafana洛基让所有这些数据都能负担得起，那么你就有了大量的数据。这是人工智能肯定也可以开始帮助我们的另一个领域——为我们查看数据，并试图给我们提供见解。我们还能做些什么呢?
“你应该时刻警惕症状，而不是原因。除了磁盘被填满。这是证明规则的例外。你应该时刻警惕这些症状，并尽可能让这些症状接近用户。”
汤姆·威尔基
汤姆:有争议的观点:你不应该盯着看仪表板在Grafana．你知道，你走进办公室，他们在墙上有大屏幕，通常情况下，上面是一个Grafana的实例。我是说，它很漂亮，看起来不错，但它会分散注意力。我不想付钱给工程师，我也不想把时间花在盯着仪表盘上，试图找出是否有什么东西坏了，而我本可以写一段代码来帮我解决这些问题。这段代码被称为警报。
我觉得你应该用91BOB体育 ．我认为这是一个大的、常见的错误，特别是像Grafana仪表盘这样的东西，它是如此漂亮，如此容易使用。建立这些伟大的东西是如此容易，你想要分享你所取得的成就，有时你可以在上面建立索引。
垫:你还能在警报上建立索引吗?你最后会不会有太多的提醒?
汤姆:所有的时间。我的许多同事和朋友都有传呼机过载的问题。他们做了正确的事，但他们对所有事情都设置了警报。
你应该总是注意症状，而不是原因。除了磁盘被填满。这是证明规则的例外。你应该时刻警惕症状。让这些症状尽可能接近用户。使用SLOs。然后你就进入了真正有趣的领域。使用错误的预算。因此，允许系统出现一定程度的故障。
我经常举一个例子来突出它。我们很早就与客户达成了SLO协议:99.9%的写操作应该在100毫秒内成功。系统一直都能命中，除了没有命中的时候。所以我们创建了一个警告，说“如果99.9%的写操作在100毫秒内没有成功，呼叫我。”我们只花了五分钟就收到了一大堆。很多次，大概一个月五六次吧。在月底，我运行一个月的查询，问在不到100毫秒的时间内有多少请求成功，结果总是八九。基本上，所有的请求都成功了。所以实际上，当我在我的SLO内时，我被传呼了。
来自Soundcloud、Prometheus和谷歌名气的Bjorn (Rabenstein)向我解释道，我们需要一个错误预算。不是在小窗口内有效地发出违反SLO的警报，而是使用某种倍数在越来越大的窗口中发出违反SLO的警报。实际上你要提醒的是你使用错误预算的速率。当他解释这个时，我惊呆了。我们在我们的服务中实现了这一点，我们的寻呼机负载和随之而来的寻呼机疲劳就消失了。
