出了阿里内部的鹰眼，最近也出来这个也不错
原文地址：http://www.jdon.com/48932
最近，IBM，Google和Lyft宣布推出Istio，这是一个开放源代码平台，帮助管理微服务分布式应用程序。Istio背后的关键原则之一是在微服务基础架构上提供统一的可观察性，而不需要特殊的工具。模块化的优点在软件工程中是众所周知的; 然而，包含大量微服务器的分布式应用程序对调试和故障排除提出了额外的挑战，特别是随着这些组件数量的增长以及它们的相互关系变得更加复杂以后。长期以来，日志和指标测量(metrics)一直是分析这些应用程序的行为并进行调试的有用手段。不幸的是，从个别微服务收集的日志和测量指标并不能提供关于整个应用程序行为的整体视图，因而就不足以揭示造成许多问题和错误的根本原因。假设问题是应用程序突然开始变慢，在试图解决这个问题时，可能会提出以下问题：1. 如何识别出问题根源的组件？2. 微服务之间的所有互动是什么？3. 与故障有关的哪些相互作用能够观察到？4. 哪个微服务是性能瓶颈？5. 微服务之间有什么意想不到的相互作用吗？显然，查看每个微服务器的日志和指标将成为一个噩梦。Istio如何帮助调试微服务性能？Istio服务网格的核心是Envoy，这是由Lyft设计，宣布和推广的开源L7代理和通信总线。在Istio中，每个微服务都与Envoy实例并置，该实例负责处理所有传入和传出的网络流量。因此，实际上，所有Envoy实例一起共同形成通信导管，微服务通过此通信导管彼此相互作用; 因此，每个Envoy实例都可以参与监控所有的服务间API调用，并记录每个呼叫所需的时间以及它是否成功完成。在Istio运行工作期间，我们决定利用Envo的上述观察能力，协助开发人员进行调试和故障排除。Envoy已经支持分布式跟踪的商业解决方案; 我们的主要目标是让开发人员能够清楚地看到所有微服务之间所有交互的大图。在Envoy中，使用Zipkin协助进行日志跟踪：每当微服务进行外部调用时，Envoy启动一个新的跨度span。一个跨度代表一对微服务器之间的完全交互，从请求者（客户端）发出请求直到接收到另一方（服务器）的响应为止。在请求客户端运行的Envoy会开始一个跨度，并将转发请求的时间记录在服务器端的Envoy上，而这又意味着跨度正在进行，并记录了请求被接收的时间。当微服务完成处理请求后，相应的Envoy会记录时间，并将响应发送给请求方。然后，在客户端Envoy会察觉到一个跨度已经完成，Envoy会记录收到响应的时间并计算跨度持续时间。假设只有跨度的创建者（客户端/请求者）单方面计算跨度持续时间，这样值是不完整的。参与此次互动的Envoy都只是部分了解跨度持续时间：客户端Envoy知道何时开始请求并收到响应; 另一方面，服务器Envoy知道自己何时收到请求并发出响应。每个Envoy将自己的跨度视图发布到Zipkin，然后将合并所有时间信息。因此，除了知道所谓的微服务为服务请求所需的时间之外，Zipkin还将同步所有这些时间信息，从而知道整个网络中请求和响应的时间要多长时间。当服务于一个请求时，微服务可能需要调用另一个微服务，从而导致因果关联的跨度的创建。具有相同根跨度的所有跨度形成痕迹trace。因此，需要跟踪捕获一个根请求所需的整个因果关联请求链。这些可通过Zipkin UI可快速查看。具体如何实现可见原文：Distributed tracing for cloud-native applications