下面将从Node Exporter服务（https：//github．com/prometheus/node_exporter）开始。它会导出与服务器相关的各种类型的指标。
给Windows用户的说明
为了使下一个命令中的挂载生效，你需要阻止Git Bash转换文件系统路径。设置环境变量：
本章包含许多使用挂载的docker service create命令。在你执行这些命令之前，请确保环境变量MYS_NO_PSTHCONV存在并且被设置为1：
由于需要node-explorer在每台服务器上都可用，因此可指定该服务为全局的。通常，我们将它连接到专门用于监控工具的单独网络（例如，monitoring）。但是，本地运行的Docker机器可能会遇到两个以上网络的问题。由于已经通过scripts/dm-swarm-services-3.sh（https：//github．com/vfarcic/cloud-provisioning/blob/ master/scripts/dm-swarm-services-3.sh）创建了go-demo和proxy网络，所以达到了安全限制。出于这个原因，我们也会使用现有的proxy网络来监控服务。在运维“真实”集群时，应该为监控服务创建一个单独的网络。
我们也挂载了几个卷。
/proc目录非常特别，它也是一个虚拟文件系统。它有时被称为进程信息伪文件系统。它不包含“真实”文件，而是包含运行时系统信息（例如，系统内存、安装的设备、硬件配置等）。
因此，/proc目录可以被视为内核的控制和信息中心。实际上，相当多的系统工具只是简单地调用这个目录中的文件。例如，lsmod与cat/proc/modules相同，而lspci是cat/proc/pci的同义词。通过更改位于该目录中的文件，甚至可以在系统运行时读取/更改内核的sysctl参数。node-exporter服务将用它来找到系统内部运行的所有进程。
现代Linux发行版包含一个作为虚拟文件系统的/sys目录（sysfs，可与作为/procfs的/proc比较），它存储并允许修改连接到系统的设备，而许多传统的UNIX和类Unix操作系统使用/sys作为内核源码树的符号链接。
sys目录是Linux提供的虚拟文件系统。它通过关于各种内核子系统、硬件设备和相关的设备驱动程序的信息从内核的设备模型导出到用户空间来提供一组虚拟文件。通过将其公开为一个卷，服务可以收集有关内核的信息。
最后定义prom/node-exporter镜像并传递给它几个命令参数。我们为/proc和/sys指定了目标卷，然后忽略容器内的挂载点。
更多信息请访问Node Exporter项目（https：//github．com/prometheus/node_ exporter）。
此时，该服务应该正在集群内运行，让我们确认一下：
serivce ps命令的输出如下（为简洁起见，删除了ID）：
现在快速查看node-exporter服务提供的指标。我们将使用util服务来获取指标：
curl输出的示例如下：
如你所见，这些指标采用Prometheus友好的格式。请浏览Node Exporter collectors（https：//github．com/prometheus/node_exporter#collectors），以获取有关每个指标含义的更多信息。现在，应该知道你需要的大部分节点信息都是可用的，并且稍后将由Prometheus进行拉取。
由于通过Docker网络发送请求，因此得到的是负载均衡之后的响应，从而无法确定哪个节点产生了输出。当配置Prometheus时，必须更具体并跳过网络负载均衡。
现在有了关于服务器的信息，应该添加特定于容器的指标，我们将使用称为容器顾问的cadvisor。
cadvisor使得容器用户能够理解其正在运行的容器的资源使用情况和性能特征。它是一个持续运行的守护进程，用于收集、聚合、处理和导出有关正在运行的容器的信息。具体而言，对于每个容器，它保留了资源隔离参数、历史资源使用情况、完整的历史资源使用情况的直方图和网络统计，这些数据在容器和机器范围内被导出，它原生支持Docker容器。
下面来创建这个服务：
就像node-exporter一样，cadvisor是全局服务，并连接到了代理网络。它挂载了几个目录，允许它监视主机上的Docker统计信息和事件。由于cadvisor带有Web UI，因此打开了端口8080，这将允许我们在浏览器中打开它。
在继续之前，应该确认服务确实在运行：
service ps的输出如下（为简洁起见，删除了ID）：
现在可以打开UI了。
给Windows用户的说明(www.xing528.com)
Git Bash可能不支持open命令，如果真是这样的话，执行docker-machine ip <SERVER_NAME>来查找机器的IP，然后直接在浏览器里打开URL，比如上面的命令应该被替换为docker-machine ip swarm-1，如果命令输出的是1.2.3.4，则应该在浏览器里打开http：//1.2.3.4：8080/。
随意向下滚动，浏览cadvisor提供的不同图形和指标（见图10-1），如果还不够，就可以通过单击屏幕顶部的Docker Containers链接来获取有关运行容器的信息。
图10-1 cadvisor界面
尽管在第一眼看来它可能令人印象深刻，但UI除了对单个服务器或多或少有用之外，其他情况下都没什么用处。由于被设计为一个监控单个节点的工具，所以它在Swarm集群中的用途不大。
首先，页面和它发出的所有请求都由ingress网络进行负载均衡。这意味着不仅不知道哪个服务器返回给了UI，而且返回由指标和图形使用的数据的请求也是负载均衡的。换句话说，来自所有服务器的不同数据是混在一起的，给了我们一个非常不准确的画面。可以跳过使用该服务并使用docker run命令运行镜像（针对每个服务器重复）。但是，尽管这样可以让我们看到特定的服务器（数据），但我们还是被迫从一台服务器跳转到另一台服务器，因此该解决方案仍然不够好。我们的目标不止于此，需要从整个集群收集并可视化数据，而不是单个服务器。因此，必须抛弃用户界面。
作为一个侧面说明，某些类型的指标在node-exporter和cadvisor服务之间存在重叠。你可能会试图选择其中一种，但他们的关注点不一样，只有两者结合才能完成整个画面图景。由于我们确定托管在Swarm集群内的UI没有用处，所以没有必要公开端口8080。因此，我们应该将其从服务中删除。你可能会试图删除该服务并在不暴露该端口的情况下再次创建该服务。没必要这么做，相反，可以通过更新服务来消除端口：
通过检查service inspect命令的输出，你会注意到该端口未打开（它根本不存在）。
现在，cadvisor服务正在运行，我们不会受到无用的UI的干扰，因此可以快速查看cadvisor导出的指标：
我们取得了不错的进展。我们正在导出服务器和容器的指标，可以不停地继续添加指标，并将本章扩充到令人难以忍受的篇幅。下面将把创建提供额外信息的服务作为你稍后要做的练习。现在进入Prometheus章节，毕竟，如果不能查询和可视化，那么拥有指标就没有多大用处。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
