有关“您的Dockerized应用程序的运行状况如何？”的这篇文章。解释了监视的麻烦，但没有提供任何有关如何实际监视docker容器内部微服务的良好示例。

我们目前正在使用PM2 monit监视我们的微服务，将它们放入docker容器后，我们将无法在一个屏幕上访问所有数据的数据，这些微服务都在各自的docker容器中运行。

Dockerswarm监视会告诉我们容器的状态，但是不是微服务在其中运行。

解决此问题的可靠方法是什么？

#1 楼

这是Kubernetes拥有正确模型的地方，所有系统之间都应该有一个负载平衡器，该平衡器应该具有运行状况检查功能。系统开始构建大型状态机。这将打破松散耦合模型，并引入相互依存关系，从而抑制了易重构性。虽然并非一成不变，但微服务和SOA其他变体之间的关键区别是这种松散耦合。

如果服务是细粒度的并且执行单个功能，请在上游负载均衡器上进行运行状况检查，然后监视活动池成员。

作为HAproxy中的一个示例

backend myapp
[...]
option tcp-check
tcp-check send GET\ /health HTTP/1.0\r\n
tcp-check send Host:\ foo\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.1\ 200\ Ok
tcp-check expect string container\ Good
server srv1 10.0.0.1:8080 check
server srv2 10.0.0.2:8080 check


从理论上讲，您并不关心实际的容器，只是您的整体性能良好。只需检查您期望的系统数量是否还可以运行，如果不是，则可以启动更多系统。如果您需要增加容量，则只需更改期望的节点数即可。

这也简化了重构，因为您只需要复制或修改此测试，而无需外部依赖项或状态机。

随着系统自我修复，它还应该减少停机时间和午夜的Pagerduty警报。

对于整个系统指标，需要跟踪诸如延迟之类的问题，我希望它们在中心位置使用诸如Elasticsearch之类的工具。如果您使用syslog，logstash或log4？收集从长远来看将更加有用的指标。当系统较小且简单时，传统的基于轮询的监视可能会提供足够的指标，但最好采用可搜索的格式，并且更重要的是与其他系统相关。

诸如monit之类的解决方案仍然占有一席之地，但是它可以监视存在时间很长的组件（例如托管您的群集的VM或裸机），但是容器本身应与该系统分离，以从微服务模型中获得最大收益。 br />

评论

为什么我不关心特定容器的性能？这不是找出瓶颈所在并知道何时进行扩展的最简单方法吗？

–avi
17年5月21日在7:38


您可以跟踪容器主机的性能，这是相同的。但是，是否要遵循微服务模型确实是一个问题。虽然这不是完成工作的唯一选择，但松耦合是该模型的核心租户之一

– gdahlm
17年5月21日在20:11


@gdahim对不起，我的问题不清楚。我问这是怎么引起耦合的。我看到了运行状况检查的好处，但是您的回答对我而言并不明确，为什么我不关心容器中的CPU或内存使用情况。

–avi
17年5月22日在7:15
原因多种多样，但其中原因很少：1）代理版本和配置将需要在整个环境中同步，这需要协调一致的努力。 2）内部系统的任何更改或重构都将潜在地产生警报或减少监视，这可能导致需要协调更改。 3）它增加了每个集装箱所需的服务，这将需要集成测试或闸门。但也要记住，容器是一个名称空间，而不是一个单独的实体，监视容器主机将产生相同的数字。

– gdahlm
17年5月22日在17:21

#2 楼

一种常用的解决方案（不是特定于容器的）是在您的服务中构建运行状况检查API，以测试您要监视的所有功能（例如数据库和其他依赖项的可用性）和应用本身，并返回一些预期的输出（例如<服务>：<状态>）。然后，如果此API并未对所有服务都返回OK，则可以从Nagios等监视服务触发警报。如果微服务本身不健康，这也将失败。

这种方法还具有对服务进行功能测试的优势（通过点击API端点）。但是，这种方法并未涵盖某些边缘情况-例如微服务运行（但特定的API失败）。