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

0
задан 11 August 2015 в 12:21
1 ответ

Насколько я понимаю, как это работает, область конфигурирования является глобальной и содержимое данного раздела (input, filter, output) в "окончательной" конфигурации в основном объединено. Таким образом, в вашем примере, да, два вышеуказанных трубопровода приравниваются к упрощенной конфигурации ниже, с той лишь разницей, что у вас будет два выхода для эластичного поиска , а не только один. Я не думаю, что LS достаточно умна, чтобы знать, что они одинаковые.

Я предлагаю создать красиво названные файлы на основе секции, функции и типа журнала:

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

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

  1. Быстро активируйте/деактивируйте секции, перемещая файлы в неактивную подпапку и перезапуская LS; он не загружает конфигурационные файлы рекурсивно
  2. Работайте с новыми лог-типами вне диапазона, затем скопируйте новый конфигурационный файл в каталог и перезапустите LS
1
ответ дан 4 December 2019 в 16:51

Теги

Похожие вопросы