当应用程序是整体式应用程序时，突然，一旦应用程序发布，就将另一个未知数添加到可用性计算公式中-网络。 由于组件之间的调用存在问题，应用程序经常掉下来并开始抽动。 找出导致分布式应用程序不稳定的原因是另一项任务。 条件kubernetes造成应用程序结构中的其他混乱，它可以自行决定是否可以通过条件节点任意分配条件pod。 我写的是“有条件的”，因为可能有Swarm和Openshift以及其他一些人代替了Kubernetes。
我的意思是，没有正常的可视化，很难确定温度在哪里。 在削减的基础上，我对可以绘制应用程序图并突出显示应用大蕉的工具的潜在功能的想法进行了介绍，并提供了带有截图的这些工具的列表。
让我们开始弄清楚在应用程序图上希望看到什么，然后我们将考虑监视方法，然后继续研究特定的供应商。
我想在应用程序地图上看到的内容
首先想到的是能够按特定条件对应用程序节点进行分组的能力。 例如，我说在这个组中我有一个前端，在这个后端或这里我有Payments服务的实例，在这里是Shipping。 好吧，依此类推。 负责这一部分或那一部分的人员会立即看到他们职责范围内正在发生的事情的全貌。
第二个是按级别对应用程序进行布局，使其能够查看例如基础结构，服务，服务实例等。 与第一种情况一样，它有助于识别问题层。
第三 ，这些节点的输出和输入，包括它们之间的连接。 在这些字符串上，我希望看到Google在“监视分布式系统”的第6章中的Site 6可靠性工程中描述的黄金信号。 我已经
在Medium的博客上发布了本章
的译文。 信号如下：延迟，流量（吞吐量），错误（错误率）和饱和度（饱和度）。
也许我没有考虑到某些问题。 如果您认为缺少其他重要内容，请转到评论。
有哪些不同的监控方法
我不知道它还能叫什么，因此我将其称为方法代理和无代理监视。 现在我将从胡解释胡。
代理监控
代理监视意味着需要在受控应用程序中实施特殊的监视代理。 代理将跟踪ID嵌入到数据包头中。
这种类型包括APM监视解决方案以及所有通过将SDK注入应用程序代码而嵌入的解决方案。
优点：有助于查找问题的根本原因，标头可以准确跟踪事务的路径。
缺点：由于应用程序算法的修改，可能无法嵌入旧版应用程序，支持有限的一组编程语言而可能产生的开销
无代理监控
无需修改应用程序即可进行监视。 此类型包括日志，在操作系统级别进行跟踪以及监视网络流量。
优点：监视各种框架和编程语言的覆盖范围，可以在不可能添加跟踪ID的情况下工作，在受控应用程序上没有开销。
缺点：如果没有跟踪ID，则很难恢复业务交易的上下文，如果配置了SSL封装且没有密钥，则将无法侦听流量，
供应商提供什么
Vendorov在Agent / lessagent的基础上进行了分解，您可以在评论中或在个人消息中要求其他特征。 我想在Instana，Appdynamics和New Relic上获得最大的经验，如果您愿意的话，我可以为您提供超过14天的演示许可证帮助（默认情况下，它们在其网站上提供）。
代理监控
Instana是用于监视分布式系统的工具。 一个关键功能是针对所有受支持技术的单个代理程序以及每秒收集一次指标。
Appdynamics是APM监视的著名解决方案。 能够基于应用程序组件之间的调用来构建应用程序映射。 需要代理监视来监视呼叫。
New Relic是Appdynamics的直接竞争对手。 关键区别在于只能从云进行监视（代理也安装在目标服务器上）。 根据调用构建应用程序映射。
Dynatrace是APM监视工具。 它支持监视各种编程语言，并且可以在云和本地环境中工作。
AWS X-Ray-监视AWS上托管的应用程序。 支持应用程序图的可视化，需要安装自己的SDK。
OpenTracing是用于检测分布式应用程序的API。 许多
商业和非商业解决方案都基于此API。
Jaeger是免费的开源交易工具。 建立在OpenTracing的基础上。
Datadog APM是用于监视分布式应用程序的商业工具。 它在上述OpenTracing基础上工作。
无代理监控
OpenZipkin是用于跟踪分布式应用程序的免费工具。 他的工作特点是使用工具库来收集有关调用的数据，并将该数据进一步发送到OpenZipkin收集器。
Linkerd是用于跟踪应用程序内调用的免费工具。 它是OpenZipkin的附加组件，它作为Sidecar容器安装在kubernetes基础设施上。
Envoy是一个免费工具。 它充当代理，在应用程序组件之间向其发送呼叫数据。 没有自己的Web界面，可以通过HTTP GET请求接收数据或将其发送到statsd。
Netsil是用于基于侦听流量来监视分布式应用程序的工具。 无论使用哪种语言编写应用程序，它都可以工作。
告诉谁使用了什么以及留下了什么印象。