|
|
|
|
@ -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 的方式，一举解决日志和监控的后顾之忧
|
|
|
|
|
- 对于需要认真对待，例如生产级或优秀的开源项目，建议使用 tracing 的方式，一举解决日志和监控的后顾之忧
|
|
|
|
|
|
脑袋里进花生了
4 weeks ago
committed by
GitHub