React 设计模式指南

当今复杂动态系统的可观察性取决于领域知识，或者更重要的是，基于不完整的领域知识产生的未知“未知”。换句话说，落在裂缝之间的案例让我们感到惊讶，如以下引文所示：

我们花了不到一个小时就弄清楚了如何恢复网络;需要额外的几个小时，因为我们花了很长时间才控制行为异常的 IMP 并使它们恢复正常。内置的软件警报系统（当然，假设它不受误报的影响）可能使我们能够更快地恢复网络，从而显着缩短中断的持续时间。这并不是说更好的警报和控制系统可以替代试图正确分配重要资源利用的仔细研究和设计，而只是说它是一个必要的辅助手段，可以处理即使是最仔细的设计也不可避免地落在裂缝之间的情况 - （罗森， RFC 789)

从本质上讲，可观察性是我们如何暴露系统的行为（希望以某种有纪律的方式）并理解这种行为。

在本文中，我们将讨论可观测性的重要性，并将研究如何编写可观察 Rust 应用程序的基础。

为什么可观测性很重要？

由于微服务部署和编排引擎的激增，如何在 Windows 11 中访问高级启动选项（6 种方法）我们的系统变得更加复杂，大公司运行着数千个微服务，甚至初创公司也在运营数百种微服务。

微服务的严酷现实是，它们突然迫使每个开发人员成为云/分布式系统工程师，处理分布式系统固有的复杂性。具体而言，部分故障，其中一个或多个服务的不可用可能会以未知方式对系统产生不利影响。–（Meiklejohn等人，服务级别故障注入测试)

在这个复杂的时代，实现可观测性对于长期构建、故障排除和对系统进行基准测试大有帮助。提供可观测性首先从我们正在运行的系统收集输出数据（遥测和检测），在适当的抽象级别（通常围绕请求路径进行组织），以便我们可以探索和剖析数据模式并找到互相关。

在纸面上，这听起来很容易实现。Windows 11怎么禁用笔记本自带的键盘？3个方法轻松搞定我们收集了三个支柱（日志、指标和跟踪），然后就完成了。然而，这三个支柱本身只是位，而收集最有用的位并一起分析位的集合则最复杂。

形成正确的抽象是困难的部分。它可以是非常特定于领域的，并且依赖于为我们的系统行为构建一个模型，该模型可以接受更改并为意外做好准备。它涉及开发人员必须更多地参与如何生成和诊断其应用程序和系统中的事件。

到处抛出日志语句并收集每个可能的指标会失去长期价值并引起其他问题。我们需要公开和增强有意义的输出，以便数据关联成为可能。

毕竟这是一篇 Rust 文章，虽然 Rust 在构建时考虑了安全性、速度和效率，但公开系统行为并不是其创始原则之一。

我们如何使 Rust 应用程序更易于观察？

从第一原则开始，我们如何检测代码，收集有意义的跟踪信息，并派生数据以帮助我们探索未知的“未知”？如果一切都由事件驱动，并且我们有捕获一系列事件/操作的跟踪，包括请求/响应、数据库读/写和/或缓存未命中等，那么对于必须与外界通信以实现端到端可观测性的 Rust 应用程序来说，从无到有的诀窍是什么？构建块是什么样的？

可悲的是，这里不仅有一个技巧或银弹，尤其是在编写 Rust 服务时，这给开发人员留下了很多东西。首先，我们唯一可以真正依赖来理解和调试未知“未知”的是遥测数据，我们应该确保我们呈现有意义的上下文遥测数据（例如，可相关的字段，如、和）。其次，我们需要一种方法来探索该输出并将其跨系统和服务相关联。request_pathparent_spantrace_idcategorysubject

在这篇文章中，我们将主要关注收集和收集有意义的上下文输出数据，但我们还将讨论如何最好地连接到提供进一步处理、分析和可视化的平台。幸运的是，核心工具可用于检测 Rust 程序以收集结构化事件数据并处理和发出跟踪信息，以实现异步和同步通信。

我们将重点介绍最标准和最灵活的框架，跟踪，它位于跨度、事件和订阅者周围，以及如何利用它的可组合性和可定制性。

然而，即使我们有一个广泛的框架，趣知笔记比如跟踪，帮助我们在 Rust 中编写可观察服务的基础，有意义的遥测并不是“开箱即用”或“免费掉出来的”。

