У ELK’и иголки колки: минимизируем потерю сообщений в Logstash, следим за состоянием Elasticsearch

[amarao]

Главная проблема logstash, он невероятно медленный. В бенчмарках (~2015) он делал около 3000 сообщений в секунду на UDP listener перед тем, как начать существенно терять. Всё упиралось в однопоточный udp listener внутри java. Сама java тормознутая (в сравнении с С/С++/Rust), плюс сам logstash не быстрый, плюс в один поток слушать сокет...

Короче, под нагрузкой всё плохо. 3k pps UDP вообще ни о чём, а logstash захлёбывается.

[Insurgent2018]

тоже соглашусь, очень медленный, очень прожорливый по ресурсам, некоторые output плагины — с кучей багов, пока поймешь, как обходить, все нервы потратишь.

[PrinceKorwin]

а какие альтернативы? не троллю, действительно интересно.

[amarao]

Люди про graylog рассказывают, loki. Для админских задач хватает journald, у которого есть remote send (но с которым я, например, пока не пробовал).

В целом, ELK, став проприетарным, перестал быть интересным. Ну да, ещё одна проприетарная штука на яве с лицензией и HANA-подходом.

[ky0]

Балансировать на несколько логстэшей, если не требуется какая-то хитрая обработка — отправлять сразу в ES.

[shuron]

Под мониторинг Prometheus, grafana а вот ELK я бы не стал. Прожерлив, капризен.

Если же толькио под логи, то ELK мне лично очень, и Logstash очень мощён, много чего можно с ним сделать… мы раньше доп. информацией логи снабжали и писали в спец. индексы и т.д. из логов много видели...

Но если хочется все в одном наверное сегодня надо смотреть в grafana стек, и там для логов есть вышеупомянутый loki. Я лично его ещё не видел в бою, но по документации очень правильная штука.

[SlavikF]

Мне тоже интересен вопрос альтернативы.
Я пытался разобраться, и пришёл к тому, что логи отправляю с помощью Beats.
Beats имеют меньше возможностей по обработке сообщений, но зачастую достаточно.
Beats — быстрее.

Вот что я не очень понял — теряет ли Beats сообщения, если Beats временно теряет связь с Elastic host. Beats умеют retries, но я не очень разобрался, насколько оно надёжно и как работает.
Если у кого есть опыт — поделитесь.

[Bkmz]

Вроде как у filebeat есть queue и если ES не отвечает, то filebeat будет ждать пока есть время жизни у harvester'a и после восстановления ES все отправит. Но это при том, что за время отсутсвия ES файлы с логами не удалились и не истекли всякие таймауты.

[sergiochoo]

FluentD

[z0mb1ek]

Java тормознутая в кривых руках обычно) Потестить производительность можно через benchmark tool

[dtarasov7]

Ну наверно за 6 лет в плане быстродействия могло что-то и поменяться. Хотя конечно хочется большего…
Я провел тест с помощью tcpflood (утилита из комплекта rsyslog).
logstash-oss-7.10.1 — 100000 событий (размером 250 байт) — за примерно 10 сек без потерь.
4 потока у logstash. на VM — 4 vCpu. load average 1m ~0.35. Для Xmx=Xms=1GB
Это конечно тоже не космос, но все же больше чем в 2015-ом…
Для сравнения нашел logstash 6.0.0 — это 2017 год.
У него результаты хуже — 100000 за 27 секунд — это выходит примерно 3.5K EPS.

Вот Pipeline
input {
udp {
port => 2514
}
}

filter {
metrics {
meter => "events"
add_tag => "metric"
}
}
output {
if "metric" in [tags] {
stdout {
codec => line {
format => "rate: %{[events][count]}"
}
}
}


[amarao]

А, вы так делали?

Я статистически определял. У меня был фиксированный генератор (~100 сообщений в секунду) и генератор мусора с подстраиваемой скоростью. Я подбирал такую скорость генератора мусора, чтобы видеть ~100 "полезных" сообщений. Как только рейт падал (< 99), я смотрел сколько мусора входило, это и был показатель "начал терять сообщения".

[M0rdecay]

По поводу persisted queue на Logstash

У этого механизма есть не упомянутая в документации особенность, которая может знатно попить крови - page_capacity должен быть строго меньше max_bytes (понятно, что больше делать неразумно, но даже равенство этих параметров не допускается).

Несоблюдение чревато внезапной остановкой обработки событий при внешнем отсутствии явных проблем.