可观测白皮书 part2/2

此文为可观测白皮书翻译的第二篇， 第一篇点此链接 原文链接请点此处

关联可观察性信号

毫无疑问，可观察性体系是复杂的。 正如您从前面的部分中了解到的，为了更多地了解我们运行的软件的状态和行为，我们从不同的角度、不同的时间间隔和管道收集不同的数据类型：

• Metrics：一段时间内状态的可聚合数字表示。
• Logs：结构化 或者 可读的 离散化事件的详细信息
• Traces: 可以绑定到系统中单个实体的生命周期的元数据位（例如请求或事务）。

我们还讨论了不属于上述类别，称之为信号的数据，例如：
可持续Profiling：随着时间的推移，跨不同程序函数的各种资源的代码级消耗数（例如，MEM、CPU）。
我们首先想到的疑问是，为什么要创建这么多的种类？难道我们不能只有一个“包罗万象”的东西吗？答案是不能，类似的，我们不能拥有一辆在柏油路和越野路都有效工作的自行车。 每种类型的信号都针对其用途高度专业化。 Metrics以实时、可靠和廉价的监控为中心，支持响应告警 - 可靠系统的基础。 我们收集log lines，让我们更深入地了解有关正在运行的系统的较小细节，以获得更多上下文。 在某些时候，详细信息会形成一个请求树，因此distributed tracing通过其spans和跨进程上下文传播发挥作用。 有时我们需要更深入地研究，我们会转向performance application profiles以检查哪些代码效率低下并使用了意外数量的资源。
正如您可能已经注意到的那样，对于一个完整、方便的可观察性系统来说，只有一个信号是不够的。 例如，将太多细节放入metrics（基数）中的成本太高，而以警报所需的近实时延迟可靠地trace每个可能的操作也太昂贵。 这就是为什么我们看到许多组织旨在为他们的可观察性系统安装和利用多个信号。

实现多信号可观测性

多信号可观测性是可行的，而且许多人已经做到了。 但是当您退后一步，看看为实现这一目标必须构建什么时，您会发现一些主要挑战、错失的机会或效率低下：

1. 不同操作的努力
   除非您愿意花钱购买 SaaS 解决方案，它会为您完成一些工作，否则现在很难让一个团队管理所有可观察性系统。拥有一个单独的专门团队来安装、管理和维护每个可观察性信号的情况并不少见，例如一个用于metrics系统，一个用于logs记录技术栈，一个用于trace。这是由于每个系统需要不同的设计模式、技术、存储系统和安装方法。这里边的细枝末节的工作是巨大的。这就是我们的目标是通过开源计划来改进，例如用于检测和转发部件的 OpenTelemetry以及用于可扩展多信号后端的 Obsevatorium。
2. 重复劳动
   当我们查看上述可观察性信号时，发现信号之间都会有明显的重叠。 例如，让我们看一下上图。 我们看到关于“数据在哪里”（通常称为“目标元数据”）的上下文对于每个信号都是相同的。 然而，因为对于每种信号，都有一个独立的系统，我们会经常发现这些信息，通常是不一致的，保存在多个地方，并且（更糟！）多次索引和查询它。它不仅适用于目标元数据。 许多事件会产生多个信号：增加指标、触发日志线和开始跟踪跨度。 这意味着与此特定事件相关的元数据和上下文在整个系统中重复。 在开源中，有一些尝试来减轻这种影响，但是进度缓慢，例如 Tempo。
3. 采集时集成多种信号。
   鉴于多信号管道，通常需要用另一个信号的附加数据来补充每个系统。比如用metrics协议（例如 OpenMetrics/Prometheus）兼容特定traces和logs 集合创建metrics或类似地将logs组合到traces等功能。 诸如 OpenTelemetry 收集器的处理器（从trace spans生成 RED metrics）和 Loki 将logs转换为metrics的功能等举措是该领域的一些现有尝试。
4. 使用时集成多种信号
   类似地，在“阅读”级别，快速导航到表示相同或相关事件的另一个可观察性信号将非常有用。 这就是我们所说的信号相关性。 让我们详细关注这个机会。 现在有什么可以实现的？

信号相关性

为了将可观察性数据链接在一起，让我们看一下附加到所有信号的常见数据（如前所述，有时是重复的）。