Comments 7
У kibana самый античеловеческий интерфейс, который я когда-либо видел. Лучший метод унизить админа - заставить его чинить сервер по мотивам логов в elk'е.
Почему? Для админа вполне естественно читать сырые логи на этих серверах. Кибана практически в сыром виде эти логи и выводит, добавляя лишь к этому свой синтаксис запросов. Выглядит не так модно, как графана например, но, по сути, все оно одно и тоже. Грейлог и тем более монк выше чистая копипаста с кибаны. А другого я ничего и не видел. Платными решениями не приходилось пользоваться.
Кибана практически в сыром виде эти логи и выводит
В ES очень много подводных камней не очевидных даже опытному админу, если он не спец по ES. Это может выстрелить в любой момент - просто не увидишь нужную критичную запись из за особенностей поискового запроса / настроек анализатора.
Выводит то может и похоже, хотя тут тоже спорный момент - настроили или нет корректное разбиение на записи обрабатываемого логфайла при заливке большой вопрос, и чаще ответ будет нет, чем да. Graylog тут чуть лучше смотрится, так как у него хотя бы есть нормальный log-ориентированный протокол.
На любых хоть сколько-нибудь значимых объемах эластик это очень дорого. Стоит ли платить за его мощь как распределенного поискового движка - зависит от случая. Среднестатистический админ профита получит с гулькин нос, а боли - достаточно.
Вообще, кажется что лучше и удобнее чем grep по файлам пока не придумали ничего, но даже таким инструментом не каждый админ умеет нормально пользоваться.
Локи имеет право на жизнь.
Ну да. Я писал с позиции, что сбор логов настроен нормально и в систему попадает все как надо. Тут конечно можно накосячить сильно. Проще просто не увлекаться с попытками парсить логи, а тупо лить как есть и опираться на индексы эластика, чтобы в них найти нужное.
Про ненужность эластика для такой простой задачи как логи я тоже постепенно прихожу и неоднократно видел блог посты других с подобным мнением. Даже простейшая конфигурация требует дохера ресурсов и взамен дает инструмент, возможности которого используются на жалкие доли процента. А разбираться с его индексами, шардами и настраивать ротейт адекватный это то еще удовольствие.
Локи хорош тем, что с этой позиции его похоже и сделали. Для логов достаточно грепа, а локи это централизованный и параллельный греп, по сути.
Мне эту сказку рассказывали несколько раз, пытаясь пересадить на кибану. Один раз я даже коммитнулся разбираться.
Знаете, что делает админ, когда находит "странную строчку", которая, вроде бы подозрительная, но не понятная? Листает вокруг неё вверх и вниз. PgUp/PgDn на консоли работает со скоростью примерно 1500 строк в секунду (pgUp + repeat), ограниченной скоростью терминала и ssh на сервер.
Знаете, сколько времени нужно в кибане, чтобы пролистать на 2000 сообщений назад от "интересной строчки"? 4 раза по 500 строк, каждая следующая группа грузится с o(n) от предыдущей. В 2017 году я один раз загрузил от отчаяния в kibana примерно 20000 сообщений таким образом за примерно пол-часа (других логов не было, а проблему решать надо было). На 25ой тысяче мне OOM снёс браузер на машине с 16Гб памяти (тогда это было вполне много).
После чего я пошёл и дампнул все логи из эластика за этот день и комбинацией grep'а и less'а нашёл первоисточник странного в примерно 300 экранах от подозрительной строчки за несколько минут.
Админы умеют быстро читать логи (обнаруживать визуальные узоры трейсов разных языков программирования). Нужный мне питоновый трейс я нашёл почти мгновенно. Никаких подозрительных атрибутов у сообщения не было - это был stdout от вызванной утилиты, которая вернула rc 0, так что serverity было INFO.
Так что нет, кибана для админов - это как консервный нож для хирургов. Теоретически, похож на скальпель, на практике не применим.
А, да, главное, она по uuid'ам искать не умеет без спецвыкрутасов.
Недавно как раз задеплоил локи и пока все нравится, но и не было пока случаев, когда надо прямо сильно копаться в логах. ELK помню помогал в этом плане, когда тупо отсеивали по одному сообщению мусор и докапывались до истины. При этом все это делалось за считанные миллисекунды.
Но зато в плане простоты и легковесности нет равных. Читая документацию по архитектуре, выглядит это все жутко наворочено, но если ограничиться монолитными вариантом деплоя и начать с конфига из примеров, то вся система простая как пробка. Сейчас переваривает логи с 4 хостов и загрузка CPU до процента не доходит даже. Память тоже несколько сотен мегов.
Единственное надо быть очень осторожным с лейблами. Каждая комбинация лейблов это отдельный "memory stream" в памяти локи и отдельные файлы на диске для каждого чанка. Очень быстро может оказаться, что в памяти миллион стримов, а не диске все десятки и сотни. И если руками заданные лейблы ты естественно контролируешь сам, то динамические могут легко выйти из под контроля. Например, если логи прилетают извне по syslog протоколу.
На каких бесплатных инструментах строить Observability и зонтичный мониторинг: ELK vs Graylog vs Grafana Loki vs Monq