Какова область применения директив в конвейерах 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Необходимо проверить тип / хост / файл / и т.д.., чтобы убедиться, что данный раздел относится только к определенным событиям.

Это также позволяет пару дополнительных вещей.

  1. Быстро активировать / деактивировать разделы, перемещая файлы в inactive подпапка и перезапуск LS; он не загружает конфигурационные файлы рекурсивно
  2. Работа над новыми типами журналов вне диапазона, затем скопируйте новый файл конфигурации в каталог и перезапустите LS
Другие вопросы по тегам