既生瑜，何生亮，SkyWalking 和 ELK 实现链路追踪的实践

一、背景

最近在给项目搭建日志平台的时候，采用的方案是 SkyWalking + ELK 日志平台，但发现 ELK 日志平台中的日志没有 Trace ID，导致无法追踪代码报错的整体链路。

空哥提示：Trace ID 是分布式追踪中用来唯一标识一个服务请求或事务的 ID。在微服务架构中，一个请求可能会经过多个服务节点，Trace ID 帮助追踪和关联整个请求链路中的所有日志和性能数据。

既然 SkyWalking 提供了日志的链路追踪，为什么 ELK 没有链路追踪 ID 呢？ 带着这个疑问我们继续往下看。

二、SkyWalking 和 ELK 啥关系啊？

• SkyWalking: 专注于应用性能监控(APM)的系统，主要提供分布式追踪、服务性能分析和多维度监控功能。

  它支持自动化代码埋点，能够追踪微服务之间的调用关系和性能指标。

• ELK：日志数据的集中管理和分析，Elasticsearch + Logstash + Filebeat，作为日志采集和存储，Kibana 作为可视化日志检索平台。

SkyWalking 和 ELK 是如何联系在一起的？我们一步一步往下看。

2.1 SkyWalking

SkyWalking 本来就带有链路追踪，而且通过搭建 SkyWalking-UI 服务就可以以通过界面来查看日志。

SkyWalking 整体架构如下：

FROM http://skywalking.apache.org/

• 最上面的 Tracing：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器，目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。我们采用的是 SkyWalking Agent 收集 SkyWalking Tracing 数据，传递给 SkyWalking OAP 服务器。
• 中间的 SkyWalking OAP 服务器 ：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
• 最右边的 Storage ：负责存储 Tracing 数据。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。
• 最左边的 SkyWalking UI ：一个网页版的界面，提供查看数据的功能。