日志调试不理想？试试分布式追踪优势

太过爱你忘了你带给我的痛 2022-10-19 14:00 263阅读 0赞

![img][]

**目录**

日志调试的困难

1. 记录是一个手动及耗时的过程

2. 很难找到合适的平衡点

3.跨服务跟踪日志很困难

4. 日志没有标准化

什么是分布式追踪？

分布式追踪优势

1. 可视化

2. 自动化

3. 加快发布时间

4. 跨服务跟踪请求

5. 易于使用和实施

6. 有洞察力

我们什么时候应该使用分布式追踪？

1. 分布式架构

2. 识别和分析系统问题困难

3. 需要可观察性

分布式追踪工具

1. Jaeger

2.Zipkin

3. Aspecto

结论

--------------------

在调试微服务时，开发人员可能很难确定问题的根本原因。即使有日志，但需要在多个服务中搜索，花费大量时间往往是令人沮丧。

然而，面对所有这些挑战，还有一线希望——分布式追踪。

分布式追踪，为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。

本文，我会和大家一起了解什么是分布式追踪、它的好处以及它在你的团队系统中扮演的角色。然后我们将介绍开发人员可以使用哪些工具，在云原生环境中实现分布式追踪。

## 日志调试的困难 ##

当我们试图了解意外响应或生产故障时，日志非常有用。但是，日志没有无限的功能。以下是他们在调试微服务时给开发人员带来的一些挑战：

### 1. 记录是一个手动及耗时的过程 ###

添加日志不是一个自动过程，它需要大量细致的手动工作。确定调试所需的所有潜在信息，添加日志，必要时删除它们——这些都需要很长时间，需要付出很多努力。此外，该过程容易出错。开发人员可能会花费大量时间添加日志，但仍会错过他们在生产中所需的确切信息。

### 2. 很难找到合适的平衡点 ###

开发者需要确保自己有足够的日志用于调试，但不要太多日志，浪费太多时间在添加和分析上，这就很难创造这种平衡。如果他们没有记录足够的信息，他们将错过用于调试的数据。如果他们记录的太多，这个过程就会变得资源密集，并使日志分析变得更加困难。

### 3.跨服务跟踪日志很困难 ###

跨多个服务、容器和进程，跟踪和分析日志具有挑战性。开发人员必须能够理解所有不同日志之间的关系，这需要他们了解不同服务中的代码逻辑，并将它们与日志相关联。

即使是在业务逻辑中，添加了唯一标识符来跟踪服务日志的公司，也会面对难以汇总和分析的困难。

### 4. 日志没有标准化 ###

日志没有标准化或结构化格式，这意味着任何开发人员都可以根据自己的风格创建消息和事件。虽然这提供了灵活性和自由度，但对于你的团队来说，试图理解其他人的日志或对其进行解释，可能具有挑战性。

因此，日志并不总是提供解决性能和故障所需的信息。有许多解决方案试图克服这些挑战，其中包括标准化约定、最佳实践、分析工具等。但是，也许我们需要意识到日志记录有其局限性，你的团队需要另一种调试微服务的解决方案。

而这个解决方案就是追踪。

## 什么是分布式追踪？ ##

日志提供有关服务内部发生的事情的信息，而分布式追踪则告诉你服务/组件之间发生的事情及其关系。这对于微服务来说非常重要，因为组件之间的集成失败会导致许多问题。

此外，日志是一种手动操作工具，可用于任何级别的活动。这也是为什么有许多日志记录最佳实践可供开发人员学习的原因。另一方面，跟踪是自动生成的，提供对架构最完整的理解。

分布式追踪是适应微服务架构的跟踪。分布式追踪旨在实现跨服务和模块的请求跟踪，为云原生系统提供了可观察性。

## 分布式追踪优势 ##

在日志有限的地方，分布式追踪蓬勃发展。让我们看看分布式追踪如何解决日志调试微服务的困难。

### 1. 可视化 ###

分布式追踪，一般具备可视化。与日志相反，开发人员不必想象通信流程并在他们的脑海中形成一个图像。相反，他们可以在眼前看到它。这使开发人员更容易理解服务之间的关系并解决性能瓶颈等问题。

![img][img 1]

### 2. 自动化 ###

与日志不同，跟踪是自动的。开发人员不必手动添加日志来获得完整的信息。相反，他们会自动获得用户请求所发生情况的可视化信息。

### 3. 加快发布时间 ###

分布式追踪提供了服务的可观察性和清晰的画面。这提高了组织的生产力，因为它使开发人员可以花更少的时间来尝试定位错误和调试它们。因此，生产力得到提高，开发人员可以花更多时间开发业务功能，同时也加快了发布时间。

### 4. 跨服务跟踪请求 ###

