Я настраиваю универсальный стек 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
) в "окончательной" конфигурации в основном объединено. Таким образом, в вашем примере, да, два вышеуказанных трубопровода приравниваются к упрощенной конфигурации ниже, с той лишь разницей, что у вас будет два выхода для эластичного поиска
, а не только один. Я не думаю, что 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 для проверки типа/хоста/файла/ и т.д. . чтобы убедиться, что данный раздел применим только к определенным событиям.
Это также позволяет сделать пару дополнительных вещей.
неактивную подпапку и перезапуская LS; он не загружает конфигурационные файлы рекурсивно