Как стать автором
Обновить

Комментарии 20

Добрый день!
Технология довольно свежая, мы ее в сравнение не брали.
Спасибо за информацию, по возможности рассмотрим и такой вариант.

Локи немного другой. Если нужен анализ/поиск логов то ES проще чем регулярки и т.п. в Локи. Если логи отражают прежде всего метрики работы приложения, то Локи хорош.

Мы тоже долго выбирали между ELK и Graylog. Но почему то после того как запустили все на ELK использовать Graylog расхотелось. По вхождениям в graylog на момент тестов нельзя напрямую слать логи в elasticsearch, только через gelf (или то что в админке, udp syslog например).

По масштабированию с graylog тоже не так как с ELK - читал, пробовал - монго и какие то еще дополнительные телодвижения, бросил. Если есть elasticsearch, то пусть в чистом виде будет, есть kibana, которая подключается к elasticsearch, что еще надо. Когда возрастут нагрузки, рано или поздно поменяете решение.

В случае если потребуется масштабироваться — вы правы, ELK больше подходит. Но у нас сейчас такой задачи не стоит.
У нас основное — syslog и логи веб-серверов, пока это основной функционал, для которого Graylog достаточно. Да и elasticsearch в нем присутствует.
Что ELK что Grailog в плане масштабирования по факту одинаковы. Оба решения используют elastic для хранения. Имея опыт использования обоих решений в конфигурациях порядка 60к сообщений в секунду предпочитаю graylog. По ресурсам они по факту кушают практически одинаково, GELF в использовании на порядок проще чем регексы для ELK.
В graylog подкупает простота и всеядность коллектора логов. Хотя на вкус и цвет все фломастеры разные. )
По сравнению с ELK ресурсоемкость значительно ниже.

Логи же все равно хранятся в Elastic, то есть требуются те же ресурсы IMHO.
Если используется Logstash, то он сам не против занять много ресурсов, если ingest в ES — то основной удар по CPU, но без аггрегаций и прочих ML незаметно.
Logstash совсем не обязателен, так что я все-таки не могу понять как Greylog может быть «легче».
Пару лет назад я пробовал Graylog.
Помню тогда упёрся в то, что для Graylog уж как-то жутко неудобно настраивать отсылко логов с клиентских систем.

Например для ELK — я ставлю FileBeats & MetricBeats, несколько строчек в конфиге — и всё.

А для Graylog надо было разбираться с их хитрыми протоколоми, которые я тогда не осилил.

Планируется ли продолжение о том, как настраивать отсылку логов с клиентов?
Вообще, статья похоже на перевод «родной» инструкции по установке и имеет ценность, близкую к 0.
Касаемо вашего вопроса: даже версия 2, которая стояла у нас несколько лет, уже могла принимать почти любые форматы сообщений. Буквально только что перешел на 4-ю версию. У нее есть система управления агентами, которая работает с *Beat.
Добрый день!

Да, это как раз будут примеры использования во второй части, она выйдет совсем скоро)
Например для ELK — я ставлю FileBeats & MetricBeats, несколько строчек в конфиге — и всё.
А для Graylog надо было разбираться с их хитрыми протоколоми, которые я тогда не осилил.
Как простой вариант — засылать логи через filebeat, направив его на graylog с target=logstash, парочку лишних полей, которые требует logstash, можно почистить простеньким процессором в грейлоге, чтобы не мешались
Graylog умеет обрабатывать логи, в которых записи идут блоками?
Например:
18/01/2021 12:20:10 Начало операции А
18/01/2021 12:21:15 Переход к операции Б
18/01/2021 12:22:20 Завершение операции Б
18/01/2021 12:23:10 Аварийное завершение операции А
И, надо, например, подсчитать, сколько таких аварийных блоков в логе за день
Если вы имеете ввиду какой-либо способ обработки с сохранением состояния, то мне о таком неизвестно. Если же просто надо найти процент количества сообщений с «аварийным завершением» относительно сообщений о «начале операции», то это можно.

Да именно второе. Спасибо за информацию, надо будет попробовать.

Если вы имеете ввиду какой-либо способ обработки с сохранением состояния, то мне о таком неизвестно.

по идее возможно. Но там нюансы будут на каждом шагу
https://community.graylog.org/t/multiline-log-index/3550/7
https://github.com/Graylog2/graylog2-server/issues/2465
Но проще всего, конечно, это на стороне отправителя править, чем на стороне хранилки, каковой является грейлог

48 закладок и всего один плюс мой.

Как-то это дико странно. Получается статья зашла читателям Хабра, но не авторам Хабра. Хм… интересная статистика.
По сравнению с ELK ресурсоемкость значительно ниже.

как такое может быть, если в грейлоге под капотом ТОТ ЖЕ эластик, да еще и есть дополнительные компоненты? Я отказываюсь в это верить. Похоже на неподтвержденные практикой доводы. Я уж не говорю о том, что возможностей по оптимизации у ЕЛК даже больше, чем у грейлога… Просто это надо делать


Если не используем ipv6 — лучше отключить:

srsly? вообще-то IPv6 не так отключается


Еще я не понял, почему в разных сниппетах разная раскраска форматирования

Добрый день!

Ресурсоемкость проверяли на демо-стенде, под наши задачи Graylog показал себя менее ресурсоемким.
Тут стоит отталкиваться от объемов, уверен, в какой-то момент ELK может и должен проявить себя с лучшей стороны.

«возможностей по оптимизации у ЕЛК даже больше, чем у грейлога» — факт, обратного мы в статье и не утверждали.

По воросу ipv6 — не совсем корректно выразились, отключаем не ipv6, а входящие подключения на порты 546-547 (dhcp для IPv6)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.