在 Rust 中获得正确的抽象并不像在其他语言中那样简单。相反，一个健壮的应用程序必须建立在分层行为之上，所有这些行为都为知情的开发人员提供了示例性控制，但对于那些缺乏经验的人来说可能很麻烦。

我们将把问题空间分解为一系列可组合层，趣知笔记网站地图这些层在四个不同的行为单元上起作用：

• 存储上下文信息以备将来使用

• 使用上下文信息扩充结构化日志

• 通过检测和跨度持续时间派生指标

• 分布式跟踪的开放遥测互操作性

类似于关于基于属性的测试的原始 QuickCheck 论文如何依靠用户指定属性并为用户定义的类型提供实例，构建端到端可观察的 Rust 服务需要了解跟踪是如何生成的，如何指定和维护数据，以及随着应用程序的增长，哪些遥测是有意义的。在调试和/或探索不一致、部分故障和可疑性能特征时尤其如此。

跟踪收集将驱动本文示例中的所有内容，其中跨度和事件将成为我们将已知数量的完整图片联系在一起的镜头。我们将有日志，但我们会将它们视为结构化事件。我们将收集指标，但通过检测和跨度实现自动化，并将与OpenTelemetry兼容的跟踪数据导出到像Jaeger这样的分布式跟踪平台。

范围、事件和跟踪

在进入实现细节之前，让我们从一些我们需要熟悉的术语和概念开始，例如跨度、跟踪和事件。

跨越

跨度表示属于跟踪的操作或段，并充当分布式跟踪的主要构建基块。对于任何给定的请求，初始跨度（没有父级）称为根跨度。它通常表示为给定分布式跟踪的整个用户请求的端到端延迟。

还可以有后续子跨度，这些子跨度可以嵌套在其他不同的父跨度下。跨度的总执行时间包括在该跨度中花费的时间以及由其子项表示的整个子树。

下面是新请求有意压缩的父跨度日志的示例：

level=INFO span name="HTTP request" span=9008298766368774 parent_span=9008298766368773 span_event=new_span timestamp=2022-10-30T22:30:28.798564Z http.client_ip=127.0.0.1:61033 http.host=127.0.0.1:3030 http.method=POST http.route=/songs trace_id=b2b32ad7414392aedde4177572b3fea3

此跨度日志包含重要的信息和元数据，例如请求路径 （）、时间戳 （）、请求方法 （） 和跟踪标识符（分别是 、 和）。我们将使用此信息来演示如何将跟踪从开始到完成绑定在一起。http.route2022-10-30T22:30:28.798564Zhttp.methodspanparent_span``trace_id

为什么叫跨度？Ben Sigelman是Google的Dapper追踪基础设施论文的作者，他在《The Span》简史中考虑了这些因素： 难以爱，难以杀死：

• 在代码本身中，API 感觉就像一个计时器

• 当将跟踪视为有向图时，数据结构看起来像一个节点或顶点

• 在结构化、多进程日志记录的上下文中（旁注：归根结底，这就是分布式跟踪），人们可能会将跨度视为两个事件

• 给定一个简单的时序图，很容易将这个概念称为持续时间或窗口

事件

事件表示时间上的单个操作，其中在执行某个任意程序期间发生了某些事情。与带外非结构化日志记录相比，我们将事件视为在给定跨度上下文中发生的摄取的核心单元，并使用键值字段进行结构化（类似于上面的跨度日志）。更准确地说，这些事件称为跨度事件：

level=INFO msg="finished processing vendor request" subject=vendor.response category=http.response vendor.status=200 vendor.response_headers="{\"content-type\": \"application/json\", \"vary\": \"Accept-Encoding, User-Agent\", \"transfer-encoding\": \"chunked\"}" vendor.url=http://localhost:8080/.well-known/jwks.json vendor.request_path=/.well-known/jwks.json target="application::middleware::logging" location="src/middleware/logging.rs:354" timestamp=2022-10-31T02:45:30.683888Z

我们的应用程序还可以具有在跨度上下文之外发生的任意结构化日志事件。例如，在启动时显示配置设置或监视刷新缓存的时间。

痕迹

跟踪是表示某些工作流（如服务器请求或项目的队列/流处理步骤）的跨度集合。本质上，迹线是跨度的有向无环图，其中连接跨度的边指示跨度与其父跨度之间的因果关系。

下面是在 Jaeger UI 中可视化的跟踪示例：

如果此应用程序是更大的分布式跟踪的一部分，我们将看到它嵌套在更大的父跨度中。

现在，有了这些术语，我们如何开始实现