Сила логов: зачем команда Яндекс 360 собирает терабайты логов в день
Привет! Я Вадим, руководитель команды бэкенда Телемоста — платформы для видеоконференций от Яндекс 360. В 2022 году я пришел в Яндекс 360 и удивился местному подходу к работе с логами: оказалось, что здесь их собирают в 100 раз больше, чем я привык.
Обычно компании так не делают, потому что хранить логи дорого, к логам предъявляются требования безопасности, которые не всегда просто выполнить, а разработчики не понимают, как их анализировать. Как следствие, руководство не видит выгоды от вложений в хранение и обработку логов. Но в Яндекс 360 умеют с этим работать, поэтому собирают терабайты каждый день — расскажу, зачем это делают.
Спойлер 1: Мы не работаем с ELK (Elasticsearch, Logstash, Kibana) — стек-стандартом для логирования. Дальше будут подробности о технологиях, которые используем.
Спойлер 2: Мы исключаем из логов любые данные пользователей (включая персональные), а также любые секреты.
Как устроен процесс работы с логами в Яндекс 360
Яндекс 360 обрабатывает четыре вида логов, которые составляют единую структуру:
Access log — все входящие в систему запросы, HTTP, GRPC.
Default log — дебажные сообщения и данные, необходимые для диагностики системы.
Request log — вызовы смежных систем. Это все исходящие из приложения запросы по всем протоколам (HTTP, AMQP, SQL и так далее).
Еrror log — ошибки.
Пишем логи при помощи трёх языков: Java/Kotlin, Go, Python. Единый формат лога — TSKV:
tskv tskv_format=ydisk-telemost-backend-default-log host=telemost.sas.yp-c.yandex.net name=telemost-backend.default appname=telemost-backend timestamp=3000-01-01 00:00:00,000 timezone=+0300 ycrid=telemost_api_broadcast-fae8b5726f7a294d0bf399234291a16b-wfty4wosfw73v37t request_id=telemostBroadcastHealthCheckCron_ordinary/30000101T210000.000Z level=INFO message=Performing broadcast healthcheck
Все логи связываем с помощью единого идентификатора YCRID — Yandex Cloud Request ID. Это позволяет нам строить трейсы по логам.
Пайплайн доставки логов выглядит так:
Logrotate — стандартная технология Linux, в которой ротируем логи
Agent — аналог Beats
Logbroker — аналог Kafka
Logfeller/Logshater — аналог Logstash
ClickHouse — аналитическая БД (аналог Elasticsearch)
YTsaurus — map-reduce (аналог Hadoop)
Хранение логов делим на две части:
В ClickHouse — оперативные логи за 24 часа
В YTsaurus — логи, разбитые по дням
Для чего мы ежедневно собираем так много логов
Вот несколько сценариев, как мы используем логи в Яндекс 360.
Решаем проблемы, которые возникают в приложении. Например, однажды у нас внезапно начало расти время запросов. Мы выбрали конкретные долгие запросы по access log и связали запросы c request log. Предположили, что причина кроется в базе данных, но там эти запросы отрабатывали быстро. Тогда начали изучать сеть — оказалось, проблема в ней. Наличие requests и access-логов на всех компонентах системы позволило легко локализовать место, где появляется задержка, и найти проблему с ретрансмитами пакетов по сети.
Как-то была разовая проблема в продакшене: мы видели её по жалобам пользователей и воспроизводили сами. Проверили все машины в кластере на наличие проблемы, но её не обнаружили. Тогда проанализировали логи. Выяснилось, что проблемы возникают на хосте, которого нет в дискавери нашего внутреннего облака. Благодаря данным из логов удалось оперативно найти хост, который уже не видело облако и на который невозможно было подключиться, и остановить его. SRE впоследствии подтвердили проблему в системе управления хостами внутреннего облака и устранили её.
Используем для предсказаний. В Телемосте, например, у нас медиасерверы stateful, и релизы вызывают переподключения у участников. У нас был вариант релизить ночью, когда мало нагрузки, или в рабочее время, но это сказывается либо на команде разработчиков, либо на пользователях. Найти решение удалось с помощью логов. Мы знаем, когда первый участник встречи подключается к медиасерверу и когда отключается последний. На основе этих данных построили график активности конференций и увидели, как они распределены в течение дня. Далее рассчитали оптимальное время и длительность релизов, чтобы минимизировать негативный эффект.
Делаем аналитику наглядной. Сами по себе массивы логов не представляют ценности для стейкхолдеров, поэтому все финальные данные мы визуализируем, а именно строим графики в Yandex DataLens — опенсорс BI-системе.
Yandex DataLens консолидирует данные из разных источников и создаёт интерактивные отчёты для бизнес-анализа. Исходный код опубликован на GitHub и предоставляется по открытой лицензии. Развернуть DataLens можно на любой инфраструктуре.
В результате логи помогают нам постоянно улучшать сервис. С их помощью мы анализируем качество соединения во время созвона и узнаём о проблемах каждого подключения: был ли стабильным интернет, зависало ли видео из-за загрузки CPU, какое разрешение было у камеры. В случае инцидента оцениваем его реальный масштаб — сколько пользователей пострадало.
Почему важно собирать логи и анализировать их даже в небольших IT-компаниях
Опыт не только Яндекс 360, но и других компаний и команд показывает, что логи могут стать активом. С их помощью можно вовремя обнаружить проблемы в работе продукта или инфраструктуры в целом, отследить расход ресурсов, проанализировать производительность, понять пользовательский опыт. При этом важно писать много логов, чтобы у вас было достаточно данных для анализа.
Убеждайте стейкхолдеров, что логи пригодятся, и объясняйте, зачем это нужно. Надеюсь, мои примеры вам в этом помогут. Систему логирования реально внедрить за 2–3 месяца, и для этого необязательно использовать стек ELK — можно взять другие open source решения.
