Трейсинг что это такое
Что такое трейсинг расскажите пожалуйста.
Еще его называют паркуром. Он не требует никакого специального снаряжения, не нужна даже спортивная площадка и особая экипировка. В трэйсинге есть только город и экстремалы, бегущие по его стенам, перепрыгивающие через заборы и изгороди, гаражи и канавы.
да вы заколебали! она именно про разновидность фитнеса спрашивает!
Трейсинг (метод Трейси Андерсон) — это смесь пилатеса, аэробики и личных наработок Трейси Андерсон, известного фитнес-тренера таких звезд, как Мадонна, Гвинет Пэлтроу, Шакира и т. д. Она изобрела специальные тренажеры и упражнения, которые задействуют самые мелкие группы мышц и позволяют добиться максимально гармоничного развития всего тела.
Сама Трейси о своей методике говорит так: «Традиционные виды тренировок вам не помогут, они делают некрасивую фигуру с гипертрофированно натренированными мускулами в одной-другой части тела, не развивая другие. Ни пилатес, ни бикрам-йога, ни бег не смогут выточить вам такую женственную, аккуратную фигуру, как разработанный мной в течение десяти лет метод. Благодаря постоянному разнообразию и чередованию упражнений, которых в методике уже более трех тысяч, а программа меняется каждые 10 занятий, вы натренируете второстепенные мышцы, не наращивая основных, и станете обладательницей идеального тела». И фигура Трейси, — наглядное тому доказательство.
Автор методики настаивает на тренировках шесть раз в неделю по целому часу (по 30 минут — на кардио-нагрузки и 30 минут — на тонизирующие упражнения). «Вы же чистите каждый день зубы, почему не можете ежедневно выделять время и телу?»
Трейсинг
В последние годы все большую и большую популярность приобретают экстремальные виды фитнеса. Эта тенденция «оживляет» не только общеизвестные экстремальные виды спорта, но и помогает появляться новым, например, трейсингу. Это неизвестное название станет Вам, скорее всего, известнее, если назвать трейсинг паркуром (вообще-то, это два названия для одного и того же вида спорта). Ну что, Вы еще не вспомнили этих «диких» парней, бегающих по стенам и прыгающих с нечеловеческой высоты?
Суть паркура
Занятия паркуром не требуют никакого специального снаряжения, кроме собственного тела. Площадка для тренировки – это весь город с его препятствиями – канавами, заборами, гаражами, стенами домов и т.п.
Смысл паркура – преодолеть любым нестандартным способом препятствие, которое может встретиться на пути. Для тех, кто занимается трейсингом, этот вид спорта не только спорт, а гораздо больше – стиль жизни. Впервые о паркуре узнали в 1987 году в Париже, когда первый трейсер Давид Белль собрал команду из восьми человек, которые также, как и он, были увлечены нестандартными способами передвижения. Команда получила название «Ямакаси». Позже известный режиссер Люк Бессон снял о них фильм с одноименным названием, благодаря которому о паркуре узнал весь мир. Моментально новый экстремальный вид спорта стал популярным во многих странах мира. Экстрим, отсутствие дополнительных затрат – выгодные положительные стороны трейсинга. Но эта «легкость» занятий паркуром всего лишь видимость.
На самом деле трейсеры – это люди с солидной физической подготовкой, ведущие здоровый образ жизни. Курение и частое употребление алкоголя несовместимо с занятиями паркуром. Задумайтесь об этом перед тем, как с головой окунуться в мир трейсинга. Начните с самого малого, например, с контрастного душа после утреннего бега. В противном случае Вам вряд ли удастся достичь каких-либо успехов.
Самые успешные трейсеры пришли в это спорт уже после занятий боевыми искусствами, альпинизмом или акробатикой. Но если уж не сложилось, и до паркура Вы ничем не занимались, то это тоже не повод расстраиваться. Конечно, Вам придется начать с самого начала, но, как говорится, было бы желание. Вас зачислят в «трейсеры-первоклассники» после вступительного экзамена – подняться легким бегом на последний этаж многооэтажки, причем, самой высокой в районе или даже городе.
Риск или удовольствие?
Если справитесь с таким заданием, значит с Вами можно работать и Вы не безнадежны. После многооэтажки последует обучение базовым элементам паркура, без которых немыслима дальнейшая «карьера» успешного трейсера. К базовым элементам относятся такие элементы, как «ролл» и «лендинг». При прыжке с высоты ролл помогает смягчить падение, т.к. приземление происходит в кувырке. Лэндинг также относится к приземлению, а если быть точнее, то к приземлению на все конечности. Такое приземление разгружает позвоночник и бережет его от травм. Далее следуют множественные групповые упражнения на развитие равновесия. Активно задействуются психологические тренинги. Тренировки по паркуру чем-то напоминают занятия в лагере выживания.
Любой экстремальный вид спорта – это риск для жизни. Паркур не является исключением. Ответственность за проделываемые трюки лежит только на трейсере. Т.к. аудитория трейсинг-клубов преимущественно ребята от 16 до 21 года, они в состоянии самостоятельно принимать решения. Никто не заставляет их проделывать трюки, к которым они еще не готовы, и они осознают это: крыша, карниз, стена не убегут. Такой же точки зрения придерживаются и профессионалы: глупо рисковать собственной жизнью ради того, чтобы похвастаться или чтобы кому-то что-то доказать. Каждый серьезной трюк требует значительной предварительной подготовки. Если сложный трюк попытается выполнить новичок, то наверняка его ждет больница или, как минимум, травмпункт.
Лозунг трейсеров: «Нет границ, есть только препятствия!» Следуя этому лозунгу они бегают по стенам, как герои «Матрицы», выполняют эффектные сальто, прыгают с большой высоты по примеру человека-паука. Одно маленькое «но» – у них нет дублеров, выполняющих за них трюки, у них нет страховки.
Дурачество? Нет – стиль жизни. Самое огорчительное в трейсинге – это его неприятие большинством людей. Кто-то грозится пожаловаться в милицию, кто-то переживает, и очень редко можно услышать голос в поддержку паркура. И все это несмотря на то, что даже такая звезда кино, как Джеки Чан отметил, что паркур – это спорт будущего.
Что ж, продвигать что-то в массы всегда трудно, тем более это трудно с экстремальными видами спорта, на занятие которыми не каждый отважится. Но если Вы точно знаете, что паркур – это то, что Вам нужно, то вперед сдавать вступительный экзамен! Но даже, если Вы станете признанным лидером в трейсинге, никогда не теряйте голову, т.к. в результате можете распрощаться с жизнью. Сохраняйте трезвость рассудка, и тогда у Вас точно все получится.
Трейсинг
Трейсинг — «отслеживание происхождения», комплекс мер, позволяющих по нескольким поисковым критериям определить место происхождения и связанные с этим характеристики конкретного продукта на любом этапе изготовления и/или цепи поставки. Задавая номер партии, можно узнать, какое сырье использовалось для производства данной продукции и характер его происхождения. Трейсинг применяется для идентификации происхождения каких-либо проблем, связанных с качеством продукции. Другими словами, трейсинг обеспечивает возможность идентификации происхождения данного изделия в направлении «вверх» по цепи производственных участков и поставок по записям, сделанным на предыдущих этапах движения.
 | Сейчас Вы находитесь на странице словарной статьи, поясняющей значение какого-то слова, сокращения или словосочетания, которая может быть расширена и дополнена Вами аудиовизуальным материалом, альтернативными дополнениями известных пояснений, исторической справкой, способом изготовления или использования описываемого, ссылками на внешние источники интернета и литературой, а также иными разделами до статьи энциклопедического вида. |
