Comments 21
loki?
Мы тоже долго выбирали между ELK и Graylog. Но почему то после того как запустили все на ELK использовать Graylog расхотелось. По вхождениям в graylog на момент тестов нельзя напрямую слать логи в elasticsearch, только через gelf (или то что в админке, udp syslog например).
По масштабированию с graylog тоже не так как с ELK - читал, пробовал - монго и какие то еще дополнительные телодвижения, бросил. Если есть elasticsearch, то пусть в чистом виде будет, есть kibana, которая подключается к elasticsearch, что еще надо. Когда возрастут нагрузки, рано или поздно поменяете решение.
У нас основное — syslog и логи веб-серверов, пока это основной функционал, для которого Graylog достаточно. Да и elasticsearch в нем присутствует.
В graylog подкупает простота и всеядность коллектора логов. Хотя на вкус и цвет все фломастеры разные. )
По сравнению с ELK ресурсоемкость значительно ниже.
Логи же все равно хранятся в Elastic, то есть требуются те же ресурсы IMHO.
Помню тогда упёрся в то, что для Graylog уж как-то жутко неудобно настраивать отсылко логов с клиентских систем.
Например для ELK — я ставлю FileBeats & MetricBeats, несколько строчек в конфиге — и всё.
А для Graylog надо было разбираться с их хитрыми протоколоми, которые я тогда не осилил.
Планируется ли продолжение о том, как настраивать отсылку логов с клиентов?
Касаемо вашего вопроса: даже версия 2, которая стояла у нас несколько лет, уже могла принимать почти любые форматы сообщений. Буквально только что перешел на 4-ю версию. У нее есть система управления агентами, которая работает с *Beat.
Да, это как раз будут примеры использования во второй части, она выйдет совсем скоро)
Например для ELK — я ставлю FileBeats & MetricBeats, несколько строчек в конфиге — и всё.Как простой вариант — засылать логи через filebeat, направив его на graylog с
А для Graylog надо было разбираться с их хитрыми протоколоми, которые я тогда не осилил.
target=logstash, парочку лишних полей, которые требует logstash, можно почистить простеньким процессором в грейлоге, чтобы не мешались
Например:
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
Но проще всего, конечно, это на стороне отправителя править, чем на стороне хранилки, каковой является грейлог
Как-то это дико странно. Получается статья зашла читателям Хабра, но не авторам Хабра. Хм… интересная статистика.
По сравнению с ELK ресурсоемкость значительно ниже.
как такое может быть, если в грейлоге под капотом ТОТ ЖЕ эластик, да еще и есть дополнительные компоненты? Я отказываюсь в это верить. Похоже на неподтвержденные практикой доводы. Я уж не говорю о том, что возможностей по оптимизации у ЕЛК даже больше, чем у грейлога… Просто это надо делать
Если не используем ipv6 — лучше отключить:
srsly? вообще-то IPv6 не так отключается
Еще я не понял, почему в разных сниппетах разная раскраска форматирования
Ресурсоемкость проверяли на демо-стенде, под наши задачи Graylog показал себя менее ресурсоемким.
Тут стоит отталкиваться от объемов, уверен, в какой-то момент ELK может и должен проявить себя с лучшей стороны.
«возможностей по оптимизации у ЕЛК даже больше, чем у грейлога» — факт, обратного мы в статье и не утверждали.
По воросу ipv6 — не совсем корректно выразились, отключаем не ipv6, а входящие подключения на порты 546-547 (dhcp для IPv6)
Спасибо за статью. Давно подбирался, а Ваша статья - подтолкнула.
Мои опыты с Graylog тут:
Как мы работаем с логами (сбор, хранение, анализ при помощи Graylog)