Назад | Перейти на главную страницу

Каков объем директив в конвейерах 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 {...} в этом файле конфигурации?

Насколько я понимаю, как это работает, область конфигурации глобальна, а содержимое данного раздела (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для проверки типа / host / file / и т. д., чтобы убедиться, что данный раздел применим только к определенным событиям.

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

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