微服务间的通信交互，往往会跨越多个服务。分布式追踪可以理解这些系统和组件之间的关系。它是通过传递给处理它们的服务的唯一ID 跟踪和记录所有这些请求来完成的。因此，开发人员可以在整个架构中看到请求的流程和进展，这在日志调试时通常是难以实现的。

### 5. 易于使用和实施 ###

分布式追踪，不会将你限制为一种语言或某些应用程序，从而为你的团队节省了大量时间和麻烦。

### 6. 有洞察力 ###

分布式追踪为开发人员提供了大量有洞察力的信息。这包括请求时间、有关组件的信息、延迟、应用程序运行状况等。所有这些信息在系统调试和故障原因分析期间都非常有用，可用于提高代码质量和快速解决用户问题。

![img][img 2]

## 我们什么时候应该使用分布式追踪？ ##

好问题！以下是分布式追踪可以为你和你的团队提供帮助的三个主要场景。

### 1. 分布式架构 ###

如果你的部门使用分布式架构，我们强烈建议实施分布式追踪。如你所见，这是跨服务跟踪请求的最佳方法。尤其当应用涉及许多团队协作开发并且流程复杂时，这相当重要。

它确保你不会浪费时间尝试跨机器调查问题或搜索无休止的日志。

### 2. 识别和分析系统问题困难 ###

开发人员，有时候即使得到很多日志，也很难识别和分析系统的问题，这正是分布式追踪的用途。跟踪为你提供了你分析问题所需的所有信息，而没有日志调试的缺点。所以如果你不知道系统问题是什么，你可以对系统进行自动分析。

### 3. 需要可观察性 ###

分布式追踪使你可以了解系统和服务以及它们之间的关系。你可以看到请求的完整链路信息、它们花费了多长时间、对系统健康状况的洞察等等。你不仅可以使用分布式追踪来确定问题发生的原因，还可以保持对分布式系统的可观察性。

## 分布式追踪工具 ##

通过上文，我们知道了分布式追踪可以让你的生活更轻松，或者至少缩短你的调试时间。

以下跟踪工具将补充你的日志记录工作，尤其是在微服务架构中：

### 1. Jaeger ###

[Jaeger][]是一个开源的分布式追踪工具。它支持事务监控、延迟优化和高级数据分析。Jaeger 支持大多数常用语言，并且支持 Kubernetes。它是一个[云原生计算基金会][Link 1]毕业的项目。

![img][img 3]

### 2.Zipkin ###

[Zipkin][]是一个与 Jaeger 非常相似的开源工具，也提供了分布式追踪功能。Zipkin也可以使用 Docker，和不同方式区别不大，归根结底还是看个人喜好和具体的技术栈需求。

![img][img 4]

### 3. Aspecto ###

[Aspecto][]就像分布式应用程序的 Chrome DevTolls，帮助开发人员在整个开发周期中查找、修复分布式应用程序问题。

Aspecto 是基于 OpenTelemetry 的，它通过实施遥测数据来了解你的系统，然后将你在本地执行的操作与生产环境或其他基准数据进行比较，从而允许你的更改部署生产环境之前，得到验证并防止问题发生。

![img][img 5]

## 结论 ##

通过实施分布式追踪，你可以看到你的请求和服务的完整信息，并减少调试时间。尝试使用开源工具（如Jaeger或Zipkin）进行分布式追踪，如果你正在想要预测应用更改的效果，请尝试使用Aspecto，以获得更快的反馈和更高的可见性。

译文连接: [https://thenewstack.io/tracing-why-logs-arent-enough-to-debug-your-microservices/][https_thenewstack.io_tracing-why-logs-arent-enough-to-debug-your-microservices]

[img]: /images/20221004/4e7beb83cbe94cdda9d88cbe6aaea387.png
[img 1]: /images/20221004/cd6e823a52af4fa5ad61a772ae92bb5c.png
[img 2]: /images/20221004/75cace5a86d345a4997054dc9b4696c4.png
[Jaeger]: https://www.jaegertracing.io/
[Link 1]: https://www.cncf.io/
[img 3]: /images/20221004/aafcc3fbf2644ea69f34c41865f3a334.png
[Zipkin]: https://zipkin.io/
[img 4]: /images/20221004/6ab92e0c80b24b1fb1209bf6b5643376.png
[Aspecto]: https://www.aspecto.io/?utm_source=thenewstack&utm_medium=blog&utm_campaign=logs-vs-traces
[img 5]: /images/20221004/29a7fb50fa084da29c482c1184be6239.png
[https_thenewstack.io_tracing-why-logs-arent-enough-to-debug-your-microservices]: https://thenewstack.io/tracing-why-logs-arent-enough-to-debug-your-microservices/