可观测性是新的Kubernetes

“现在，可观察性和Kubernetes一样受欢迎。”

这是主持人Raghavan“Rags”Srinivas在今年的北美KubeCon+CloudNativeCon大会上所说的。事实上，OpenTelemetry是继Kubernetes之后的第二或第三大CNCF项目。这是有道理的。Kubernetes使复杂系统更容易以更分布式的方式创建。这本身就需要更多的可观察性，以便理解系统的“未知”行为。

Kubernetes的广泛采用还带来了一个标准化水平，该标准化促进了围绕服务编排和标准化的公共语言和数据。服务网格允许测量服务之间的请求流。这些结合在一起，使可观察性的实践更容易被接受。现在的难题是如何处理所有的数据以及巨大成本——这些数据都是由这种日益昂贵的遥测技术带来的。

蜂巢公司的Liz Fong-Jones、红帽公司的Bartek Plotka、谷歌OpenTelemetry团队的Josh Suereth和极地信号公司的Frederic Branczyk参与了讨论。Fong-Jones也是OpenTelemetry治理委员会的成员，而Plotka和Branczyk是Prometheus的维护者。本文融合了小组讨论的要点，所有这些都是关于如何巧妙地实现可观察性以及还需要什么。

Srinivas提出了一个问题：“数据是否太多？可观察性可能会变得非常昂贵。多少算太多？当试图将信号与噪音分开时，如何确保不会丢弃隐藏的意义？我们在自动化方面取得了哪些进展？”

高质量、细粒度的可观察性与计算和存储相关的成本之间的紧张关系是真实存在的。而且，我们真的需要知道应用程序中发生的一切吗？

Fong-Jones认为，抽样是一种非常有效的方法，可以确保你保留每一个错误。她还指出了经常发生的重复数量：将数据发送到日志记录、跟踪和度量平台。“与其尝试获得所有信号中的一个，不如获得更少的高质量信号。”

她还建议使用跟踪或结构化日志，而不是非结构化日志，以将标记溢出限制在度量协议中，并且不集中索引日志——将它们保存在计算机上的本地，但使用采样的跟踪和度量作为中心索引类型。

Fong-Jones继续说，可观察性和特征标记的协同作用非常强大。这允许你将功能标记值附加到属性，还可以标记更多详细的跟踪事件。

Suereth说，“观察信号是有成本的，在某种程度上，这取决于你可以合理地进行多少压缩/采样。度量比采样跟踪便宜，更比日志便宜。你可以使用结构化日志并从中推断出所有其他可观察性信号，但可能需要支付较高的摄取/处理代码。”

Branchyk回应道：“我认为重要的是不要沉迷于一种类型的数据——或收集机制、协议甚至查询语言。关注提出的问题，然后选择正确的工具。事实上，每种类型的数据往往在某个方面都很好，所以请选择正确的工具。”

Plotka认为，开发人员甚至不应该做出决定，而应该与系统管理员和标准工具进行协商。“理想情况下，一切都是动态的。我喜欢将日志记录指标和跟踪信号引入其中的想法——减少重复，因此只需其中一项就可以了。使用、信号、网络组件——最终你可以依赖一致的统计数据，但这并不意味着你需要了解过去的每一项信号功能。”。

Fong Jones补充说，如果流量确实很大，可以在单独的线程或连续分析中使用度量和导出计数器。

Branchyck将连续评测定义为采样“代码正在执行的确切内容。幸运的是，像eBPF这样的插装技术使收集部分变得非常轻量级，因此需要解决的是存储问题。”

如何开始可观察性

更多的数据，更多的学习曲线。即使Prometheus和其他工具让你几乎可以开箱即用地开始观察，即使有工具让你打开和关闭东西，你也不一定有历史数据。而一般的新人也不会理解数据。

Srinivas要求KubeCon小组成员提供一些方法，让人们开始观察。这一切都从服务级别协议或SLO开始。Suereth说，设置日志和指标或者日志和跟踪，而不是全部三项，以监控SLO，开始了解事情进展缓慢的地方，然后深入探讨根本原因。

必须先爬才能跑。他将“爬”定义为基于行动的反思——当系统崩溃时能处理吗？可以评估某个功能是否改善了业务吗？

Fong-Johns认为，任何成功的可观察性都是在生产中完成的，所以第一步必须是缩短发布周期。后来，她建议开始覆盖微服务，从一两项服务开始——不需要完全覆盖。

“我们建议从尽可能靠近用户/入口的位置开始，并根据需要添加新的跟踪范围，以诊断堆栈中更深层次的问题。”

一位与会者问，是否有办法自动缩小数据范围，以自动检测问题，如机器学习。是的，这听起来很理想，但这将使大部分学习过程自动化。

Branczyk回答说“事实上，了解数据比任何类型的机器学习或诸如此类的方法都要有效得多。从简单开始，从负载均衡器上的错误和延迟SLO开始。对于许多组织来说，这足以提醒他们。从这个开始，然后将其从负载均衡器扩展到应用程序级别。”

左移：可观察性的下一步

那么，在未来的两到五年内，可观察性将走向何方？

Fong Jones说，下一步是支持开发人员在代码中添加工具，表示需要在简单和开箱即用以及每个用例的注释和定制之间取得平衡。

Suereth说，OpenTelemetry项目将在未来五年内对应用程序开发人员有用，因为在应用程序开发中，仪器可能特别昂贵。现在的可观察性更关注运维，而不是开发人员语言。“我认为我们将开始看到应用程序提供可观察性作为其自身配置文件的一部分。”

他继续说，OpenTelemetry开源项目的目标是通过一次拉取就拥有一个包含所有跟踪、日志和度量的API，但仍有待确定应该附加多少数据。

Fong-Jones指出，这是为了缩短反馈周期而向左移动的下一步。尽管她担心，与DevOps一样，可观察性的概念将被淡化。

Branchyk说，标准化协议对于边缘案例来说非常强大，下一步是开放标准，有线协议将标准化。对于旧的可观测性，虽然日志度量和跟踪是真正有用的信号，但仍然有更多的数据。“我们谈论的是集群，但有时它们太小，在全球物联网设备中运行。我们也需要用于这些情况的工具。”

可观察性的更多潜力还有待挖掘，但应该引起你足够的重视了。