From 4d7b105da5d1a3f35ca87b2636d9b24d9662e45b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=84=91=E8=A2=8B=E9=87=8C=E8=BF=9B=E8=8A=B1=E7=94=9F?= =?UTF-8?q?=E4=BA=86?= <109732988+Redmomn@users.noreply.github.com> Date: Fri, 31 Jan 2025 10:54:05 +0800 Subject: [PATCH] fix: typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit “透穿”应为“透传” --- src/logs/tracing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/logs/tracing.md b/src/logs/tracing.md index 392484b5..b9fee598 100644 --- a/src/logs/tracing.md +++ b/src/logs/tracing.md @@ -3,7 +3,7 @@ 随着微服务的流行，现在一个产品有多个系统组成是非常常见的，这种情况下，一条用户请求可能会横跨几个甚至几十个服务。此时再用传统的日志方式去跟踪这条用户请求就变得较为困难，这就是分布式追踪在现代化监控系统中这么炽手可热的原因。 -关于分布式追踪，在后面的监控章节进行详细介绍，大家只要知道：分布式追踪的核心就是在请求的开始生成一个 `trace_id`，然后将该 `trace_id` 一直往后透穿，请求经过的每个服务都会使用该 `trace_id` 记录相关信息，最终将整个请求形成一个完整的链路予以记录下来。 +关于分布式追踪，在后面的监控章节进行详细介绍，大家只要知道：分布式追踪的核心就是在请求的开始生成一个 `trace_id`，然后将该 `trace_id` 一直往后透传，请求经过的每个服务都会使用该 `trace_id` 记录相关信息，最终将整个请求形成一个完整的链路予以记录下来。 那么后面当要查询这次请求的相关信息时，只要使用 `trace_id` 就可以获取整个请求链路的所有信息了，非常简单好用。看到这里，相信大家也明白为什么这个库的名称叫 `tracing` 了吧？ @@ -497,4 +497,4 @@ fn main() -> Result<()> { 如果你让我推荐使用哪个，那我的建议是: - 对于简单的工程，例如用于 POC（ Proof of Concepts ） 目的，使用 `log` 即可 -- 对于需要认真对待，例如生产级或优秀的开源项目，建议使用 tracing 的方式，一举解决日志和监控的后顾之忧 \ No newline at end of file +- 对于需要认真对待，例如生产级或优秀的开源项目，建议使用 tracing 的方式，一举解决日志和监控的后顾之忧