此文为中文翻译，原文地址https://github.com/cncf/tag-observability/blob/main/whitepaper.md#executive-summary

摘要

随着软件的复杂性及所处理的数据量的持续增长，我们需要可观测性技术来了解工作负载的状况。软件工程师除了要了解可观测性工具外，还需要了解如何监控和观测程序成为了共识。随着对服务等级目标的更高要求，这就需要软件工程师能够更快的找到造成服务异常的原因。
本文旨在带你了解云原生的各种可观测性技术。

简介

随着云计算、微服务、分布式系统的盛行，上云成为了越来的越多的程序的选择。尽管这一变化使得系统更方便扩展，拥有更好的性能也更加安全，但同时也更难控制基础设施。系统负责人、开发人员和运维必须了解线上程序以及底层基础设施状况，这就要求程序能够不借助其他手段能够被观测到运行状态，例如在源代码中添加新的检测或设置断点。
为了能够让不同权限的人员能够观测到程序的状态，程序就需要设计之初考虑引入哪种观测工具，然而从市面上选择各种各样观测标准的工具本身就是一件很困难的事情
根据ClearPath Strategies和Honeycomb.io对于的社区的研究表明，“四分之三的团队还没有完成或者尚处于可观测性的初级阶段”，并且“朝着实现更多可观察系统的转变动力很足”。虽然刚开始时是困难的，但是一旦达到某种令人满意的可观测水品有很多的好处。文化的改变，不同的工具，不同的目标，不同的方法。 如此多的细节需要考虑，这会让这段旅程变得相当混乱和痛苦。 本文的目的让更多的软件和运营团队能够了解可观测，运用它并获得利益。

目标听众

本文的目标读者是：

• SRE
• DevOps 工程师
• 系统负责人
• 软件工程师
• 基础设施工程师
• 软件开发人员

本文对那些希望交付在可靠性、安全性和透明度能够达明显的等级，能够集成客户现有的观测系统的可观测性软件的人员有所帮助。可观察性是一个多学科主题，因此组织内其他人员，例如负责设计和实施此类软件的项目、产品、项目经理和架构师，也可能对本文感兴趣。计算机科学、信息系统、工程（或相关）学生和对可观察性领域感兴趣的人也可以在本文中找到有用的信息。

目标

云计算能够帮助科技公司优化成本、规模和设计更高效的产品，同时也引入了（结构的）复杂性。由于基础设施现远程、短暂和全球分布的特性，使得系统管理员曾经对数据中心拥有的控制权丢失了。曾经那些管理人员和开发人员拥有不同kpi的公司也必须转变为构建可靠软件而共同奋斗的文化。目前已经有一些工具能够通过观测云原生系统的状态提升系统的可靠性。
在可观察系统的设计和开发过程中，必须对其进行检测以向第三方发送或公开遥测数据，通常是一组工具，负责从公开的数据中提供有意义的信息。遥测数据经常以metrics、logs、traces、structured events、profiles和dumps的形式呈现。每种信号都有其目的和最佳实践，它们的滥用可能会在大规模运行软件时导致新的问题，例如“告警疲劳”和“过高的成本”。尽管存在一些新的挑战，例如文化变革、产能规划、法律问题等，但其中很多已经被早期入局的公司所解决。初学者可以从他们的总结和错误中学习，并遵循最佳实践来解决同样的问题。本文包括可观察性信号之间的区别以及应如何处理它们，列出解决常见问题时使用的几种不同方法的成功案例，并介绍了几种可观察性的工具以及如何实现自己的技术栈 ，最后介绍仍未解决的问题或者还未标准化的方法。

什么是可观测性

