服务不是静态的，当一个副本发生故障，一个节点变得不健康或由于其他原因时，Swarm每次发布都会重新安排它们。我们应尽全力为Swarm提供尽可能多的信息。我们对所期望的服务状态描述得越好，Swarm就会做得越好。
我们不会介绍通过docker service create和docker service update命令提供的所有信息。相反，我们将专注于--reserve-memory参数。稍后，你可以将相似的逻辑应用于--reserve-cpu、--limit-cpu、--limit-memory和其他参数。
我们将观察Grafana中的内存指标并相应地更新服务。
请点击Grafana中的每个容器的内存使用量（堆栈）图，然后选择查看。你将看到一个缩放图形的界面，可显示前20个容器的内存消耗。可以通过从服务名称列表中选择prometheus来过滤指标。
Prometheus使用将近175 MB的内存，让我们把这个信息添加到服务上，如图10-12所示。
图10-12 使用Prometheus服务过滤容器内存消耗的Grafana图
更新prometheus服务以预留200 MB的内存。可以假设它的内存使用量会随着时间的推移而增加，所以我们保留了比当前需要的更多的内存。
请注意--reserve-memory并没有真正地保留内存，但给了Swarm一个暗示，即我们期望该服务应该使用多少内存。有了这些信息，Swarm就可以在集群内更好地分配服务。
让我们确认Swarm重新安排了服务：
service ps命令的输出如下（为简洁起见，删除了ID和错误列）：
还可以确认--reserve-memory参数确实生效了：
输出如下：
正如你可以从Resources部分看到的那样，服务现在保留了200 MiB内存。我们应该为logstash、go-demo、go-demo-db、elasticsearch和代理服务重复一系列类似的操作。
结果可能会在你的笔记本电脑上有所不同。在我的笔记本电脑上，基于Grafana指标保留内存的命令如下：(www.xing528.com)
每次更新后，Swarm将重新安排属于该服务的容器。结果，Swarm将它们以一种内存不会耗尽的方式放置在一个集群中。你应该把同样的流程扩展到CPU和其他指标上，并定期重复。
请注意，增加内存与CPU限制和预留并不总是正确的做法。大多数情况下，你可能需要扩展服务以使资源的使用分布在多个副本中。
本章使用了随时可用的仪表板，我认为它们是一个很好的起点，并提供良好的学习体验。随着时间的推移，发现仪表板最适合你组织的需求，并且可能会开始修改这些仪表板或创建专门针对需求的新仪表板。希望你能回馈给社区。
如果你创建的仪表板与本章中使用的仪表板互补，甚至可以取代它们，请告诉我，我很乐意在书中介绍它们。
在进入第11章之前，让我们讨论一些监控最佳实践。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
