5 причин, которые заставят тебя использовать Kibana

[sedyh]

Функционал KQL и Lucene довольно беден для поиска чего-либо сложнее пары подстрок. Искать вложенные объекты очень неудобно, а регулярки сделаны кое-как и к ним нужно привыкать.

[BugM]

Проблема grep -C 5 за адекватное время уже решена?

Эта проблема обычно оказывается нерешаемой для 95% систем работы с логами.

[lair]

Во многих компаниях для сбора и анализа логов используют такой инструмент как Kibana.

… действительно, какая разница, что Kibana логи собирать не умеет.

[Ritan]

Разве это когда-то кого-либо останавливало?

[KGeist]

Наверное, имеется в виду, что Kibana визуализирует логи, а не собирает.

[amarao]

Кибана — это вершина извращения идеи "просмотра логов".

Когда вы смотрите логи, есть три режима:

• Поиск
• Вертикальное чтение
• Горизонтальное вычитывание.

И все три в кибане реализованы так, что хочется плакать.

Поиск: попытка что-то найти по uuid'у обречена, потому что дефисики у люсида — это что-то другое, а не дефисики. Мне насрать на люсид, но невозможность искать по uuid'у (guid'у и т.д.) — это эпический провал эластика как системы обработки логов. И кибана этому не способствует. Попытка искать по тегу в "выборке" не работает в продакшене, потому что top 500 сообщений с большой вероятностью от шумных генераторов, и все важные сообщения (которые, например, 1 на 10000) вы не найдёте в автовыборке top для полей. Даже если в top три значения осталось (хотя могло бы быть 5).

Вертикальное чтение (листать) убито полностью. Пара тысяч сообщений на странице и мой браузер жрёт больше ресурсов, чем ферма серверов, чьи логи я пытаюсь читать.

Горизонтальное чтение (вычитывание строчки) так же сделано максимально неудобным — контекст постоянно меняется, и простое "слева даты справа текст" не работает. Надо парсить поля в могзу, пытаясь понять где тут ещё кибана, а где сообщение от софта. Особенно этому мешают автогенерённые поля (тут претензия к логстэшу, да).

В целом, продукт напоминает результат программирования business requirement командой программистов, которые готовым продуктом не пользуются.

У него могут быть очень ограниченные применения, но как продвинутая система работы с логами она проигрывает консоли (даже без всяких красот, просто less/grep) по всем параметрам.

[lavilav]

Datadog - хорошая альтернатива, если не сильно много логов. Нет требований к размещению сервера внутри периметра.

[amarao]

Отдавать свои логи чужому человеку? В проприетарный код?

Прям мега-предложение. Особенно, на фоне loki.

[lavilav]

можно подумать, что хостить у хостера (чужого человека) намного лучше.

>>Особенно, на фоне loki.
он ок для простых свистоперделок, не более.

[amarao]

А вот расскажите про не-проприетарные варианты. graylog?

[lavilav]

Elk/opendistro, graylog, loki, fluentd.

с ui везде вопросы. Взять тот же Loki, инструмент визуализации метрик - grafana.

Часто нужна сложная аналитика паттернов, которыми хвалятся проприетарные и даже elk

[amarao]

На самом деле, всякая "сложная аналитика" — это уже следующий уровень.

Нулевой уровень — собрать все логи и не сдохнуть.
Первый уровень — дать эргономику не хуже grep/tail -f/less.
Второй уровень — уметь фильтровать, теги, etc.

Вот я не знаю реально боевого решения, которое хотя бы первый уровень прошло целиком. Все целятся в более благородные цели, но шатаются как раз основы. (условно — тот же ELK в районе 'L' начинает злобно дропать всё на 3k msg/s. Возможно, на новых процессорах ближе к 5-6к, но всё равно сильно меньше того, что условный journald выдерживает в один поток (30к)).