仪表板中缺少主机名。如果选择主机名列表，就会注意到它是空的。背后的原因在于node-exporters服务。由于它在容器内部运行，所以并不知道底层主机的名称。
我们已经评估过node-exporters的IP不是很有用，因为它们表示的是网络端点的地址。我们真正需要的是“真正的”主机IP或主机名称。由于无法从Docker服务获取真正的IP，所以替代方法是使用主机名。然而，由于没有提供官方的node-exporters容器，所以需要寻求替代方案。
下面将使用由GitHub用户bvis创建的镜像更改node-exporter服务。该项目可以在bvis/docker-node-exporter（https：//github．com/bvis/do cker-node-exporter）GitHub存储库中找到。因此，我们将删除node-exporter服务，并基于basi/node-exporter（https：//hub.docker．com/r/basi/node-exporter/）镜像创建一个新服务。
除了使用不同的镜像basi/node-exporter，还挂载了/etc/hostname目录，容器可以从中检索名称底层主机。我们还添加了环境变量HOST_HOSTNAME以及一些额外的收集器。
我们不会详细解释这个命令，因为它与之前使用的相似。附加参数的含义可以在项目的README（https：//github．com/bvis/docker-node-exporter）文件中找到。
要注意的是，新的node-exporters服务将包括主机名和由Docker网络创建的虚拟IP。可以用它来建立两者之间的关系。
其实可以更新之前运行的服务，而不是创建新的服务，但我决定不这样做，这样你可以看到完整的命令，以便于你在生产集群中选择使用节点指标。
请返回已在你的浏览器中打开的Grafana仪表板，然后刷新屏幕Ctrl+R或Cmd+R。你会注意到，一些原来空的图表由于从新的node-exporter来的指标出现了彩色。
Hostnames列表在左侧显示了所有节点的IP，在右侧显示了主机名。现在可以选择主机和节点的CPU使用率、节点的可用磁盘、节点的可用内存和节点的磁盘I/O的任意组合，图像也会相应更新，如图10-8所示。
图10-8 带有节点指标的Docker Swarm Grafana仪表板
不仅获得了仪表板所需的部分数据，而且建立了虚拟IP和主机名之间的关系。现在你可以找出其他仪表板中使用的虚拟IP和主机名之间的关系。特别是，如果监视Node Exporter仪表板并发现有问题需要修复，则可以返回到Swarm仪表板并找出对应的主机。
直到问题27307（https：//github．com/docker/docker/issues/27307）被修复之前，主机名解决方案虽然不是最好的，但应该还是一种体面的方案，选择取决于你。通过将虚拟IP与主机名相关联的功能，我选择坚持使用Docker服务，而不是采用非Swarm解决方案。
接下来需要解决的是服务组的问题。
如果你打开Service Group列表，就会发现它是空的。背后的原因在于仪表板的配置方式，它期望通过容器标签com.docker.stack.namespace来区分服务，由于没有指定任何标签，因此列表只包含“All”选项。
应该有哪些服务组？这个问题的答案视情况而定。随着时间的推移，你将定义最适合你组织的服务组。目前把服务分成数据库、后端和基础设施。我们将go-demo-db放到db组中，将go-demo放到后端，其余的放到infra下面。虽然elasticsearch是一个数据库，但也是基础设施服务的一部分，因此把它放到infra下面。
现在可以为现有服务添加标签。没有必要删除它们并创建新的。相反，可以通过使用--container-label-add参数来执行docker service update命令而添加com.docker.stack.namespace标签。
将放入组中的第一项服务是go-demo_db：
确认标签确实被加上了：
--format参数让我们避免了冗长的输出，并只显示我们感兴趣的内容。
service inspect命令的输出如下：
正如你所看到的，com.docker.stack.namespace标签已加上并且保存了值db。
应该对go-demo服务执行相同的操作，并将其放入后端组：
最后一组是infra，由于该组包含相当多的服务，因此只用一条命令更新它们：
我们遍历所有服务的名称并为每个服务执行service update命令。
请注意，service update命令会重新安排副本。这意味着容器将停止运行并且以新的参数再次运行。在所有服务全面运作之前，可能需要一段时间。请使用docker service ls列出服务，并在继续之前确认它们全部正在运行。一旦所有副本都启动，就应该返回到Grafana仪表板并刷新屏幕（Ctrl+R或cmd+R）。
这次，当打开服务组列表时，就会注意到我们创建的三个组现已可用。继续往前，并选择一个或两个组。你会看到与服务相关的图表正在发生相应的变化。
还可以按服务名称筛选结果，并将某些图表中显示的指标限制为选定的一组服务。
如果向下滚动到仪表板的中间，就会注意到与代理相关的网络图有很多的服务，而排除了代理的网络图是空的。可以通过代理选择器进行更正，它允许定义哪些服务应该被视为代理。请打开列表并选择代理，如图10-9所示。
图10-9 带有网络流量图的Grafana仪表板(www.xing528.com)
与代理相关的两个网络图现在仅限于代理服务，或者更具体地说，是我们定义的服务。底部现在包含所有其他服务的指标。分别监控外部流量和内部流量是有用的。通过代理图，可以看到外部来源的进出流量，而另外两个网络图则用于服务之间的内部通信。
现在生成一些流量并确认这些变化反映在代理图中。下面生成100个请求：
如果回去看代理网络图表，应该会看到流量激增。请注意，仪表板每分钟刷新一次数据。如果仍然看不到峰值，可能需要等一会，单击位于屏幕右上角的“Refresh”按钮，或改变刷新频率，请参考图10-10。
图10-10 带有网络流量图的Grafana仪表板
现在继续探索仪表板菜单中的下一个选项，然后单击“错误”复选框。该复选框已连接到Elasticsearch。由于没有记录的错误，所以图表保持不变。
现在生成一些错误，看看它们如何呈现在看板中。
go-demo服务有一个API，可以让我们创建随机错误。平均来说，会有十分之一的请求产生错误。我们需要用它们来演示Prometheus指标与Elasticsearch数据之间的一个集成：
输出样本应如下所示：
如果回去看仪表板，就会注意到红线代表错误发生的时间点。当发生这种情况时，你可以调查系统指标并尝试推断错误是由某些硬件故障、网络资源耗尽还是由其他原因引起的。如果全部失败，就应该转到Kibana UI，浏览日志并尝试从中推断出原因。请参阅图10-11。
图10-11 带有网络流量图的Grafana仪表板
系统不会将报告误报为错误，这一点很重要。如果你发现通过日志报告了错误，但没有任何事情可做，那么最好还是更正代码以便特定情况下不会被视为错误。否则，如果发生误报，就会看到太多错误并开始忽略它们，而当发生真正的错误时，你很可能反而注意不到。
因为它们与商业产品X-Pack（https：//www.elastic.co/products/x-pack）相关，所以跳过“警报已解决”和“已解决警报”选项。由于本书针对开源解决方案，因此跳过它。这并不意味着你不应该考虑购买它。恰恰相反，在某些情况下，X-Pack是一个对工具集有价值的补充。
这就结束了我们对Docker Swarm和Container Overview仪表板选项的快速探索。图表本身应该是不言自明的，花点时间自己去探索一下。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