毫无疑问，可观察性是当今系统的理想属性。 每个人都这么认为，对吧？ 你们中的一些人可能已经开始了可观察性之旅，而其他人现在正在阅读本白皮书，只是因为每个人都在说你应该让你的系统可观察。事实上，“可观察性”已经成为一个流行词，和其他流行词一样，每个人都想在倡导的同时留下自己的印记，但是这个词的起源和你所理解的可能有些不同。如果您要在可观察性方面升级您的程序，首先要明确其最初的目的。
“在控制理论中，可观察性是衡量一个系统的内部状态可以从其外部输出的知识中推断出来的程度”[9]。 理论上，它是一个系统的功能；人类和机器可以通过它观察、理解和控制系统的状态。根据定义，可观察性看起来很简单，但是在没有考虑目标的情况下决定系统应该具有哪些输出是很复杂的，这种情况下往往会出岔子
刚开始时，很容易复制别人的工作。这是使用开源的优势，同时也是开源的一种劣势。网上有很多例子，helm、ansible、trrafoem，只需运行其中一个脚本，您就可以在几分钟内建立并运行可观察性技术栈。这很容易，并且适用于其他人。因此它应该对我也有用，对吧？但是，我们并不是要鼓励您不要使用这些类型的脚本，可观察性不仅仅是使用所有漂亮而闪亮的工具。您必须意识到系统的输出是什么，比一切都更重要的是，您需要有一个目标！你可能会想：“哦，我想收集那些未来可能会用的到的数据。” 然后对每种数据都存在这个想法，最后你会发现你可能正在构建一个数据湖。
可观察性可用于系统开发生命周期的所有阶段。 您可以在测试新功能、监控产品新能、了解客户如何使用您的产品或制定数据驱动的决策时使用它。 一旦你有了自己的目标，你就会开始考虑输出，或者我们喜欢称之为信号的东西。

可观测性信号

如前所述，信号是系统产生的输出，人类或机器可以从中推断出知识。 这些信号会因系统而异，并取决于您要实现的目标。 它可以是您想要在某个时间点测量的东西，例如温度或 RAM 使用情况，也可以是您想要追踪的通过分布式系统的许多组件的事件。 您可能想知道系统的哪个功能在随机时间点对 CPU、内存或磁盘等资源的占用最大，或者您的系统在确切时间如何发生故障的。 虽然一些信号可能重叠以推断知识，但其他信号在系统的某些方面非常专业。它们都可以一起使用，以提供不同的方式来观察同一事物，或者，正如我们为初学者推荐的那样，您可以从一种或几种开始，然后逐步成熟到其他方式。
您很有可能听说过“三个可观察性支柱”，即metrics、logs和traces。 它们是行业标准，也可能是您要开始使用的标准。 我们喜欢将它们视为“主要信号”而不是“三根柱子”，原因有两个：（1）柱子带有隐含的含义，即如果缺少一根柱子，整个结构就会崩溃。但事实上并非如此， 我们可以只使用两个甚至一个信号，并且仍然可以实现其可观察性目标； (2) 去年，越来越多的信号在开源社区变得流行，例如profiles和crash dumps，而今天的工具和方法仍然不能满足科技行业的所有需求。 在不久的将来可能会出现新的信号，对这个话题感兴趣的人应该留意它们。

所有信号都有不同的收集或检测方式。 它们具有不同的资源成本来获取、存储和分析，同时提供不同的方法来观察同一系统。 与工程中的所有其他任务一样，在它们之间进行选择或全部进行选择是一种权衡游戏。 在接下来的部分中，我们将通过深入挖掘每个信号来帮助您做出决定，首先是人们最喜欢的：metrics、logs和traces，然后是两个新的可能信号：profiles和dumps。

Metrics

metrics是数据的数字表示。 它们分为两大类：已经是数字的数据和提炼成数字的数据。 前者的典型示例如温度而后者的典型示例如进程计数器。 这与logs或traces不同，logs或traces侧重于有关单个事件的信息。
提取数据会导致细节丢失，比如进程计数器无法获取何时发生特定增量的信息。这种权衡使metrics成为最有效的信号之一：主题专家选择了提取什么以及如何提取。这减少了保留、发送、传输、存储和处理的负载。它还可以减少运维人员的心理负担，因为他们可以快速了解情况。
metrics也代表系统状态在一个时间点的状态。 这与logs或traces不同，logs或traces侧重于有关单个事件的信息。
metrics一般是结构化或半结构化的，通常有两种用途：

• 实时监控和警报——metrics最常见的用途是看板，并在系统在超过阈值或行为异常时自动化触发报警。
• 趋势分析——metrics还用在趋势分析，同时还可以在事件发生后提供历史数据分析，修复或监控以防止潜在问题再次发生。

