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

1. ELK: менеджмент логов, быстрая
локализация проблем
Сергей Шумов

2. Что такое ELK?
Я собираю
логи
А я их храню, ищу по
ним и ещё аналитика
Я их визуализирую!

3. Проблемы
• Быстрый поиск по логам
• Быстрая аналитика по логам
• Всё это по нескольким сервисам
• …в 3 часа ночи и очень срочно

4. Олд скул
• Log, Rotate, Archive
• Поиск с помощью grep
• "Аналитика" с помощью:
zcat | cut | sort | uniq -c | sort -nr

5. Олд скул
• Плюсы
+ Надёжно
+ Просто реализовать
+ Не требует ресурсов
• Минусы
– Grep магия для фильтрации
– Нельзя делать сложные агрегации
– Если софт не помещаются на 1 сервер то всё плохо

6. Сборка логов в файлы

7. Какие проблемы?
• Порядок записей событий
• Трудно считать кросс-сервисную аналитику
• Больше файлов – дольше обработка

8. Скриптоводство

9. Структурированный лог
• Формат
• Описывает сам свою структуру
• Расширяемый
• Легко формируется и парсится
• Человекочитаем
• Содержимое
• Контекст
• Атрибуты вместо строк

10. {"JSON": "наш выбор!"}
• Описывает сам свою структуру
• Расширяемый
• Есть библиотеки под все языки
• Человекочитаем

11. ElasticSearch (ES)

12. ES: Ротация логов
• Индексы по дням
• Поиск по множеству индексов
• Удаление множества индексов
• Перемещение индексов между узлами

14. Kibana: Агрегации
Настройки
агрегации
Результаты

15. Kibana: Поиск
• Полнотекстовый поиск
• Поиск по атрибутам
• Lucene queries
• Быстрый просмотр значений

16. Kibana: Кросс-сервисный поиск
• Способы организации:
✓ Индекс на каждый сервис
X Всё в одном индексе
logs-crawler-2016.11.07
logs-2016.11.07

17. Kibana: Просмотр сессии пользователя
Фильтруем
события
Смотрим
хронологию

18. Kibana: Выявление
аномальных пользователей
Настраиваем
агрегации
Убираем
мусор
Смотрим
результаты

19. Kibana: Исследование всплесков

20. Kibana: Исследование всплесков
Смотрим
события

21. Kibana: Dashboard
«Недовольные
пользователи»
Время ответа
Балансировка

22. Как и что логировать
• «Session ID»
• Трекинг событий
• Простые агрегации
• Полный контекст
• Сложный агрегации
{
"article_id": 42,
"session_id": "0cx31f",
"ref_article_id": 17
}

23. ELK или EFK?
Logstash
TCP => File:
• 5 000 записей/сек
• ~105% CPU
• 230 MB RAM
TCP => File:
• 11 546 записей/сек
• ~80% CPU
• ~60 MB RAM

24. Logging pipeline

25. Альтернативы
• Локальный сборщик логов (LogWatch)
• LaaS (Splunk)

26. Потребление ресурсов
Cores RAM DISK
20-50 млн/сутки 10-25 4-10 ГБ
30 ГБ SSD за 3 суток
300 ГБ HDD за месяц

27. Вопросы? :)