Если Вы попали сюда по ссылке одной из статей «Традиции» ошибочно, пожалуйста, вернитесь и перепишите данные так, чтобы они указывали непосредственно верное направление к нужной для пояснения слова или термина статье.
Уроки рисования от А до Ш по методике Аарона Шнорбица: Введение
В настоящей статье мы предлагаем тебе краткий обзор рубрики «Уроки рисования» и довольно простой, но весьма эффективной методики рисования Аарона Шнорбица, которая, несмотря на незамысловатость, позволяет добиться впечатляющих результатов при наличии минимума способностей.
«Я никогда особо не умел рисовать, поэтому изобрел технику, которая не требует от меня таких способностей. Я пользуюсь тем, что уже давно есть, но при этом получаю то, чего никогда не было. А почему бы и нет, чувак?!»
Эту философию можно сравнить с философией в рок-музыке, где вовсе необязательно знать ноты и владеть сольфеджио, чтобы создать цепляющую за душу песню или мелодию. Ты можешь сыграть на двух аккордах и спеть мимо нот, но если ты искренен и делаешь это уверенно и с хорошей подачей – успех тебе гарантирован.
Но вернямся к рисованию. Пришел, увидел, переделал – вот один из простейших путей воплощения идеи минимальными средствами, позволяющий добиться максимального результата.
По сути, это и есть методика Аарона Шнорбица – основополагающий принцип, базирующийся на использовании уже готового качественного материала, доступного в изобилии во всемирной сети Интернет и печатной прессе.
Но как конкретно воплотить идею, нарисовать именно то, что ты задумал? Как это удобнее и выразительнее сделать. Элементарно! Методом коллажа и трейсинга.
Основные технические приемы: коллаж, трейсинг
Коллаж — (от фр. collage — приклеивание) – метод, заключающийся в создании произведения, путем комбинирования и приклеивания различных вырезок из самых разных источников (книг, журналов, ткани, газет итд) на общую поверхность
Трейсинг — (от нагл. трейсинг — копирование рисунка через кальку, обводка и фиксирование основных линий)
Каждый из этих технических приемов можно осуществить как на бумаге (при помощи простейших приспособлений), так и в специальных графических программах (например, в Illustrator), то есть в цифровом виде. От этого их суть не меняется, а результат зачастую превосходит ожидания.
В дальнейшем мы рассмотрим конкретные примеры создания рисунков по методике Шнорбица, которые помогут тебе понять определенные ее нюансы и особенности и нарисовать свой собственный принт на футболку или комикс, но для начала мы ограничимся лишь кратким обзором. Это позволит тебе уловить самую суть этого метода рисования и сделать предварительные выводы.
Коллаж
Итак, рассмотрим первый прием, который также можно назвать и первым этапом метода Аарона Шнорбица – коллаж.
В нашей методике основной функцией коллажа является создание композиции из отдельных фотографий, рисунков, надписей или их фрагментов. Как мы уже говорили ранее, мы будем пользоваться сторонними материалами, чтобы получить что-то свое оригинальное. Поэтому для осуществления этой волшебной метаморфозы, нам, прежде всего, нужна своя оригинальная идея и много визуальной информации в виде фотографий, иллюстраций, рисунков, графических работ и т.д.
Определившись с идеей, мы должны тщательно продумать ее, собрать соответствующий тематический материал и грамотно разместить его, используя метод коллажа. Нам необходимо получить некий эскиз (композицию), с которым мы уже будем работать на втором этапе – трейсинге.
Что мы делаем? Мы берем кипу журналов и ненужных книг и ищем соответствующие тематические иллюстрации (либо ищем их во всемирной сети Интернет, если мы будем воплощать наши замыслы в графическом редакторе). Мы подбираем рисунки, опираясь на простейшие ассоциации. Таким образом, через некоторое время мы уже имеем необходимый материал для дальнейшей работы.
В нашем случае, не мудрствуя лукаво и руководствуясь нашей уже продуманной идеей, из всего обилия визуальной информации в Интернете, мы выбрали несколько картинок: мозг, штопор, брызги крови (левая картинка ниже). Учитывая формат принта на футболку, который, как правило, предполагает заполнение области на груди, мы составили нашу композицию.
Как это видно на правом рисунке выше, мы расположили наши объекты в прямоугольной области, изменили шрифт, увеличили размеры штопора, воткнули его в мозг.
Изменения размеров и ориентации предметов, а также устранение или добавление некоторых деталей проще осуществить в графическом редакторе типа Photoshop или Illustrator, обрабатывая цифровые изображения. Любители аналоговых картинок несколько ограничены в подобных возможностях, но при обилии подручных визуальных материалов необходимость в таких манипуляциях минимальна, так как всегда есть возможность подобрать и вырезать идеально подходящий фрагмент.
Таким образом, воспользовавшись простейшими картинками, мы создали рисунок на футболку, заложив в него конкретный нужный нам смысл. Учитывая современные небрежные тенденции молодежной графики и субкультуры в целом, такой принт может легко быть использован для массового тиражирования футболок. Разная техника исполнения отдельных фрагментов, присущая коллажу, и его некая незаконченность, придает изображению своеобразный шарм.
Трейсинг
Вторым приемом-этапом нашей методики является трейсинг. Это этап копирования рисунка «через кальку», его обводка, точное воспроизведение всех или отдельных линий рисунка. В нашем конкретном случае мы берем за основу рисунок, полученный нами в результате коллажа, то есть после осуществления всех действий первого этапа нашей методики
Как мы уже говорили, сделать это можно как в аналоговом (бумажном), так и в цифровом виде при помощи графических редакторов. Однако суть остается той же: мы рисуем на отдельном листе, расположенном поверх полученного методом коллажа изображения.
Графические редакторы типа Photoshop и Illustrator позволяются избежать многих вышеперечисленных аналоговых неудобств и обладают рядом неоспоримых преимуществ перед бумажным методом. Мы можем гибко изменять прозрачность слоев, увеличивать или уменьшать исходные изображения, менять их пропорции, получать зеркальные изображения и т.д. Кроме того мы сразу же получаем готовые макеты для типографии, если мы хотим напечатать наш рисунок на футболке или использовать его при массовом тиражировании комиксов.
Основной задачей трейсинга в нашей методике является придание коллажу целостности и добавление или изменение определенных деталей исходного рисунка.
В дальнейшем мы будем подробно рассматривать наш метод только в рамках работы в графических редакторах и на конкретных примерах.
СМОТРИ ПРОДОЛЖЕНИЕ ЦИКЛА СТАТЕЙ «УРОКИ РИСОВАНИЯ»
Как самому нарисовать оригинальный принт для тишки на конкретном примере прикольной футболки от AS T-shirts «Секс-камикадзе»
В любой системе возникает задача понять, как взаимодействуют компоненты между собой. Особенно важно это в распределённых системах. Как понять, какие компоненты обработали запрос, сколько времени это заняло, какой был порядок обработки. Всё это можно узнать, но нужно добавить немного инфраструктуры.
Егор Гришечко — работал разработчиком в компании Insolar. Команда Егора делает полностью распределенную систему, и поэтому они сталкиваются с большинством проблем, которые присущи распределенным системам. Сейчас Егор трудится в Uber и занимается разработкой инфраструктуры.
Под катом — текстовая расшифровка и видео доклада Егора с конференции DotNext 2019 Moscow. Доклад будет полезен разработчикам микросервисных систем, которые смогут для себя открыть эти технологии. А также будет интересен бэкенд-разработчикам, интересующимся метриками и мониторингом.
В докладе
Поговорим немного про observability, зачем это нужно, про распределенные trace-метки, поговорим про Jaeger — это такая система сбора trace-меток, потом я расскажу о перипетиях и Санта-Барбаре вокруг OpenTracing и OpenCensus и чем это всё закончится.
Мы живем в мире, который становится сложнее с каждым днем. Есть миллионы картинок про прекрасный frontend, ужасный backend, но чаще всего юзер видит какую-то верхушку айсберга.
Картинка отображает ход нашего времени. Картинка, датируемая 2016 годом, но ничего по сути не поменялось. В 2005 у нас было классическое распределенное приложение, которое я застал, начиная работу. У нас есть какой-то веб-сервер, какая-то база, какая-то логика, мы вот ходим, отдаем, все счастливы.
Сейчас это не работает. Из-за возросших нагрузок, из-за микросервисов и из-за того, что все хотят быть модными и многого другого.
Раньше у нас было классическое приложение, которое было одним бинарем, распространялось максимум по двум машинам, и мы счастливо с этим жили.
На смену этому пришли микросервисы, и нам стало тяжелее. Представим, что у нас система, состоящая из множества компонентов. Чем больше у нас компонентов, тем больше у нас точек отказа.
Потом у нас появились вот эти ребята.
Они появились относительно недавно, но это еще один слой абстракции. Мы что-то грузим в docker, куда-то отправляем, он где-то крутится, что-то происходит. Что с этим делать — непонятно.
У нас постоянно растет комплексность наших систем, добавляется количество компонентов. Мы строим комплексные системы, а комплексным системам свойственен достаточно обширный класс проблем, которые можно классифицировать.
В любой комплексной системе есть проблемы. Чем больше вы делаете, тем больше у вас может сломаться. Поведение распределенной системы патологически непредсказуемо. Здесь вступает в дело обычная комбинаторика, то есть комбинации сбоев могут дублироваться.
Посчитайте формулу комбинации сбоев. Каждый микросервис у вас может отказывать тремя или пятью способами и просто посчитайте количество ваших микросервисов, и вы примерно увидите, сколько у вас комбинаций сбоев может быть.
Из этого следует, что мы не всегда можем предсказать комбинации этих сбоев. Это самое ужасное. В моей практике этот пункт — это главная боль, которую я испытываю на протяжении уже долгого времени. Когда ты такой: «Да, я написал, работает — круто».
Пускаешь тестировать, и потом три дня чекаешь логи и метрики, чтобы понять, что одно сообщение пришло раньше другого на 2 милисекунды, из-за этого всё сломалось.
Мы отрасль, которая работает для бизнеса, мы делаем услуги, мы делаем так, чтобы бизнесу было хорошо. Бизнес платит за это деньги. Нам критически важно, чтобы в наших системах мы могли понять, что сломалось. Мы хотим знать, почему это не работает или работает не так, как мы предполагаем.
Что такое observability?
Наблюдаемость — это обеспечение прозрачности процесса работы наших систем. Оbservability — это то, что помогает понять, как работает ваша система. Если ваша система работает непонятно как, у вас есть метрики, трейсы, логи, но вы не можете понять, что сломалось, у вас нет observability.
Observability — это про то, как вы подходите к разработке систем, как вы настраиваете процесс тестирования, как вы настраиваете процесс раскатки, метрики и так далее. Можно подумать, что это мониторинг, но это не так. Опять же картинка с той чудесной книжки:
С помощью мониторинга мы можем покрыть предсказуемые падения. Допустим, налепим метрик на то, что у нас падают контроллеры, налепим метрик на репозитории. У нас там что-то упало, повысился rate падающих запросов, — мы увидели, всё хорошо. Тестирование — это тоже чудесно, оно помогает нам предсказать, проверить сбой, который мы можем предсказать.
У нас есть ещё гигантское множество проблем, которое мы не можем покрыть. Разрывы сети, асинхронное движение сообщений, дедлоки. В практике я очень часто сталкиваюсь с тремя проблемами: сообщение пришло не туда, куда нужно, сообщение пришло не так, как нужно, и мы задедлочились в себя. Это описание моих главных проблем за последние полгода.
На данной картинке все эти комбинации сбоев представлены в синем квадрате, и observability по сути закрывает собой этот синий квадрат. Оbservability, с точки зрения девелопера — это такой супер-сет мониторинга, более модный и более накрученный, но в базе его лежит мониторинг.
Зачем нужен Observability
Пример немножко абстрактный, реальный код пойдёт чуть позже.
Представим, что у нас где-то сообщение пошло не туда, куда нужно. Как нам по-быстрому понять, что у нас, допустим, сломался CurrencyService, или ЕmailService, или ещё что-то. В данной ситуации нам нужно понять, что сломалось.
Еще есть вариант — это грепать логи (grep — это утилита для Linux, которая помогает искать по тексту). Я на своей текущей работе прошёл через этот этап, когда у нас распределённая система, мы такие: «Да, логи нам помогут». Ты два дня пытаешься грепать логи, сидишь-сидишь-сидишь, а потом понимаешь что больше или равно с меньше попутал или еще что-то.
Кто не любит Google — картинка из репозитория Microsoft, на которой изображено примерно то же самое. У нас какие-то есть микросервисы, что-то мы туда ходим, у нас мобильное приложение, web-shop. А если что-то сломалось, как нам понять?
Чтобы это всё можно было предсказать и повысить наблюдаемость системы с точки зрения девелопера, существуют три столпа observability, и они основаны на трех общеизвестных понятиях — логи, метрики и трейсы.
Что такое Trace
Я позволил себе своровать картинки из репозитория Jaeger — продукта, о котором я буду рассказывать. Давайте представим: у нас есть 5 микросервисов, которые пронумерованы латинскими буквами от A до E. Для того, чтобы вам понять, как сообщение течет по вашей системе, вы присваиваете какой-то уникальный Trace ID.
Сообщение пришло в вашу систему, допустим, на Nginx или майкрософтовский веб-сервис, вы присвоили GUID, и этот GUID ходит по системе, и потом вы можете собрать его путь. По сути трейсы — про это.
Трейсы — про то, как ваше сообщение пройдет через систему, и вы сможете это визуализировать. В картинке выше запрос пришел в A, потом пошел в B, потом пошел в C, после C он пошел в D, и потом он завершил свое выполнение в E. Мы видим, что у нас время течет слева направо, и мы имеем какое-то вложенное дерево вызовов, видим его вложенность.
Давайте посмотрим на более реальном примере.
У нас есть запрос, он куда-то приходит в балансировщик, потом приходит в API, из API он может пойти в Cache, — если не найдет в Cache, он пойдет в БД. Если мы нарисуем trace этого запроса, он будет выглядеть примерно так.
При этом хочу обратить внимание, что каждый из этих прямоугольников называется span-ом. Span — это идентификатор какой-то операции, который говорит «Вот ты меня вызвал в этом месте, всё, что после меня исполнялось там дальше, а я занял какое-то время». Он позволяет нам понять, сколько у нас выполнялся запрос.
Запрос пришел на балансировщик, балансировщик открыл span и передал запрос API. API в свою очередь открыл span, передал запрос Cache. Cache такой: «У меня нет, сорян». И API такая: «Ну ладно, пойду к БД». Сходила к БД, вернула и говорит: «Я закрываю свой span» и отдает запрос назад балансировщику. Балансировщик: «О, я получил наконец-таки ответ» и возвращается назад.
В визуальном виде мы можем получить картинку, которая отображает наш запрос. Причем отображает наш запрос понятно, так как мы можем посмотреть, сколько какой этап занимал времени, можем посмотреть, куда он пошел, как он пошел и зачем он пошел.
Добавлю, что span существуют не только на уровне компонентов, они существуют на уровне репозиториев, контроллеров, не только на уровне сервиса. У вас может быть два сервиса, и вы в каждом методе можете вызывать span и примерно смотреть, как запрос путешествует даже по вашей системе.
Как всё развивалось
В 2010 году Google опубликовал такой paper, который называется Dapper — высоко эскалируемая система распределенных трейс-меток. Это не тот Dapper, о котором вы думаете, это не ORM, это метрики.
Основываясь на этом paper-е в 2012 году компания Twitter сделала такую систему, которая называлась Zipkin. Zipkin был написан на Java, он и сейчас написан на Java, несколько раз переписывался.
В 2012 не существовало такой штуки, которая сейчас называется Cloud Native Computing Foundation. Это такая Foundation, в которую заносят деньги большие компании, и суть его заключается в том, что она поддерживает проекты, которые позволяют строить Cloud Native приложения.
Если совсем просто, на приложения, которые можно обернуть в Docker, запустить в Kubernetes и безболезненно проэскалировать.
Zipkin был написан в 2012 году, у него была не совсем удачная архитектура, его было болезненно разворачивать, и была одна большая проблема. Она заключалась в том, что когда у вас есть система сбора чего-то, вам нужны клиентские библиотеки под разные языки.
Twitter не поддерживал официальные библиотеки под все языки, у него была библиотека под Java, а всё остальное было в open source.
Немного ранее 2012 года на свет появилась компания Uber. В 2015 году компания Uber столкнулась с проблемой, что у них больше 500 микросервисов, и эти микросервисы написаны на разных языках: на Go, на Python, на Java.
Они начали имплементировать Zipkin и столкнулись с проблемами в конфигурации, с проблемами в том, что клиентские библиотеки работали не так, как им нужно. Когда есть большая компания, у неё есть проблема и у нее есть деньги, она пишет свой велосипед. Этот велосипед называется Jaeger. По картинке можно понять, что он написан на Go.
Он представляет из себя решение, которое позволяет вам собирать распределенные метрики ваших решений.
При этом он построен так, что его можно модульно конфигурировать, у него есть официальная поддержка под кучу разных языков. Uber специально для создания Jaeger создал отдельный департамент в Нью-Йорке, создал много библиотек и посадил команду, которая отдельно занимается всей этой историей.
Посмотрим небольшое демо:
Live-кодинг
У меня есть простой проект.
Он состоит из трех микросервисов. В них есть по простому контроллеру.
Что делают эти контроллеры? Они считают — 1, 2, 3. Микросервис 1 возвращает 1, делает запрос ко второму, а потом коннектит запрос второго к слову «первый» и возвращает. Есть микросервис 2, который делает то же самое, но возвращает слово «второй». И есть третий микросервис, который делает всё то же самое и возвращает слово «третий».
Я хотел показать, как легко запустить Jaeger.
Дело в том, что мы очень часто сталкиваемся с тем, что нам сложно что-то начать использовать, особенно если речь заходит про инфраструктуру или разворачивание чего-то.
Дело, конечно, становится всё лучше, но мы постоянно сталкиваемся с проблемой, что чтобы начать что-то использовать, нам надо потратить два дня. В случае с Jaeger вы можете стартануть, просто выполнив команду docker run. Я специально вынес эту команду в readme, она есть в официальной документации и она доступна в репозитории, который я создал для DotNext.
Эта команда запускает образ, который собирает в себя все компоненты Jaeger. Так как он полностью модульный, там несколько docker-образов. Запуском этой команды мы запускаем docker docker-образов, который полностью поставляет нам готовое к использованию решение.
На моем текущем месте работы мы так и делаем: у нас есть такой специальный ssh-файл, который называется «монитор SSH». Мы его запускаем, он нам запускает метрики и запускает вот так Jaeger, который хранит все данные у нас в мемори, и когда он он умирает, мы его заново запускаем и всё. Для локальных целей разработки более чем достаточно.
Все эти порты нужны для того, чтобы поддерживать разные варианты отправки трейсов. В Jaeger есть такая фича, после того, как они столкнулись с проблемой c Zipkin, они поддержали на определенном моменте обратную совместимость с Zipkin. Они заявляют, что если в вашей инфраструктуре есть Zipkin, вы ничего не меняете, просто переключаете трафик на Jaeger, и у вас всё заработает.
Давайте запустим этот файл. У меня уже скачан образ. Он запустился, качается он примерно секунд 30, то есть он не очень большой.
Так как для просмотров трейсов, нам нужен UI, я специально в readme вынес адрес, по которому мы можем посмотреть, давайте по нему перейдем.
У нас откроется чудесный UI, в котором на данный момент нет ничего по понятным причинам, потому что мы ещё ничего не отправили, но по сути это дефолтное средство для просмотра трейсов. Мы можем выбирать какие-то сервисы, мы можем выбирать специфичные операции, можем фильтровать по всяким штукам, искать и так далее.
Для запуска решения я написал отдельный файл, в котором нет никакой магии. Оно убивает предыдущий запуск, потому что, что-то было запущено и просто стартует наше первое, второе и третье решение.
Попробуем отправить запрос.
Для этого я использую curl, потому что у нас максимально простая API.
Первый, второй, третий запросы пошли по системе, давайте посмотрим, что произошло с Jaeger.
В это время в Jaeger у нас появилось 3 микросервиса, и мы можем посмотреть, что с ними происходило.
Мы сразу видим, что наш запрос занял примерно 500 миллисекунд. Повторим его.
Обновим Jaeger и видим, что один запрос у нас занял где-то 500 миллисекунд, а второй занял уже 16 миллисекунд. Повторим третий раз.
Видим, что запросы проходят всё быстрее и быстрее. Первый запрос самый долгий, дальше всё идет побыстрее. Провалимся в запрос и посмотрим, что в нем происходило. Эти штуки по сути отображают полную жизнь одного запроса. Я запустил get-запрос, он провалился в систему, прошел по микросервисам, вернулся — теперь каждый из этих запросов отображается в UI.
Провалимся в него и увидим картину со span.
Мы видим, что у нас запрос типа get, он пришел в первый микросервис, выполнил какие-то действия, потом он прошел во второй микросервис, выполнил какие-то действия, прошел в третий микросервис начал, вернул какие-то действия, написал какие-то логи, причем логи достаточно подробные, это одна из фичей библиотек, которые подключаются. Потом у нас вернулся результат.
Мы видим, что запросы были вложенные, нигде не было параллельных запросов, мы сначала прошлись по первому, потом прошлись по второму, потом прошлись по третьему.
Посмотрим другую фичу Jaeger, которая называется построение графа зависимости ваших микросервисов. Там маленький граф из трех нод.
Мы можем его развернуть в нашу нормальную проекцию и увидеть, что сначала запросы пришли в первый микросервис в количестве трех штук, потом провалились во второй микросервис в количестве трех штук и дошли до третьего. Мы можем построить карту наших микросервисов и посмотреть, как запросы ходят по системе — это достаточно круто.
Перейдем к коду и посмотрим, как я это всё подключил. Для этого перейдем в Startup.c.s первого проекта.
Чтобы Jaeger заработал, нам нужны 2 набора библиотек или 2 библиотеки. Первая из них Jaeger, вторая из них OpenTracing.
Подключаем OpenTracing в проект и регистрируем такой интерфейс, который называется Tracer, который помогает нам строить эти трейсы. Мы берем имя приложения, создаем трейсер из библиотеки Jaeger, регистрируем его глобально.
Так как это регистрация для Dependency Injection ASP.NET Core, у нас может быть какой-то код, где мы тоже хотим использовать trace, где у нас нет инъектора, для этого у нас есть статические классы. Возвращаем имплементацию и пользуемся.
AddOpenTracing добавляет стандартные обработчики для логирования, для ASP.NET Core. Мы добавляем логи для ASP.NET Core, для CoreFX, для EntifyFrameworkCore и так далее. Чтобы заработали все те трейсы, что я показал, достаточно выполнить этот код и запустить Docker run.
Даже с поиском документации в первый раз у меня это заняло где-то минут 30 — всё заработало и было классно.
Я хочу вам показать, что я ничего в первый Controller не прописывал. Вот первый репозиторий, какой-то код, HTTP-запрос, и при этом всё работает — просто магия, всё чудесно.
Немного накрутим наше решение и продемонстрируем, что Jaeger у нас на самом деле кроссплатформенный. Я написал вражеский сервис или Alien, чужой сервис, который работает на Go и который тоже в себе содержит Jaeger.
Мы стартовали сервис, но он же не принимает у нас ответы.
Настало время того кода, который я вам показал до этого. У нас есть третий микросервис, и теперь он будет посылать запрос на Alien микросервис.
Ещё раз перезапустим наше решение, ещё раз введем пароль. Всё заработало без пароля, чудесно. Дождемся, пока всё запустится. Выполним запрос.
Мы видим, что запрос поменялся, он ушел в Go.
Посмотрим, как это всё отобразилось Jaeger.
Мы видим, что у нас появился четвертый запрос, в нём появился Alien, видим, что он опять у нас занял примерно 600 миллисекунд, видим, что он появился в span-е, видим, что он выполнен другой версией Jaeger для языка Go.
Там тоже достаточно просто подключается библиотека, это почти всё работает из коробки.
Немного поиграем со span-ами. Я вам показал только базовые возможности, но мы можем сделать много всего интересного. Для этого в конструктор я заинжектил интерфейс, который называется ITracer, который я вам уже показывал, который мы регистрировали.
Скажем, что мы хотим какой-то свой чудесный span, в которой напишем лог.
Пишем tracer, build span: «я новый span». Потом на Span пишем Log. Это такое средство, которое позволяет нам добавить информацию Span, которую мы увидим. Давайте напишем: «Я новый чудесный Log». Запускаем приложение.
Ничего с этим не поделать, мы же пишем на javascript, нам перекомпиляцию надо, перезапуститься, подождать. Оно всё конечно быстрое, но…
Снова делаем запрос. Он прошёл, давайте посмотрим, что получилось.
Мы добавляли в код. Ничего не произошло. На самом деле это очень важная штука, на которую я натыкался много раз и захотел отдельно вынести — Span надо закрывать.
Надо всегда, вне зависимости от языка и конструкций, писать span.Finish. Если это не сделать, span повиснет и не отобразится. Перекомпиливаем.
Выполняем запрос, идем в Jaeger, ищем новый span, и видим — «Я новый лог». Мы чудесно сообщили себе, что происходит внутри кода.
Для Jaeger покажу последнюю прикольную фишку, которая меня тоже пару раз спасала — называется SetTag и в ней мы пишем:
Она поможет красиво отображать ошибки, например, чтобы анализировать span, когда случается что-то нехорошее. Вы пишете вот так, перекомпилируете решение, отправляете curl-запрос, идете в Jaeger, обновляете trace и видите, что случилось.
Например, «Я новый спан» сломался, с ним что-то не так и нужно что-то делать. Очень красноречиво и помогает фильтровать snap, работать с ними.
Самая прикольная фича Jaeger, которая мне нравится — это сравнение запросов.
У нас есть два запроса: один с alien, второй без. Мы знаем, что ни разные, но, допустим, у нас trace на 500 span-ов, и мы хотим их сравнить.
Переходим на страницу Compare, берем id, пишем слева, потом берем второй span, id, и видим, что они различаются. У меня перестал работать скролл — это проблема.
При приближении вы сможете увидеть разницу ваших запросов. Можно увидеть, что у нас все запросы шли одинаково, а потом после третьего один сразу возвращает результат, а второй еще куда-то уходит, что-то делает и это достаточно странная штука.
Очень помогает при дебаггинге, пару кейсов я решил с помощью этого тулы.
Это базовое демо, его достаточно для включения Jaeger в ваши проекты. Когда вы в первый раз построите карту микросервисов, если ещё не построили — скажете «Вау!» и увидите, какие-то сообщения уходят не туда.
Как это все работает
На самом деле все работает примитивно.
У нас есть какие-то запросы, мы таскаем с ними информацию, которая характеризует этот запрос, и отправляем это куда-то в бэкенде. Когда запрос приходит в систему, первый микросервис, в который включен Jaeger, и в вашем коде включен Jaeger, он просматривает header. Есть trace id у header, если он есть — Jaeger парсит его для себя, если нет — создает новый.
Все наши запросы просто таскаются с header id, это где-то 16 символов, захешированная строка. Она путешествует на вход, на выход, и потом в бэкграунде отдельной библиотекой отправляются в коллектор, который помогает в отображении этого всего.
В чем заключается модульность структуры Jaeger: в Jaeger есть 4 важных части. Это клиентская часть, это коллектор, DB-часть и UI.
Клиентская часть — это ваше приложение, в котором вы включаете какой-то код (подключаете библиотеку), которая информацию о span-ах включает в Agent.
В agent она шлет по UDP и предполагается, что этот agent будет развернут у вас в sidecar, рядом в docker, или на той же машине. Оно посылается по UDP, по быстрому loopback и клиентское приложение почти не грузится — мы не получаем никаких проблем с производительностью из-за отправки куда-то span-ов.
Далее Jaeger-agent по gRPC отправляет это в collector.
Это такая «умная» штука, которая сортирует span, складывает их, работает с ними — то есть в него льются потоки данных, а он их льет в базу. В то же время коллекторы — это такая штука, которая может хранить удаленные настройки.
Вы написали настройки, поставили кучу сервисов и когда сервисы подключаются к коллектору — они читают настройки и просто работают по ним. Сейчас они очень много работают над адаптивными настройками, чтобы в зависимости от течения трафика у вас изменялось количество span, которые вы принимаете.
На самом деле существует проблема и в Uber, я знаю некоторые российские компании, которые столкнулись с той же проблемой: когда у вас очень много span-ов, нужно очень много железа.
Для этого существует sampling. Вы можете отправлять не каждый span и не каждый trace в бэкенд Jaeger. Вы их шлете и шлете, а сохраняется, допустим, каждый сотый или тысячный. Сейчас они очень сильно работают, чтобы сэмплинг был адаптивный и подстраивался под условия.
Следующая часть — DB.
Они не стали придумывать и просто дали возможность подключать несколько внешних хранилищ. Одно из них — Cassandra. Это штука, написанная Twitter, очень быстрая на чтение и немного медленная на запись. Elasticsearch — это elasticsearch. Можно всё это запиливать в Kafka и потом как-то читать. Когда вы запускаете docker, у вас стартует memory storage, который просто складывает данные как key value в памяти.
Что происходит с данными, которые вы храните в памяти — выключаете программу, приходит уборщица из-за чего данные пропадают.
UI, который вам показал, и за ним query-движок, который строит запросы, агрегирует их, помогает отображать на UI, чтобы все было красиво.
Немного поговорим о теории.
OpenTracing
Когда я продемонстрировал вам, как Jaeger подключается к проектам, я подключил две библиотеки: Jaeger и OpenTracing.
Представим абстрактный контроллер в вакууме, ASP.NET Core. Инджектим в него какой-то репозиторий и можем поменять реализацию базы данных. Пишем репозиторий, потом мы устали от SQL-схемы или нам нужно увести нашу базу в облака, как-то меняем нашу реализацию и у нас все работает.
OpenTracing — это примерно то же самое. Это набор интерфейсов, абстракция, которая помогает нам работать с распределенными трассировками.
Она говорит: «Я даю тебе интерфейс, ты используешь интерфейс и не паришься, так как ты конечный потребитель, а потом, где-то там подключишь библиотеку и сможешь относительно безболезненно поменять реализацию span-ов на другого провайдера».
Мы подключили эту библиотеку и интерфейсы. Сейчас мы используем Jaeger, потом нам дали денег, и мы счастливые решили подключить DataDog. Это относительно без проблем стартует, вы вообще не будете переписывать код, только немножечко помучаетесь с конфигурациями, чтобы это все подключить.
Он содержит набор интерфейсов и несколько вспомогательных утилит: iTracer, iSpan, который инкапсулирует работу со span-ами, интерфейсы для SpanBuilder, чтобы строить span-ы и несколько интерфейсов, связанных со scope-ами.
Я заинджектил iTracer, я его как-то использую.
Интерфейс iTracer — это интерфейс, на котором определенный метод BuildSpan принимает string и возвращает другой интерфейс, который называется IBuildSpan.
Интерфейс ISpanBuilder представляет из себя:
Это интерфейс, в котором есть метод, который возвращает интерфейс.
Мы вызываем какие-то методы на следующие интерфейсы. Это интерфейс ISpan, который тоже определяет на себе какие-то методы, вот тут же этот обязательный финиш, про который стоит помнить.
Работаем через интерфейс: инкапсуляция, полиморфизм — вот это всё, что мы любим или не любим.
Интерфейс возвращает интерфейс, интерфейс, интерфейс… Мы работаем максимально высокоуровнево и вообще не знаем, что там происходит в бэкенде, счастливы, довольны.
Когда мы хотим подключить реализацию, просто подключаем реализацию от провайдера, который создал вам совместимость с OpenTracing.
OpenTracing — это набор интерфейсов, который лежит на GitHub и для которого разные провайдеры и создатели Trace-систем обеспечивают совместимость.
Компания Jaeger знала про OpenTracing, она такая: «окей, мои библиотеки будут совместимы с OpenTracing». DataDog — аналогично.
Чтобы поменять реализацию, нам достаточно будет подключить LightStep.Options и всё. Мы поменяли имплементацию, просто работаем с нашими интерфейсами и где-то в бэкенде поменяли реализацию.
OpenCensus
В это время в этой же галактике существовала такая компания, как Google. В своих внутренних продуктах компания использовала библиотеку OpenCensus, которую в определенный момент тоже заопенсорсила.
OpenCensus — это open source решение, основная цель которого упростить работу с метриками, с трейсами для разработчиков. Авторы понимают: у нас столько провайдеров, у нас столько всего, мы хотим просто.
Вот это просто — это библиотека OpenCensus. Мы тоже представляем какой-то унифицированный интерфейс, который помогает нам подключаться к различным провайдерам.
Вот пример работы этой библиотеки. Он напоминает то, что я вам показывал с OpenTracing. У нас есть какой-то SpanBuilder, что-то мы там стартуем, что-то делаем и так далее.
Реализация работает примерно похоже: у нас есть какое-то наше приложение, под ним лежат интерфейсы, мы работаем через эти интерфейсы, куда-то шлются данные, и мы вообще не паримся об этом.
OpenCensus дополнительно поставляет реализацию. Если OpenTracing — это просто интерфейсы, то OpenCensus — это интерфейсы + реализация. Кроме трейсов он позволяет работать с метриками. Для C# мы можем видеть, что реализованы экспортеры для Azure, для Prometheus, для Jaeger. Для разных языков реализованы разные экспортеры. Если OpenTracing — это просто интерфейсы, то OpenCensus — это такой: у нас есть интерфейсы, но мы не верим компаниям, которые создают решения, и мы напишем свои экспортеры.
Получается: у нас есть OpenCensus, который делает интерфейсы плюс реализации, в левом углу ринга, и в правом углу ринга у нас OpenTracing, который делает примерно то же самое, только про интерфейсы.
Я просто ради интереса привел сравнение.
В OpenCensus и OpenTracing есть interface ITracer. Они делают одно и то же, они возвращают даже интерфейс один и тот же по названию. Они немного отличаются по функции, но делают всё то же самое.
То же самое для SpanBuilder, то же самое для ISpan.
У нас существует два решения, которые делают примерно одно и то же с некоторыми различиями. Ребята, которые поддерживают эти проекты, работают в больших компаниях, и они смогли договориться. Они собрались на нейтральной территории между кампусами Microsoft и Google где-нибудь в Сиэтле и решили сделать проект, который называется OpenTelemetry.
OpenTelemetry
Это эксклюзивный скриншот старого сайта. Сейчас у них сайт более красивый. OpenTelemetry — это конец истории, связанной с двумя разными реализациями, и он собирается вобрать в себя лучшие стороны OpenTracing и OpenCensus, объединить их вместе и назвать OpenTelemetry.
Основная цель OpenTelemetry — создать библиотеку, решение, которое вам поможет максимально просто работать с трейсами, метриками в ваших приложениях. То есть вы подключили одну библиотеку, и у вас всё хорошо.
OpenTelemetry — это репозиторий на GitHub, у него есть какие-то реализации.
На данный момент имплементация OpenTelemetry для C# впереди планеты всей.
Она развивается быстрее, чем все остальные языки. Её поддерживают ребята из Microsoft, и она достаточно активно развивается.
Её разработка открытая, каждую неделю проводятся daily-митинги. Microsoft слышит комьюнити, комьюнити слышит Microsoft. Эта библиотека рано или поздно выйдет в релиз.
С этой библиотекой связано две интересные истории: одна моя личная, вторая нет.
Первая — релиз OpenTelemetry должен был состояться в ноябре, а потом они написали во всех анонсах: «Упс, мы не рассчитали, мы что-то попробовали-попробовали, не полетело, ждите в следующем году». Релиз, судя по всему, ожидается на третий квартал 2020 года, они так пишут в чатах и в issue.
Вторая — моя личная история, как я пытался запустить OpenTelemetry на проекте.
У OpenTelemetry уже есть альфа-релиз. Я такой: «Ура, поставлю себе альфа-релиз и попробую запуститься». Я открыл доки из мастера, поставил себе nuget package и понял, что релиз был в июне, а после этого было полгода разработки, и доки не соответствуют библиотеке.
Надо подключаться к альфа-каналу, собирать альфовский new get package из Nightly-билдов, либо собирать локально сборку. Я мучился вечер, забил и решил, что вот как они опубликуют следующий релиз, это всё можно будет пробовать.
Главная история в том, что все мы там будем. Кто пользуется OpenTracing или OpenCensus или собирается пользоваться, рано или поздно это будет OpenTelemetry.
Спецификации
Представим, что у нас есть два сервиса: сервис А, который работает с Jaeger, сервис Б, который работает с APM и сервис В, на котором мы свои трейсы написали, в своем формате хэдеров. Uber-trace-id — это формат Jaeger, elastic-apm-traceparent — это формат хэдера для Elastic APM.
У нас разные решения или запрос ходит между системами разных провайдеров, мы хотим парсить или как-то ещё работать, но при этом не терять эту информацию. Формат trace-ов в данный момент несовместим. Тут всё не так плохо.
Комитет людей, которые работают над Open Telemetry и создатели Jaeger, который Юрий, уже работают над стандартом для Trace Context. Это как с HTML: они напишут стандарт, а вам только надо будет его заимплементить.
И trace-ы между всеми системами будут выглядеть примерно в таком формате.
У нас и у них будут одинаковые заголовки, и когда к вам будет приходить trace, вы без проблем сможете его спарсить. Вам не нужно будет ожидать много разных trace-ов, много разных форматов и так далее. Спецификации, интерфейсы, единообразие — это всё классно и замечательно.
Давид Фаулер в июне 2019 годаобъявил, что ASP.NET Core 3.0 автоматом поддерживает парсинг W3C-контекстов.
Когда приходит запрос, и в нём есть header в формате W3C, ASP.NET за вас всё спарсит и также добавит в тот же формат header, когда вы будете отправлять запросы вне.
Создатели ASP.NET уже подумали за нас.
Полезные ссылки
Ниже представлен список литературы, который Егор настоятельно рекомендует к ознакомлению:
До следующего DotNext 2020 Piter осталось меньше недели! В этот раз на конференции выступят такие известные спикеры, как Скотт Хансельман, Джон Скит и многие другие. А еще мы сделали для вас билет-абонемент, который дает доступ ко всем 8 конференциям этого сезона.