LINUX.ORG.RU
Форум — Admin  

Fluentd сбор log-ов tail

 


0

1

Ребят не подскажите в чем беда, сам не могу разобраться. Я мониторю определённый log файл Fluentd с помощью плагина tail, а после результат отправляю в Elasticsearch. И всё работает, кроме одной беды. При появлении в log файле новой строки, передаётся в Elasticsearch не последняя строка log-а, а весь log файл целиком.

Например. В log файле 5 записей. В Elasticsearch передалось 5 записей. В log файле появляется новая, шестая запись, в Elasticsearch передаётся не последняя шестая запись, а целиком, все шесть записей. В итоге в Elasticsearch будет не шесть записей, а одиннадцать. Старые записи в Elasticsearch будут по 2 раза. Если добавится ещё одна строка в log файл, то снова Fluentd передаст весь log файл.

Может кто знает, как заставить Fluentd передавать только последнюю строку log-а.



Последнее исправление: Andrei_IW (всего исправлений: 1)
← centos 8: point-to-point адрес для ethernet
Bareos и права на файлы архивов →
Ответ на: комментарий от Andrei_IW

Смотрел содержимое файла /var/log/td-agent/my-log.pos, там какие то цифорки. Так вот при добавлении новой записи в log эти самые цифорки меняются.

Andrei_IW
() автор топика
Ответ на: комментарий от Andrei_IW

Заметил так же, что если зайти в файл log-а, не чего не добавлять, не изменять, просто сохранить его, то в elasticsearch улетит всё содержимое log файла. То есть получается что tail во fluentd не следит за посленими изменениями в файле, а следит за изменением даты редактирования. Как только она изменилась, то весь log (всё содержимое) отправляется в elasticsearch.

Andrei_IW
() автор топика
Ответ на: комментарий от Andrei_IW

Удалось решить проблему. Дело оказалось в том, что строчки в log файл я добавлял с помощью vim. И толи так vim работает, то ли ещё что, в общем после сохранения log-а в vim Fluentd передавал весь log целиком. А когда я сделал добавление строки в log с помощью приложения, то fluentd стал отправлять как и полагается, только самую последнюю строку.

Andrei_IW
() автор топика
Ответ на: комментарий от Andrei_IW

По идее, это должно работать так:
Мы берем лог и отправляем его, запоминаем хеш и номер последней прочитанной строки в другой файл (pos). Когда файл изменился, либо когда пришло время, мы сверяем хеш того что написано до запомненной строки, если хеш совпал - значит файл тот и мы просто берем все, что написано ПОСЛЕ запомненной строки. А если не совпал, значит это совершенно новый файл и его надо отправить целиком.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

зачем так сложно? открываешь файл на чтение,передаешь,потом в цикле read,если мы в конце файла и ничего не появилось-получим eof,если что-то есть-читаем и передаем. обрабатываем eof

anonymous
()
Ответ на: комментарий от anonymous

Ради консистентности, чтобы можно было пережить штатную или нештатную остановку сервиса, например. Иначе на каждом рестарте если у тебя там лог в пару сотен гигабайт - он будет улетать в целиком.

slowpony ★★★★★
()
Ответ на: комментарий от anonymous

Можно упростить и сверять хеш только от последней прочитанной строки и ее номер. Наверное, должно хватить для покрытия большинства ситуаций.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

можно просто запомнить последнюю позицию в файле для дескриптора

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← centos 8: point-to-point адрес для ethernet
Admin
Bareos и права на файлы архивов →