Comments 8
Ох намучился я с этим fluentd. При передаче JSON логов по сети иногда возникали exception'ы. Пробовал отсылать одну и ту же строку лога, exception появлялся рандомно. Отдебажить так и не получилось, слишком много времени потратил лишь на debug. Logstash хоть и монструозный, но подобными проблемами не страдает. К тому же имеет нативный output в hdfs. Во fluentd же используется WebHDFS.
Еще существует проблема отказа коллектора логов, при условии, что логи требуется каждый час скидывать в s3. Если master упал в 10:55, то slave должен иметь все логи от 10:00 до 10:55 и отправить их ровно в 11:00 на s3.
Еще существует проблема отказа коллектора логов, при условии, что логи требуется каждый час скидывать в s3. Если master упал в 10:55, то slave должен иметь все логи от 10:00 до 10:55 и отправить их ровно в 11:00 на s3.
Всем хорош Scribe, простой и надежный. Для передачи логов на центральный сервер — самое то, там их уже можно обрабатывать специализированными инструментами. Жаль Facebook перестал его поддерживать и развивать.
Бывают конечно случаи, когда логов столько, что без распределенного хранилища (типа HDFS) не обойтись, но это будет скорее система аналитики, чем просто логгирования
Бывают конечно случаи, когда логов столько, что без распределенного хранилища (типа HDFS) не обойтись, но это будет скорее система аналитики, чем просто логгирования
Для администрирования лучше все решать стандартными средствами — типа rsyslog или syslog-ng. Первый так вообще чудо.
Но да, все зависит от конкретных потребностей.
Но да, все зависит от конкретных потребностей.
Андрей, спасибо за статью, но вот мне не совсем ясен принцип работы: Fluentd — это демон, запущенный где-то на ценральном сервере. Если с логами приложений более менее все ясно, используя некоторые клиентские библиотеки, я шлю соответствующее событие, то с системными логами непонятки: например, как мне собрать логи с 10 удаленных серверов? Мне нужен лог nginx access.log & error.log
Т.е. на каждом из серверов необходимо запустить какой-то агент сборщик, или логи забираются по ssh? Не хотелось бы устанавливать агента на сервера.
Т.е. на каждом из серверов необходимо запустить какой-то агент сборщик, или логи забираются по ssh? Не хотелось бы устанавливать агента на сервера.
Задача решается либо установкой fluent в качестве клиента, либо отправкой логов по tcp/udp средствами самого приложения. Например, nginx может слать логи в syslog over udp. Вам, конечно, целостность логов это не гарантирует, но и клиентов для сборки логов не надо будет ставить. Fluentd слушает на другом серваке по опубликованному порту. Профит. (ещё больший профит от использования logstash вместо fluentd)
Почему профит бОльший от использования logstash вместо fluentd?
Все так пишут, но никаких аргументов не выдвигают. Какой-то холивар вечный.
Все так пишут, но никаких аргументов не выдвигают. Какой-то холивар вечный.
У меня одного единственного из компании симпатию вызывает logstash вместо fluentd. Все остальные за fluentd, потому что в докере логдрайвер из коробки есть, кубернетес и вот это вот всё. А ещё регэксп, который надо всем уметь и знать по дефолту, вместо изучения онигурамы, которая хз где ещё пригодится девопсу.
Как по мне — если у тебя эластик стэк стоит, то какого черта делать выбор в пользу сторонних решений? Всё легче поддерживать в актуальном состоянии, у каждого компонента в стеке есть pressure control и xpack monitoring.
fluentd неплох, ничего не скажу, но logstash сильно изменился с тех времён когда был тяжеловесен, работал на java и ставился на каждый хост, тогда и filebeat не было. Сейчас всё иначе, но никто не хочет разбираться. Я наоборот по большей части сталкиваюсь с предпочтениями fluentd логсташу.
Sign up to leave a comment.
Сбор и анализ логов с Fluentd