Как мы делаем трейсинг в условиях тысяч сервисов и миллионов спанов в секунду / Игорь Балюк (Авито)
HTML-код
- Опубликовано: 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 алгосов из головы и спасти деньги бизнеса.
Один из лучших докладов на моей памяти!
Отличный уровень глубины повествования, мне было понятно, хотя совсем не моя зона экспертизы
observability = logging, tracing, metrics
Отличный доклад
Хороший доклад, спасибо!
Ха! я теперь понял, что чуваки которые сидят всю ночь за компом, это не просто чуваки которыми нечем заняться, а это никто иные, как инцидент-менеджеры!!! Они наблюдают ночь за миром и в случаи возникновении аварии, проблемы или просто непонятной ситуации находят подходящих экспертов! Ну а про экспертов, вы знаете!
огонь! Хочу в Авито!
Отличный доклад!
Интересный доклад, спасибо. Только нет action items 99% программистов и компаний. Мы уже на elk+zipkin+prometheus и хотим брать open source решения и не изобретать всё самим.
Отличный доклад. Не раскрыто только желание заопенсорсить коллекторы и UI :)
Доклад хороший, только зумеры ничего не придумали и трейсинг к ним никакого отношения не имеет
Сайдкар, который прокси - уже не сайдкар)
Нам нравится Кликхаус, он крутой.
Перед Кликхаусом у нас есть Кафка, так как Кликхаус плохо работает на запись... Мы пишем в нево большими пачками и редко...
Ну как бы это особенность колоночных БД. Они только чтение больших данных ускоряют.
когда не чукча даже не читал мануал, но осуждает
Почему б не хранить трейсы в чем-то специализированном для этого типа данных?
24:50 - что на практике означает "синхронизировать count min sketch между всеми коллекторами"?
Считать вероятность относительно всех коллекторов, а не внутри каждого отдельно?
В комментариях уже дали правильный ответ, немного раскрою его.
В нашем случае шардирование происходит только по Trace ID.
Мы бы хотели выставить гибкое условие вида "сохранять все трейсы, где есть редкие спаны", где "редким" будем считать спан, который встречался меньше N раз за час, с точностью до имени сервиса и имени операции. Но трейсы с такими спанами могут агрегироваться на разных коллекторах. Коллекторы должны как-то синхронизировать свои счетчики между собой, чтобы мы понимали, как много таких спанов было сгенерировано за последний час.
В итоге пришли к следующей схеме. Разобьем временную прямую на некоторое блоки фиксированного размера в T минут. Коллектор поддерживает локальное состояние count-min-sketch счетчиков за последний период, на основании данных, которые проходят через этот коллектор. По завершению периода коллектор сохраняет свое состояние в отдельное общее хранилище и обнуляет счетчики. Также коллектор постоянно вычитывает состояние других коллекторов за уже прошедшие периоды и агрегирует их у себя в памяти. Таким образом у коллектора есть информация по локальным счетчикам за самый актуальный период и сумма счетчиков по всем коллекторам за уже прошедшие периоды.
Решение о семплировании принимается исходя из данных за самый актуальный период и за несколько предыдущих периодов. Важно, чтобы правила семплирования имели период больше, чем период синхронизации T.
Пути
Не путю
написали клон sentry
Все APM инструменты в чем-то похожи друг на друга. Но мы в первую очередь целились в полноценные платформы, такие как DataDog, honeycomb и т. д. Всех их объединяет то, что они из одного места предоставляют доступ сразу к многим видам данных, и то, что они как правило платные :)
Self-hosted версия Sentry у нас тоже есть, и неплохо справляется со своей основной задачей: принимать ошибки от приложений (или веба), показывать стектрейсы ошибки, группировать их и отправлять алерты.
В Sentry действительно появился механизм работы с трейсингом, однако сам UI не предоставляет тех переходов, которые мы бы хотели видеть, и есть подозрение, что будут проблемы с обработкой того объёма данных, которые у нас есть (мы не пробовали, но опираемся на предыдущий опыт использования sentry). Поэтому на данный момент Sentry у нас используется только по прямому назначению.
Доклад про то, как сначала создать себе проблем микросервисами, а затем пытаться их решить ресурсами.
Да, могли ж просто монолит на пхп забабахать, чтоб он один мильоны рпс вывозил, и на одном мощном серваке его развернуть, не заниматься ерундой
@@artembass9535 кто тебе сказал, что монолит не масштабируется? Джун детектед.
Без пути героя нечего было бы докладывать)
@@namegormну удачи помасштабировать свой монолит, может быть в твоем залупа-софте с 10ю клиентами и 3мя разрабами это не вызовет проблем
и да, трейсы нужны не только в микросервисной архитектуре, в твоем любимом монолите они тоже будут очень полезны, стажер детектед
инцидент-инженеры у вас по сути являются SRE инженерами?
Человечество придумало довольно много определений SRE-инженерам :) Но в Авито это разные роли.
В Авито SRE-инженеры в первую очередь занимаются разработкой и эксплуатацией решений, влияющих на стабильность системы. Например, они могут заниматься быстрым развертыванием Kubernetes кластеров, их настройкой и организацией автоматического наблюдения за ними (и автоматического выведения деградирующих k8s узлов).
Инцидент-менеджеры организуют постоянное (24/7) наблюдение за production средой. Если по метрикам (или по другим признакам) заметно, что что-то перестало работать, инцидент-менеджер занимается процессом устранения деградации: определяет зону ответственности, находит и призывает ответственных разработчиков, помогает им найти root cause и ведет лог инцидента для последующего разбора.
@@igor.baliuk
Root cause по-русски это первопричина
Простыми словами (itil) это техподдержка L1, L2, L3. Просто немодно, немолодёжно
Надеюсь это только пример, что на каждый чих людей надо будить
Рут коз 🫠
Root cause, root cause...😢 Первопричина
Не стоит доклад про логи на конфе вещать. В Авито до сих пор по номеру телефона авторизуют... Так себе сервис. Похоже на рекламу больше, чем доклад