Тезисы

Сначала несколько слов про предпосылки задачи.

1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна

2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.

3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.

Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;

Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.

Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.

* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.

Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk

Планирование требуемых ресурсов, (не-)линейность масштабирования.