完成了ELK栈的中E，现在让我们转到L。LogStash需要一个配置文件，可使用vfarcic/cloud-provisioning（https：//github．com/vfarcic/cloud-provisioning）代码库中已有的一个。创建一个新目录，复制conf/logstash.conf（https：//github．com/ vfarcic/cloud-provisioning/blob/master/conf/logstash.conf）配置，并在logstash服务中使用它：
logstash.conf文件的内容如下：
这是一个非常简单的LogStash配置，用于在端口51415上监听syslog条目。
每个条目会被发送到两个输出：elasticsearch和stdout。由于logstash和elasticsearch连接的是同一个网络，所以可以直接把服务名作为主机名。
第二个输出把所有内容发送到stdout。请注意，在生产环境中运行LogStash之前，应删除此配置，它会产生不必要的开销，如果服务很多的话，那么开销会很大。这里这么配置，仅仅是为了展示日志是如何经过LogStash的。在生产中，你无须查看标准输出，而是使用Kibana查看整个系统的日志。
让我们继续并创建第二个服务。
给Windows用户的说明
为了能够让以下命令中的mount参数正常工作，你需要阻止Git Bash修改文件系统路径。设置环境变量：
我们创建了一个名为logstash的服务，并将主机卷docker/logstash作为/conf挂载到容器中。这样就可以在容器内使用当前位于主机上的配置文件。
请注意，挂载卷不是将配置放入容器内的最佳方式。相反，应该将配置文件构建在镜像中，我们应该创建一个Dockerfile，它可能如下所示：
这个配置文件不应该经常更改（如果会更改的话），因此，基于logstash创建新镜像的方式要比挂载卷的要好得多。但是，为了简单起见，我们使用mount。一旦你开始应用从本章中学到的东西，就要记得构建镜像。
我们还定义了环境变量LOGSPOUT，现在还用不到，稍后会对其进行说明。
logStash服务现在应该已经启动并正在运行，让我们再次确认：
输出应如下所示：
如果当前状态仍未运行，请稍等片刻并重复service ps命令。只有在logstash运行之后，我们才能继续。
现在可以确认logStash正确初始化。我们需要找出它正在运行的节点，获取容器的ID，然后输出日志：(www.xing528.com)
上一个logs命令的输出如下：
"Pipeline main started"意味着LogStash正在运行并等待输入。
在建立一种从集群内的所有容器发送日志的解决方案之前，先执行一个中间步骤来确认LogStash确实可以在端口51415上接收syslog条目，创建一个名为logger-test的临时服务：
该服务会连接到elk网络，以便与logstash服务进行通信。
我们需要把重启条件设置为空，否则进程结束之后容器会停止，Swarm会将其检测为失败并重新安排它。换句话说，如果没有把重启条件设置为空，Swarm将进入无限循环，一直试图重新安排将要停止的容器。
正在执行的命令会发送一个syslog消息给在端口51415上运行的logstash。消息内容是hello world。
让我们再次输出LogStash日志：
输出如下：
首先Swarm需要下载debian镜像，并且一旦发送了logger消息，LogStash就必须接受日志条目。LogStash处理第一个条目需要一些时间，所有后续的条目会被立刻处理。如果你的输出与上面的输出不一样，请稍等片刻，然后重复执行logs命令。
正如你所看到的，LogStash收到了hello world消息。它还记录了其他一些字段，如时间戳和主机，请忽略错误消息_grokparsefailure_sysloginput。可以配置LogStash来正确解析日志消息，但由于后面不会再用到它，所以就不再浪费这个时间了。很快会看到更好的转发日志的方式。
LogStash充当消息的解析器并将其转发给ElasticSearch。现在你得相信我的话。很快就会看到如何存储并探索这些消息。
把logger-test服务删除，它的目的只是演示我们有一个接受系统日志消息的LogStash实例：
通过调用logger发送消息很棒，但这并不是我们想要完成的目标。
我们的目标是能够转发集群中任意位置运行的所有容器中的日志。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
