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