metrics提供的信息可用于系统整体行为和健康状况的分析。 metrics通常在“发生什么”，有时是“为什么”中发挥重要作用。 例如，一个metric可以告诉您每秒 HTTP 请求的数量，但并不总是可以告诉您请求高峰或下降的原因。 不过，它可以告诉您负载均衡器过载的原因。 换句话说，metric并不总是揭示根本原因，通常作为发现问题的起点。

Logs

Logs是描述操作系统、应用程序、服务器或其他设备中活动和操作的文本流。
日志可以分为不同的类别，例如：

• 应用程序日志 - 当应用程序内部发生事件时创建应用程序日志。 这些日志可帮助开发人员了解和衡量应用程序在开发期间和发布后的行为方式。
• 安全日志 - 创建安全日志以响应系统上发生的安全事件。 这些可能包括各种事件，例如登录失败、密码更改、身份验证请求失败、资源访问、资源更改（包括文件、设备、用户）或其他管理更改。 系统管理员通常可以配置安全日志中包含哪些类型的事件。
• 系统日志 - 系统日志记录操作系统本身发生的事件，例如处理物理和逻辑设备的内核级消息、引导顺序、用户或应用程序身份验证以及其他活动，包括故障和状态消息。
• 审计日志 - 也称为审计跟踪，本质上是事件和更改的记录。 通常，它们通过记录执行活动的人员、执行的活动以及系统如何响应来捕获事件。 通常，系统管理员会根据业务需求确定为审计日志收集的内容。
• 基础设施日志 - 是基础设施管理的重要组成部分，涉及管理影响组织 IT 基础的物理和逻辑设备。 这可以在本地或云端，通过 API、Syslog 或使用基于主机的代理收集的方式获得。

日志在许多场景中都很有用——metrics、traces、security、debugging。 保留所有应用程序和系统相关事件的记录可以了解甚至重现导致特定情况的逐步操作。 这些记录在执行根本原因分析时非常有价值，可提供信息以了解故障时应用程序或系统的状态。
存储在日志中的信息很随意，因此很难从中获得信息。 在过去的 30 年中，有很多尝试将schema应用于日志，但没有一个特别成功。 引入schema可以使得提取相关信息更加容易，通常这是通过解析、分段和分析日志文件中的文本来完成的。 日志中的数据也可以转换为其他可观察性信号，包括metrics和traces。 一旦数据成为一个metric，它就可以用来分析随时间的变化。 日志数据也可以通过日志分析技术进行可视化和分析。
日志级别允许表达每个日志语句的重要性。 日志级别包括 ERROR、WARNING、INFO 和 DEBUG。 其中，ERROR 是最不详细的级别，而 DEBUG 是最详细的级别。

1. ERROR 传达发生故障的原因和详细信息。
2. WARNING 是需要重点关注的告警消息。
3. INFO 消息帮助我们了解系统是如何工作的。
4. DEBUG 是存储每个操作的非常详细信息的级别。 通常，仅在故障排除期间或由于存储或性能影响而短期使用。

可以通过多种方式转发日志。 第一个建议是配置标准流以将日志直接发送到存储中心。 其次，将日志写入消息队列以进行过滤或添加一些信息，然后发送至存储中心。 最后一种方法是使用开源数据收集器应用程序将日志发送到存储中心。 将日志与其他可观察性信号结合起来，可以全面了解您的系统。
在规划日志记录解决方案时，我们必须关注安全性。 在将与日志相关的文件或信息发送到存储中心时，对这些文件或信息进行加密。 不要在日志中存储任何个人身份信息 (PII)。 最后，真正重要的数据不应仅保存在日志中。 尽管日志语句很有用，但不能保证它们会被传递。

Traces

traces是一种了解分布式事务期间发生的事情的技术，例如最终用户发起的请求及其对所有下游微服务的影响
traces通常是“跟踪数据点”的集合，或称为spans，并且可能会显示为甘特图，如下例所示：

