Как лучше контролировать logstash?


8

Я видел этот вопрос в списке рассылки несколько раз, но не получил удовлетворительного ответа.

Как лучше всего следить за тем, чтобы трубопровод не застревал? Клиенты -> logstash -> эластичный поиск.

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

Мнения приветствуются.


Может быть, поможет это Как проверить пульс
— Logstash

Ответы:


2

Лично я на самом деле проверяю, что redis все еще находится в очереди на центральном хосте регистрации, который находится выше по потоку от LS + ES.

то есть: redis-cli llen logstashменьше некоторого фиксированного числа.

Это может не указывать на то, что журналы вообще появляются в redis, но это тоже можно проверить, я думаю.

redis-cli info | grep total_commands_processedМожет быть, что-то вроде проверки, которая продолжает расти?


Разве это не будет увеличиваться с увеличением количества журналов? Нам нужно общее количество LPOP. Или, может быть, предупредить, когда LLEN становится слишком большим?
— Дэн Гартвейт,

Да. Я плохо сформулировал это, проверяю, что llen меньше некоторого числа, и предупреждаю, если это не так.
— Sirex

Не total_commands_processedвсегда будет увеличиваться, если не из logstash, а затем из самой infoкоманды?
— Дэн Гартвейт

2

Я использую zabbix в своей среде, но я полагаю, что этот метод может работать и в других установках. Я настроил следующую команду, которую zabbix разрешено использовать:

UserParameter=elasticsearch.commits,/usr/bin/curl -s 'localhost:9200/_cat/count?v' | /bin/sed -n '2p' | /bin/awk '{print $3}'

Это вернет количество зафиксированных записей эластичного поиска. Поэтому я беру это значение и делю на количество секунд, прошедшее с момента, когда я взял последний образец (проверяю каждую минуту), если это число падает ниже произвольного предела, я могу предупредить его. Я также использую zabbix, чтобы проверить, не умер ли PID logstash, и отключить его, а также выполнить следующую команду:

UserParameter=elasticsearch.health,/usr/bin/curl -s 'http://localhost:9200/_cluster/health?pretty=true' | /bin/sed -n '3p' | /bin/awk -F'\"' '{print $4}' | /bin/sed s/yellow/0/ | /bin/sed s/green/0/ | /bin/sed s/red/1/

Это вернет 1, если состояние кластера стало красным (желтый и зеленый в порядке), что я также могу предупредить.


0

Убедитесь, что журналы в секунду в вашей конечной точке (например ,asticsearch) выше некоторого базового уровня.

То есть выполните сквозную проверку, если ваш конечный результат работает правильно, вы знаете, что все шаги в конвейере работают правильно.

Если вы часто сталкиваетесь с проблемами или вам требуется более тщательный анализ, начните инструктировать каждый участок конвейера, например, redis, как предложено выше.


0

Мы используем несколько подходов:

  1. Monit , прослушивать Elastic и Logstash порты и перезапускать их
  2. Для случаев, когда произошло что-то плохое, и все в порядке с точки зрения мониторинга, но журналы не используются / сохраняются, существует простой сценарий, который проверяет активный индекс каждый час и выдает предупреждения, если количество документов не изменилось за последний час.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.