Как мы делаем трейсинг в условиях тысяч сервисов и миллионов спанов в секунду / Игорь Балюк (Авито)
Вставка
- Опубліковано 3 лип 2024
- МТС - генеральный партнёр конференции Saint HighLoad++ 2024.
________
. Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Highload++ 2023
Презентация и тезисы:
highload.ru/moscow/2023/abstr...
Поговорим о трейсинге в Авито: какую он задачу решает, и как у нас выглядит архитектура трейсинга, обрабатывающая миллионы спанов в секунду от нескольких тысяч сервисов, объединенных в service mesh (который, как оказалось, помогает).
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Образцовый доклад, просто идеальный текст и визуализация, браво
Не покидает чувство, что произошла инфляция уровня докладов на HL. Ну т.е. образцовые доклады в моем понимании - это продакшен от Аксенова, Зайцева, Осипова, Столярова, etc.. Тут самый обычный доклад middle уровня, который хорошо подходит для внутреннего митапа на час в управлении на 20 человек в какую-нибудь среду после закрытия спринта.
@@denisbalyasnikov7185 доклады уровня синьер-лид не имеют смысла. Там будет что-то типа "Мы раскопали, что тормозит индекс. Переписали его с Java на Го командой из 3х человек. Всё стало быстрее. Пока." Синьер отличается от мидла тем, что сделает это один за 3 дня. А не потупить и бросит через месяц. Задачи везде одинаковые. Просто уровень мидла это присобачить апишку или прокинуть трейс. А синьера - переколбасить 50 алгосов из головы и спасти деньги бизнеса.
Один из лучших докладов на моей памяти!
Отличный доклад. Не раскрыто только желание заопенсорсить коллекторы и UI :)
Отличный уровень глубины повествования, мне было понятно, хотя совсем не моя зона экспертизы
observability = logging, tracing, metrics
Отличный доклад
огонь! Хочу в Авито!
Хороший доклад, спасибо!
Ха! я теперь понял, что чуваки которые сидят всю ночь за компом, это не просто чуваки которыми нечем заняться, а это никто иные, как инцидент-менеджеры!!! Они наблюдают ночь за миром и в случаи возникновении аварии, проблемы или просто непонятной ситуации находят подходящих экспертов! Ну а про экспертов, вы знаете!
Отличный доклад!
Доклад хороший, только зумеры ничего не придумали и трейсинг к ним никакого отношения не имеет
Нам нравится Кликхаус, он крутой.
Перед Кликхаусом у нас есть Кафка, так как Кликхаус плохо работает на запись... Мы пишем в нево большими пачками и редко...
Ну как бы это особенность колоночных БД. Они только чтение больших данных ускоряют.
когда не чукча даже не читал мануал, но осуждает
Почему б не хранить трейсы в чем-то специализированном для этого типа данных?
24:50 - что на практике означает "синхронизировать count min sketch между всеми коллекторами"?
Считать вероятность относительно всех коллекторов, а не внутри каждого отдельно?
В комментариях уже дали правильный ответ, немного раскрою его.
В нашем случае шардирование происходит только по Trace ID.
Мы бы хотели выставить гибкое условие вида "сохранять все трейсы, где есть редкие спаны", где "редким" будем считать спан, который встречался меньше N раз за час, с точностью до имени сервиса и имени операции. Но трейсы с такими спанами могут агрегироваться на разных коллекторах. Коллекторы должны как-то синхронизировать свои счетчики между собой, чтобы мы понимали, как много таких спанов было сгенерировано за последний час.
В итоге пришли к следующей схеме. Разобьем временную прямую на некоторое блоки фиксированного размера в T минут. Коллектор поддерживает локальное состояние count-min-sketch счетчиков за последний период, на основании данных, которые проходят через этот коллектор. По завершению периода коллектор сохраняет свое состояние в отдельное общее хранилище и обнуляет счетчики. Также коллектор постоянно вычитывает состояние других коллекторов за уже прошедшие периоды и агрегирует их у себя в памяти. Таким образом у коллектора есть информация по локальным счетчикам за самый актуальный период и сумма счетчиков по всем коллекторам за уже прошедшие периоды.
Решение о семплировании принимается исходя из данных за самый актуальный период и за несколько предыдущих периодов. Важно, чтобы правила семплирования имели период больше, чем период синхронизации T.
Пути
Не путю
написали клон sentry
Все APM инструменты в чем-то похожи друг на друга. Но мы в первую очередь целились в полноценные платформы, такие как DataDog, honeycomb и т. д. Всех их объединяет то, что они из одного места предоставляют доступ сразу к многим видам данных, и то, что они как правило платные :)
Self-hosted версия Sentry у нас тоже есть, и неплохо справляется со своей основной задачей: принимать ошибки от приложений (или веба), показывать стектрейсы ошибки, группировать их и отправлять алерты.
В Sentry действительно появился механизм работы с трейсингом, однако сам UI не предоставляет тех переходов, которые мы бы хотели видеть, и есть подозрение, что будут проблемы с обработкой того объёма данных, которые у нас есть (мы не пробовали, но опираемся на предыдущий опыт использования sentry). Поэтому на данный момент Sentry у нас используется только по прямому назначению.
инцидент-инженеры у вас по сути являются SRE инженерами?
Человечество придумало довольно много определений SRE-инженерам :) Но в Авито это разные роли.
В Авито SRE-инженеры в первую очередь занимаются разработкой и эксплуатацией решений, влияющих на стабильность системы. Например, они могут заниматься быстрым развертыванием Kubernetes кластеров, их настройкой и организацией автоматического наблюдения за ними (и автоматического выведения деградирующих k8s узлов).
Инцидент-менеджеры организуют постоянное (24/7) наблюдение за production средой. Если по метрикам (или по другим признакам) заметно, что что-то перестало работать, инцидент-менеджер занимается процессом устранения деградации: определяет зону ответственности, находит и призывает ответственных разработчиков, помогает им найти root cause и ведет лог инцидента для последующего разбора.
@@igor.baliuk
Root cause по-русски это первопричина
Простыми словами (itil) это техподдержка L1, L2, L3. Просто немодно, немолодёжно
Надеюсь это только пример, что на каждый чих людей надо будить
Доклад про то, как сначала создать себе проблем микросервисами, а затем пытаться их решить ресурсами.
Да, могли ж просто монолит на пхп забабахать, чтоб он один мильоны рпс вывозил, и на одном мощном серваке его развернуть, не заниматься ерундой
@@artembass9535 кто тебе сказал, что монолит не масштабируется? Джун детектед.
Без пути героя нечего было бы докладывать)
@@namegormну удачи помасштабировать свой монолит, может быть в твоем залупа-софте с 10ю клиентами и 3мя разрабами это не вызовет проблем
и да, трейсы нужны не только в микросервисной архитектуре, в твоем любимом монолите они тоже будут очень полезны, стажер детектед
Рут коз 🫠
Root cause, root cause...😢 Первопричина
Не стоит доклад про логи на конфе вещать. В Авито до сих пор по номеру телефона авторизуют... Так себе сервис. Похоже на рекламу больше, чем доклад