Pull to refresh

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 протоколу.

Only those users with full accounts are able to leave comments. Log in, please.

Articles