迄今为止，我们所做的一切，先不提在本书其余部分将要完成的任务，降低系统复杂性的同时也在某种程度上增加了其复杂性。使用Docker Swarm扩展服务比只使用容器更简单。一方面，Docker已经简化了我们之前的过程，加上自带服务发现的新的networking功能，结果就是简单到令人难以置信。另一方面，表面下隐藏着复杂性。如果尝试将迄今为止使用的动态工具与在（和）别的时期创造的工具结合起来，那么可以很容易观察到这种复杂性的一种表现方式。
以Nagios（https：//www.nagios.org/）为例，我不会说不能用它来监控系统（当然可以）。我要说的是，它会与我们迄今设计的新系统架构发生冲突。我们的系统比以前的复杂得多。副本的数量在波动。虽然今天可能有四个服务实例，明天上午可能有六个，但到了下午又只有三个。它们分布在集群的多个节点上，并且四处移动，服务器不停地被创建和销毁。我们的集群和它内部的一切都是真正动态的和弹性的。
我们构建的系统的动态特性不适合Nagios。Nagios期望服务和服务器相对静态，期望我们提前定义好一切。这种方式的问题在于我们没法提前获得这些信息，而Swarm可以。即使我们得到了需要的信息，它也会很快改变。
我们正在建立的系统是高度动态的，我们要用来监控这样一个系统的工具需要能够处理这种动态性。
不仅如此，大多数“传统”工具倾向于将整个系统视为一个黑匣子，这么做的原因是，一方面具有一定的优势，另一方面是它可以让我们将服务与系统的其他部分解耦。在许多（但不是全部）情况下，白盒监控意味着需要将监控代码库添加到服务中，并在其周围编写一些代码，以便它们可以暴露服务的内部。
在选择向你的服务中添加一些与其工作不是很相关的内容之前，请三思。当采用微服务的方式时，我们在实现服务功能时应该尽量关注其主要目标。对于购物车来说，它应该是一个API，允许我们添加和删除项目。将别的代码和库文件添加到这个服务，以方便它可以在服务发现存储中注册自己，或者将其指标暴露给监视工具，这样会产生很多的耦合。一旦这样做了，未来的选择就会非常有限，且对系统进行更改可能需要更多的时间和精力。
设法避免将服务发现与我们的服务耦合起来。go-demo服务没有任何关于服务发现的知识，但我们的系统还是拥有了需要的所有信息。还有很多其他的例子，组织掉入陷阱并开始将其服务与周围的系统耦合起来。这种情况下，我们主要关注的是能否在监控方面取得同样的效果？能否把为服务编写的代码和生成指标的代码解耦？
再一次，白盒监控提供了黑盒没有的很多好处。还有一点，理解服务的内部让我们能够对粒度更小的细节进行操作，如果将系统视为黑盒，那将无法得到这些信息。
在为高可用性和快速响应时间而设计的分布式系统的世界里，仅限于健康检查和CPU，内存和磁盘使用的监控是不够的。我们已经拥有了可确保服务健康的Swarm，并且可以轻松写出检查重要资源使用情况的脚本。我们需要的不仅仅是这些，需要的是不会引入不必要耦合的白盒监控，还需要智能告警以便在出现问题时通知我们甚至自动解决问题。理想情况下，可以在发生问题之前得到告警并执行自动修复。(https://www.xing528.com)
对监控系统的一些要求如下。
● 一种去中心化的方式来生成指标，以应对集群的高度动态性。
● 一个多维数据模型，可根据需要在多个维度上进行查询。
● 一种高效的查询语言，可以让我们利用监控数据模型创建有效的告警和可视化。
● 简单，允许（几乎）任何人在没有额外培训的情况下使用该系统。
本章将继续之前开始的工作，探索如何导出不同的指标集合，如何收集这些指标，如何查询这些指标以及如何通过看板呈现这些指标。
在开始之前，应该做出一些选择，监控解决方案应使用哪些工具？
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
