Сначала несколько слов про предпосылки задачи. 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 Планирование требуемых ресурсов, (не-)линейность масштабирования.