Istio 概念 - 服务间通信和跟踪

Istio concepts - inter-service communication and tracing

编辑:我正在重写这个问题以缩小评论中建议的范围。

Deploying the application 下,文档说,

To run the sample with Istio requires no changes to the application itself. Instead, you simply need to configure and run the services in an Istio-enabled environment, with Envoy sidecars injected along side each service.

我有一个 NodeJS 后端 API,它使用 winston 包写入日志。我认为,应用程序 必须更改,以便来自 winston 包的日志可以参与分布式跟踪。这是正确的吗?

分布式跟踪系统通常需要在出站请求中添加 headers 以告知跟踪系统和下游任务跟踪给定请求属于哪个。虽然这不是 Istio-specific,但 Istio 确实有需要传递的文档 a list of OpenTracing headers。如果您不这样做,那么服务之间的每次调用都将显示为单独的跟踪,而不是将它们拼接在一起成为一个统一的 end-to-end 跟踪。

这与您的日志系统是分开的。除非您通过 HTTP 将日志发送到 Logstash 之类的东西或直接发送到 Elasticsearch,否则日志根本不会显示在跟踪中。另一方面,您不需要将日志设置中的任何内容更改为 "work with" Istio,但主要是因为没有太多直接交互。

不,你的假设不正确。 Istio 跟踪与日志无关。这都是关于由 Istio 管理并由 sidecar 自动修改的自定义 headers,以允许每个 sidecar 处理流量在流量进入(请求)和离开(响应)时放置时间戳。这为您提供了参与网络调用的容器之间的实际延迟的有用图片。

最重要的是,您可以自由修改您的应用程序代码,以包含更详细的 method-level 跟踪,使用一些 OpenTracing-compatible 库为您的应用程序的语言。基本上,除了 Winston 日志记录之外,您还添加了一些行,以便也包括代码执行管道的检查点。虽然您可以解析日志并使用日志时间戳通过数学方法对其进行测量,但要实现 opentracing 已经为您提供的功能,还有更多工作要做。