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

Logstash / elasticsearch перестает принимать новые данные

Я установил новую систему проверки концепции logstash

CentOS 6.6 (on Vmware 5.5) - single CPU VM with 12G RAM allocated

Elasticsearch и Logstash устанавливаются с RPM…

# rpm -q elasticsearch logstash
elasticsearch-1.7.1-1.noarch
logstash-1.5.3-1.noarch

JVM: 1.8.0_51

Данные, которые я ввожу, - это простые записи в форме…

M1234 z123 2015-01-31 23:28:09.417 8.55373

(поля - это имя машины, идентификатор пользователя, дата, время, время, затраченное на вход в систему - все просто US-ASCII)

Конфигурация Logstash ниже (эти данные поступают из базы данных MSSQL, и на данный момент я экспортирую в текстовый файл и передаю файл на сервер logstash).

Это нормально работало для дневных журналов (11K записей), но когда я пытаюсь обработать отставание за этот календарный год, оно «зависает».

Симптомами этого являются

Похоже, это происходит примерно с 200 тыс. Документов. На него не влияет количество индексов - я начал с дневных индексов, а затем перешел на еженедельные - он все еще останавливает около 200 тыс. Документов.

Поскольку это доказательство концепции, работающей на одной машине, я уменьшил счетчик реплик до 0, а сегментов до 1 - я не думаю, что это должно иметь какое-либо значение для этой проблемы.

Я не вижу никаких ошибок в журналах logstash или elasticsearch, несмотря на то, что я включил многословие в обоих.

Я не думаю, что системе не хватает памяти, дискового пространства, файловых дескрипторов.

Я не знаю, на что еще смотреть. Это похоже на проблему незначительного размера (для ELK), и я не вижу этой проблемы в существующей настройке ELK, которая обрабатывает наши почтовые журналы (хотя она работает с более ранними версиями и имеет несколько узлов хранения elasticsearch)

Хотя я уверен, что во входных файлах нет нечетных байтовых последовательностей, я явно объявил вход как US_ASCII с charset => "US-ASCII" в file входной плагин строфа. Я не думаю, что это что-то изменит (тест все еще продолжается).

Обновление: хотя в журналах не было ничего интересного, когда импорт остановил строки, зарегистрированные при logstash попросили выключить, было интересно…

{:timestamp=>"2015-08-03T10:17:39.104000+0100", :message=>["INFLIGHT_EVENTS_REPORT", "2015-08-03T10:17:39+01:00", {"input_to_filter"=>20, "filter_to_output"=>0, "outputs"=>[]}], :level=>:warn}

Подразумевается, что проблема в стадии фильтрации, а не в выводе на elasticsearch. Я подтвердил это, сначала избавившись от elasticsearch вывод и просто имея stdout. Это показало то же поведение - импорт через некоторое время остановился.

Помещение elasticsearch вывести обратно, но очистить все в filter раздел дал мне успешный, полный импорт данных.

Теперь у меня есть исправление - подробности в ответе.

input {
        file {
                path => "/var/lib/clusters/*"
                type => "clusterF"
                start_position => "beginning"
        }
}

filter {
        mutate {
                remove_field => [ "path", "host" ]
        }
        # 13COMP014   nabcteam    2015-07-29 11:09:21.353 153.493
        if [type] == "clusterF" {
                grok {
                        match => { "message" => "%{NOTSPACE:client} +%{WORD:userid} +%{TIMESTAMP_ISO8601:datestamp} +%{BASE10NUM:elapsed:float}" }
                }
        }
        if [elapsed] < 0 {
                drop {}
        }
        if [elapsed] > 1000.0 {
                drop {}
        }
        if [userid] =~ "[a-z][0-9]{7}" {
                mutate {
                        add_field => [ "userClass", "student" ]
                }
        } else if [userid] =~ "n[a-z].*" {
                mutate {
                        add_field => [ "userClass", "staff" ]
                }
        } else {
                mutate {
                        add_field => [ "userClass", "other" ]
                }
        }
        date {
                match => [ "datestamp", "ISO8601" ]
        }
        mutate {
                remove_field => [ "message" ]
        }
}

output {
        elasticsearch {
                bind_host => "clog01.ncl.ac.uk"
                protocol => "http"
                cluster => "elasticsearch"
                flush_size => 10
                index => "clusters-%{+xxxx.ww}"
        }
}

Как только я узнал, что ларек происходит вокруг filter скорее, чем output это было намного легче найти.

Помещение elasticsearch вывести обратно, но очистить все в filter раздел дал мне успешный, полный импорт данных.

Я написал простой perl скрипт для проверки строк ввода на соответствие grok спецификация - это показало мне, что некоторые идентификаторы пользователя содержат дефисы (чего я не ожидал). Замена +%{WORD:userid} с участием +%{NOTSPACE:userid} в исходной конфигурации дал мне рабочую настройку. Я подозреваю, что в первую очередь мне следовало добавить поле при успешном grok и применять другие правила фильтрации, только если это поле присутствует.

Основная мораль, которую я извлекаю из этого, заключается в том, что важно упростить такого рода проблемы, иначе пространство для поиска потенциальных причин будет слишком большим.