我正在设置一个通用的Elasticsearch-Logstash-Kibana堆栈来部署到我的一些客户端。 我正在尝试对一些pipe道进行模板化，这样我们只需要根据需要为每个客户端部署config / pipelines。
Logstash将input{...} ， filter{...}和output{...}作为部分及其内容作为插件 ，将它们作为处理pipe道进行聚合，并将每个pipe道包含在文件中作为configuration文件 。
考虑到这一点，是否有部分和pipe道的范围？ 也就是说，在一个特定的configuration文件中定义的部分是否只用于该configuration文件中的pipe道？
如果我有2个configuration文件和2个pipe道：
# my_apache_pipeline.config input { tcp { port 5000 } } filter { if [application == "httpd"] { ... } } output { elasticsearch { ... } }
和
#my_nginx_pipeline.config input { tcp { codec => "json" port => 6000 } } filter { if [application == "nginx"] { ... } } output { elasticsearch { ... } }
做这两个以上的configuration文件创build相同的2pipe道作为单个下面的configuration文件？
#my_merged_pipeline.config input { tcp { codec => "json" port => 6000 } tcp { port 5000 } } filter { if [application == "nginx"] { ... } if [application == "httpd"] { ... } } output { elasticsearch { ... } }
也就是说，一组插件/部分用于获取pipe道的configuration文件是否重要？ 或者，在特定configuration文件中定义的input {...}仅适用于该configuration文件中的filter {...}和output {...}
据我了解它的工作方式，configuration范围是全球性的，给定部分（ input ， filter ， output ）的内容都基本上在“最终”configuration连接在一起。
所以在你的例子中，是的，上面的两个pipe道将等同于下面的简化configuration，唯一的区别是你有两个 elasticsearch输出，而不只是一个。 我不认为LS聪明，知道他们是一样的。
我的build议是根据部分，函数和日志types创build很好的命名文件：
#inputs 00-input-lumberjack.conf 01-input-syslog.conf 02-input-syslog_vmware.conf #filters 11-filter-haproxy.conf 12-filter-lighttpd.conf 13-filter-syslog.conf 14-filter-proftpd.conf 15-filter-httpd.conf 17-filter-cron.conf 18-filter-yum.conf 88-filter-checksum.conf 89-filter-cleanup.conf #outputs 97-output-kafka.conf 98-output-redis.conf 99-output-elasticsearch.conf
然后，您可以使用-f开关指向包含上述所有文件的文件夹来运行LS。
这将确保它们按特定顺序加载，并且不会有重复。
在我的情况下，filter和输出被包围if检查types/主机/文件/等等，以确保给定的部分只适用于某些事件。
这也允许一些额外的东西。
inactive子文件夹并重新启动LS来快速激活/取消激活部分; 它不会recursion加载configuration文件