traces通常是数据流转的一个具体实例，是可观察性的高分辨率信号。span是高度上下文化的，包含有关启动span的信息。这使得在分布式系统的不同参与者（例如服务、队列、数据库等）之间建立因果关系成为可能。
虽然许多监控系统实现了自己专有的trace上下文传播方式，但业界达成了广泛的共识，即traces上下文传播应该以标准化的方式进行。这导致了 W3C 分布式traces工作组的创建以及随后发布的 W3C traces上下文规范。受 OpenZipkin 项目事实上的标准 B3 的启发，W3C Trace Context 定义了标准 HTTP header 格式来传播trace。该规范标准化了上下文信息在服务之间的发送和修改的方式。上下文信息唯一地标识分布式系统中的各个请求，还定义了一种添加和传播特定于提供者的上下文信息的方法。
现在 OpenTelemetry 和 .NET 正在使用 W3C Trace Context 作为他们的标准传播格式，并且可以预期云基础设施提供商也将开始支持 W3C Trace Context，这样上下文在通过托管服务时不会中断，例如服务网关。
Instrumentation 在分布式跟踪中起着至关重要的作用，负责创建数据点本身并将上下文从服务传播到服务。如果没有上下文传播，我们无法将传入的 HTTP 请求与其下游 HTTP 请求或消息的生产者及其消费者联系起来。
Instrumentation对于分布式跟踪有两个主要目的：上下文传播和span映射。在大多数情况下，上下文传播是通过使用可以与 HTTP 客户端和服务器集成的库透明地完成的。在这一部分中，可以使用 OpenTelemetry API/SDK、OpenTracing 和 OpenCensus 等项目、工具和技术。

Profiles

随着公司不断优化云原生应用程序，了解尽可能细粒度的性能指标变得越来越重要。其他工具通常会显示存在性能问题（即延迟、内存泄漏等）。持续收集profiles使我们能够深入了解特定系统为何会遇到此类问题。
有以下几种分析器：

• CPU 分析器
• 堆分析器
• GPU 分析器
• 互斥锁分析器
• IO 分析器
• 特定于语言的分析器（例如 JVM Profiler）

每一种分析器中都有许多子类型的分析，它们都具有相同的目标，即展示资源在系统之间的分配方式。
传统上，分析器不适合在生产中运行，因为相关开销很大。然而，由于采样分析器越来越受欢迎，它们在云环境中变得越来越流行；它们只增加了百分之几的开销，使生产中的添加分析器成为一个可行的选择。
为分析器数据添加“时间”轴使用户可以全局查看他们的数据，也能细粒度的观测数据。 在优化或调试云原生应用程序或者规划如何分配资源时全面了解资源变得越来越重要。
trace可以帮助你了解应用程序的哪个部分导致延迟问题，profilling则可以使您可以更深入地了解为什么存在这些延迟问题。 此外，它还可以帮助您了解哪些代码占用了过多的资源。
运行时生成的Profiling数据通常包含源代码行号的统计信息，因此它是分析“为什么”的重要数据。

Dumps

在软件开发中，core dump文件可用于对崩溃程序进行故障定位。操作系统在诸如位置、名称约定或文件大小等配置的帮助下，会在崩溃时把进程内存写入一个镜像中以供分析。然而，在云原生中，大型集群的核心转储文件集合很容易在存储甚至网络方面造成瓶颈，处理密集型应用程序最终可能会生几十G的核心转储文件。
从内核 2.6+ 的Linux 的系统开始，有一种新的处理核心转储方法，即所谓的核心转储处理程序，可以通过全局设置 (/proc/sys/kernel/core_pattern) 将核心转储文件设置为写入系统中的任何位置。 这意味着不是将文件的收集委托给操作系统，而是推送给应用程序。 例如，在基于 Ubuntu 的发行版中，这可以在 systemd 或 abort 的支持下完成。 基于 RedHat 的发行版可以使用 ABRT。
在云原生环境中收集core dumps文件有两个难点：在云原生中，拥有应用程序和基础架构权限的人较少，因此对全局系统设置的清晰访问权限不太容易。 另一个就是，云原生环境的数据持久性：应用程序（例如 pod）需要在崩溃重新启动之前收集其核心转储文件写入持久性卷，需要一些的技术来支持实现这一点。
一个大约 5 年前的 RFC (https://lore.kernel.org/patchwork/patch/643798/) 要求 Linux 内核社区支持core_pattern命名空间 ，而不作为全局系统设置。 此外，Docker 社区有同时间的open issue (moby/moby#19289），也要求 Docker 支持 core_pattern