Рейтинг@Mail.ru
HighLoad++ 2016 завершён. До встречи в 2017!

Профессиональная конференция разработчиков высоконагруженных систем

Москва, СКОЛКОВО,
7 и 8 ноября
Архив
2015
года
Конференция прошла в этом году уже в десятый раз и собрала 2500 участников. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

ELK: менеджмент логов, быстрая локализация проблем
DevOps и эксплуатация

Доклад принят в Программу конференции
News360

Возглавляет команду backend разработчиков в News360. Разработал приложение для графовых операций на большом объёме данных (сотни миллионов узлов, десятки миллиардов рёбер) в Сбербанк-Технологии.
Разработал и внедрил систему сбора и обработки данных из социальных сетей в компании Инфорион. В проекте использовались Apache Spark, Apache Kafka и ElasticSearch. Ключевыми особенностями системы является высокая нагруженность подсистемы сбора и аналитики. Объём данных: терабайты в месяц.

Тезисы

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

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

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

Логирование и мониторинг

Другие доклады секции
DevOps и эксплуатация

Бронирование билетов
Вы можете забронировать себе билеты уже сейчас — чем раньше Вы это сделаете, тем лучше, ведь цена на билеты постоянно растёт. Бронь вас ни к чему не обязывает, после бронирования у Вас будет пара недель на принятие решения об оплате.
ЗАБРОНИРОВАТЬ БИЛЕТЫ
Остались вопросы?
Спроси по телефону у контактного центра: +7 (495) 646-0768
Или напиши письмо в службу поддержки: support@ontico.ru
Rambler's Top100