Kubernetes监控：地图和追蹤的服务依赖性

可靠的分布式系统必须拥有观察和理解组件之间依赖性的能力，若不了解服务依赖关係造成的盲目性代价高昂：

令消费者失望的原因：「服务看起来不错； 其他一些依赖性导致错误。」长时间停机：「哪个服务导致停机？」错误的部署：「不知道此代码更改会影响该服务！」无效的计划：「哪些服务对最终用户交易最为重要？」
新兴产品希望解决跨服务的可观察性挑战。这些可观察性产品会生成时即时地图和追蹤，以捕获服务之间的依赖关係结构。此外，也能获得监视服务运行状况的黄金讯号－延迟、附载量和错误率。在本文中，我们将讨论Netsil Maps和OpenTracing，以提供对依赖关係结构和服务交互运行状况的完整性。

Netsil地图

Netsil应用程序运营中心 （AOC） 提供了自动Kubernetes服务及其相互作用的程式。可以在Kubernetes群集的多个抽象级别上创建Netsil。例如：下图显示了(a)主机、(b)命名空间和(c)窗格级别的反应。

除了依赖关係结构外，Netsil反应还显示了服务交互的延迟和附载量，只需点击两个服务之间的链接，即可取得任服务交互作用。例如：下图示範了 sock-shop / frontend 和 sock-shop / catalogue pod之间的http 交互概况 。透过相关URI、请求方法、返回状态代码等，有洞察力的讯息对延迟、附载量和错误率进行了分组。

Netsil AOC透过对数据进行深入分析生成服务交互图。Netsil反应不需要更改任何代码或容器即可了解服务交互的运行状况。AOC能够分析和理解大多数通用服务协议，包括 gRPC、HTTP2、HTTP、PostgreSQL、MySQL、DNS、Cassandra、Redis 等（点此处观看完整列表）。

DevOps团队轻鬆地将Netsil收集器部署为DaemonSet，并利用地图和指标。每次部署都会对其他依赖服务产生大程度的负面影响，Netsil反应不仅可以显示依赖性，还可以提醒延迟出现、附载量下降或错误率增加的负面影响等等。这样一来，可以防止不良部署影响生产，并避免代价高昂的停机时间。

Netsil反应出现在服务交互的各个部分，一种限制是缺少因果关係讯息。时间戳点和呼叫签名（即URI、MySQL查询等）提供了启发式推断因果关係。由于通信具有高度重複性，因此在单个事务级别不需要因果关係，但如果细粒度的单个事务级别追蹤对于程式需求非常，那么OpenTracing是一个不错但却麻烦的选择。

开放追蹤

Netsil使用「黑盒」方法生成地图，而OpenTracing使用「白盒」方法。对于 OpenTracing （或通常分布式跟蹤），应用程序代码：

创建跨部门功能

创建所需的上下文并将其发送到后续的链接範围使用

建立跨部门之间的因果关係。

例如：下图中，假设A、B、C表示与各个範围关係的服务。服务A创建 SpanA 作为请求处理的一部分。只有服务A知道自己满足进行中的请求并同时呼叫服务B和C，服务A将需要创建上下文并将其发送给服务B、C，服务B和C可以将它们各自的跨部门链设定为SpanA的子集。

只有应用程序具有可靠、明确的因果关係，因此出于实际使用，为了使跟蹤正常运用，必须向应用程序添加追蹤码。如果已经编写了大量的代码就会非常费力，尤其是为了插入追蹤码而难以更改的代码。还有许多第三方软体，例如缓存、数据库、付款处理、库存管理等等，可能无法为其插入跟追蹤代码。开创性的Google Dapper论文启发了许多分布式追蹤工作。

追蹤程序的另一个重要挑战是基础协议和上下资料串接所需的存取「空间」。儘管HTTP等协议提供对自定义功能的支持，但仍有许多协议没有存取空间。诸如gRPC，Thrift等的现代通信渠道都为OpenTracing提供技术支持，但是在没有这些渠道的情况下，底层运营商协议的约束成为跨服务串接资讯流动的挑战。

结论

观察和监视服务依赖性对微服务应用程序（通常对于任何分布式应用程序）的可靠性和性能至关重要。使用Netsil能够轻鬆的取得地图，并且可以了解通信和业务流程的结构。Netsil反应和指标能帮助DevOps团队进行部署管理、事件响应、原因分析和储存规划。
如果需要事务级别的切割，则应考虑更严紧的检测方法追蹤所有服务。进行追蹤时，开发团队必须适当地处理追蹤资料，确保底层的通信协议可以承载追蹤的资讯流动，并确保弹性分析可用于查询大量追蹤以获取有意义的见解。虽然追蹤工作可能需要几个月的时间才能得到成果，但是Netsil能在几分钟之内为kubernetes集群提供可观察性。