Какова область применения директив в конвейерах logstash?
Я настраиваю общий стек Elasticsearch-Logstash-Kibana для развертывания на нескольких моих клиентах. Я пытаюсь создать шаблон некоторых конвейеров, так что нам нужно только развернуть конфиги / конвейеры по мере необходимости для каждого клиента.
Logstash относится к input{...}
, filter{...}
, а также output{...}
в виде разделов и их содержимого в виде плагинов, их агрегирование в качестве конвейера обработки и файл каждого конвейера содержится в файле конфигурации.
Имея это в виду, есть ли возможности для секций и трубопроводов? То есть разделы, определенные в определенном файле конфигурации, используются только конвейером в этом файле конфигурации?
Если бы у меня было 2 файла конфигурации и 2 конвейера:
# 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 {
...
}
}
Создают ли эти два файла конфигурации те же 2 конвейера, что и один файл конфигурации ниже?
#my_merged_pipeline.config
input {
tcp {
codec => "json"
port => 6000
}
tcp {
port 5000
}
}
filter {
if [application == "nginx"] {
...
}
if [application == "httpd"] {
...
}
}
output {
elasticsearch {
...
}
}
То есть имеет ли значение, в каком конфигурационном файле находится набор плагинов / разделов для получения конвейеров? Или делает input {...}
определенные в конкретном файле конфигурации применяются только к filter {...}
а также output {...}
в этом конфигурационном файле?
1 ответ
Насколько я понимаю, как это работает, область конфигурации является глобальной и содержимое данного раздела (input
, filter
, output
) все в основном объединены в "окончательную" конфигурацию.
Так что в вашем примере, да, два конвейера выше будут соответствовать упрощенной конфигурации ниже, с той лишь разницей, что у вас будет два elasticsearch
выходы, а не только один. Я не думаю, что Л.С. достаточно умен, чтобы знать, что они одинаковы.
Я предлагаю создавать файлы с красивыми именами на основе раздела, функции и типа журнала:
#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
Затем вы запускаете LS с -f
Переключатель, указывающий на папку, которая содержит все файлы выше.
Это гарантирует, что они будут загружены в определенном порядке, и что у вас не будет дублирования.
В моем случае фильтры и выходы окружены if
Необходимо проверить тип / хост / файл / и т.д.., чтобы убедиться, что данный раздел относится только к определенным событиям.
Это также позволяет пару дополнительных вещей.
- Быстро активировать / деактивировать разделы, перемещая файлы в
inactive
подпапка и перезапуск LS; он не загружает конфигурационные файлы рекурсивно - Работа над новыми типами журналов вне диапазона, затем скопируйте новый файл конфигурации в каталог и перезапустите LS