У меня есть папка в которой хранится большое количетсов фалйов (минимум 300 тысяч).
Для этих файлов я сделал отдельный модуль, все записи через этот модуль отправляются на прямую в elastic.
Если запустить файлбит первый раз, или удалить registry, то всё работает. Но если перезапустить файлбит, перезапустить хост, или был случай когда там оперативка закончилась, файлбит перестаёт отправлять что-либо, полностью игнорирует новые записи итп.
Так же при повторной попытке переазапустить сепрвис пишет:
filebeat.service: State 'stop-sigterm' timed out. Killing.
25 09:38:16 bisArch systemd[1]: filebeat.service: Main process exited, code=killed, status=9/KILL
Если ничего не делать, то спустя какой-то случайное время от 8 до 10 часов, всё начинает работать снова, в логах при этом никаких ошибок нет, ни в syslog, ни в filebeat.
filebeat 7.3.2, ubuntu 16.04.
Может быть есть какие-то идеи в чём может быть проблема?
здраствуйте! расскажите пожалуйста подробнее, что подразумевается под "работает" в данном случае? после запуска filebeat, что происходит с файлами в директории, что вы ожидаете от filebeat? Например, эти файлы - это логи, или статические файлы? новые файлы появляются в директории, и ожидается что filebeat их "увидит" и проиндексирует?
Также, можно посмотреть еще несколько вещей - вне зависимости от того, что происходит с файлами:
journalctl -r filebeat.service
strace -vttf -p filebeat process pid во время этих 8 часов, когда "не работает"; или увеличить log level до debug у filebeat, что дает значительно больше информации в логах
что происходит с процессом filebeat в эти 8 часов - использует ли CPU, например 50-100-200%? память?
судя по логам, filebeat настроен отсылать мониторинговую информацию в elasticsearch - попробуйте посмотреть в kibana для кластера, куда отсылается мониторинговая инофрмация, на состояние filebeat в течении этих 8 часов
проверьте, что происходит с elasticsearch в эти 8 часов
4 раза в час появляются новые файлы, думаю что реже строчки в самих файлах, lftp работает.
пока я не делаю рестарт сервиса, filebeat видит новые файлы, и отправляет информацию. http://prntscr.com/paznvb - вот график работы.
процессор и память - ничего необычного.
в кибане я не вижу состояние файлбита, или не понял где смотреть, остальное с утра добавлю.
пока я не делаю рестарт сервиса, filebeat видит новые файлы, и отправляет информацию.
Тогда еще стоит глянуть на systemctl status filebeat.service, до и после рестарта. И проверить, сколько процессов filebeat запущено в системе до и после рестарта, и перезапускается ли процесс вообще. Ну и посмотреть, что происходит в логе с level=DEBUG во время [попытки] перезапуска. и systemctl cat filebeat.service.
Опять же, теория/догадка, но судя по ошибке
filebeat.service: State 'stop-sigterm' timed out. Killing.
и тому, что там 300к файлов, возможно sigkill прерывает запись registry и после перезапуска новый filebeat процесс как-то странно себя ведет из-за не совсем "здорового" registry. Systemd документация, вроде как, говорит что по-умолчанию systemd будет ждать 90 секунд после sigterm перед тем, как посылать sigkill. Гипотетически, это очень долго. Поэтому либо systemd делает что-то не то, либо filebeat действительно нужно больше времени...
Да, где-то 90 секунд и приходится ждать, НО, это если второй раз рестартить, первый раз когда всё работает рестарт происходит быстро, т.е. если запись и прерывается то это ненормальное поведение, там никакого sigkill'а нет.
Pastebin с логами filebeat и статусами из systemd - это после первого рестарта, или после второго? в логе filebeat видно sigterm/sigkill в районе "Sep 26 20:21:41" - это первый или второй рестарт? после второго рестарта все так же, один filebeat процесс в системе ("ps uax | grep filebeat| grep -v grep") и его PID совпадает с systemd? ничего - например, configuration management system - не меняет файлы конфигурации filebeat?
выглядит странно, потому как командная строка для filebeat не меняется (судя по systemd status), значит используются те же пути к файлам конфигурации. ну и к Kibana/Elasticsearch подключается. почему тогда 0 inputs после sigterm/sigkill?
все логи после 2го и последующего.
не знаю почему он пишет 0, но в data.json у него 48 метров файлов чего-то, я так понимаю если бы инпут был реально 0, там было ты тоже 0?
процентов на 99 уверен что если вот сейчас rm по /var/lib/filebeat/registry/filebeat то у меня через 10 минут файлбит начнёт файлы в еластик отправлять, и после рестарта опять перестанет это делать.
data.json - это registry. просто статус. inputs:0 - это, как я понимаю, к такому выводу приходит filebeat после чтения конфигурации. я бы попробовал запустить с DEBUG "с нуля" - например, после удаления файлов. и посмотреть, что пишет log на тему inputs изначально, после первого рестарта и после второго рестарта.
проблема с удалением регистра в том, что это вообще не должно быть нужно, и заставляет filebeat переиндексировать все файлы во всех inputs, т.е. если какие-то данные из файлов уже в ES - filebeat их запишет заново. к тому же, исходя из логов, data.json filebeat как раз без проблем читает.
именно поэтому я и решил тему начать, потому что действительно заново запишет в ес данные, и потому что процесс повторяется, если первые два раза можно было списать на непонятные какие-то случаи, то когда 3й раз картина 1 в 1 повторилась...
завтра дебаг попробую сделать после удаления регистра.
Отлично, попробуйте. Если проблема действительно в filebeat, желательно установить очень точный список действий для ее воспроизведения, и собрать как можно больше DEBUG логов и вывода strace после воспроизведения проблемы. Открыть issue с filebeat, или даже поглядеть в код - не проблема, но информации пока не густо. И, соответственно, сложно будет получить решение, окончательное или временное.
ну в общем как и ожижал, после удаление регистра всё заработало, в конфиге только лог на дебаг поменял
я предполагаю что по достижении какого-то размера самого data.json файлбит начинает некорректно работать, но опять же, у меня только после перезапуска. https://pastebin.com/8K0xa7ie - после перезапуска, файлбит отсылает данные
https://pastebin.com/1qyD1BaN - момент перезапуска и файлбит больше не отправляет данные, размер data.json всего 3.5 мегабайта.
хотя после перезапуска не видно что бы появлялись строчки откуда файлы должны читаться, какой ingest будет использоваться, хотя они есть при первоначальном запуске.
хотя возможно я накосячил когда модуль правил, но в любом случае не могу понять даже примерно куда смотреть.
нет никаких ошибок которые бы хотя бы направление указали что-ли.
К сожалению, не вижу причин проблемы Судя по логам, filebeat загружает registry и начинает обрабатывать events после второго перезапуска. Почему они не появляются в Elasticsearch - загадка. Я подозреваю, что отсутствие записей о elasticsearch client и crawler в логе после второго перезапуска - это нормально. Постараюсь поглядеть код или пообщаться с разработчиками.
судя по логам, ничего пока не подтверждает данную теорию.
да же по логам не видно что бы файлбит начал данные отправлять, когда он работает появляются строчки вроде
Sep 27 14:46:20 bisArch filebeat[2192]: 2019-09-27T14:46:20.288+0300#011INFO#011log/harvester.go:253#011Harvester started for file: //bis/PATH/cut_20190925_050827_008362.txt
а когда не работает их просто нет, при чём нет ни в дебаге, не в инфо, может быть он при повторном запуске все файлы которые уже записал в регистр проверяет? Но судя по времени делает это даже дольше чем если бы просто их передавал с нуля в эластик, а на большом количестве файлов время слишком много тратит, я просто не успеваю дождаться.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
Судя по логам, filebeat загружает registry и начинает обрабатывать events после второго перезапуска. Почему они не появляются в Elasticsearch - загадка. Я подозреваю, что отсутствие записей о elasticsearch client и crawler в логе после второго перезапуска - это нормально. Постараюсь поглядеть код или пообщаться с разработчиками.