Trace centering что это
Золотая середина или как сделать лучше всех. Обзор и тестирование монитора ASUS VN279QLB (страница 4)
Стабильность цветовой температуры
Продолжим изучение монитора ASUS VN279QLB, оценив стабильность цветовой температуры в стандартных и специальных режимах изображения.
реклама
Результаты данной таблицы представляют собой отклонения точек серого клина по оси X. Вертикальную ось они не затрагивают, а поэтому оценить наличие паразитных оттенков можно лишь по CIE диаграмме из подраздела «Гамма-кривые, баланс серого и результаты UDACT».
Показатель стабильности цветовой температуры находится на высоком уровне, а в некоторых случаях результаты близки к тем, которые часто получаются лишь после ручной настройки и калибровки дисплея. Так что по данному параметру ASUS VN279QLB обходит не только неудачный в этом плане BenQ GW2760HS, но и более дорогой Samsung.
Ручная настройка в User Mode вносит свои коррективы – точность установки White Point увеличивается, а отклонения немного уменьшаются. Два в одном, так сказать.
После произведенной калибровки среднее значение более чем в три раза ниже, а максимальное увеличивается в пределах погрешности измерений. Результат великолепный – по-другому и не скажешь.
Теперь рассмотрим результаты специальных режимов Color Temp. Напомню, что по умолчанию производитель установил пресет «User» со значениями RGB 100/100/100. Поэтому стоит учитывать, что значения его столбца полностью совпадают с результатами режима Standard из первой таблицы данного подраздела тестирования. Остается лишь поговорить про три оставшихся режима ЦТ.
Тут можно отметить следующее:
В итоге совет таков – стоит забыть о дополнительных заводских режимах ЦТ и предпочесть User с RGB Gain 100/100/100, которые в дальнейшем можно будет изменить, если у вас глаз – алмаз или есть соответствующее оборудование.
Стабильность контрастности и диапазон изменения яркости
реклама
Для изучения стабильности контрастности и диапазона изменения яркости был выставлен режим Standard. Значение яркости менялось с 100 до 0% с шагом в 10 единиц. Для представленной ниже таблицы измеренные значения были получены через программу HCFR, которая дает возможность более точно оценить уровень черного (три знака после запятой) и соответственно определить достоверный коэффициент контрастности.
Полученный рабочий диапазон яркости при стандартных настройках составил 79-321 нит при уровне контрастности в
3580:1. Снижение яркости линейно, а коэффициент контрастности меняется в пределах погрешности измерений. Сам результат пусть не такой хороший, как у конкурента в виде модели Samsung, но явно лучше, чем у BenQ GW2760HS. Так сказать, золотая середина.
Значение верхней границы яркости точки белого в 321 нит позволит работать с монитором в большинстве ситуаций, когда на рабочем месте очень светло или на экран падают отраженные/прямые лучи солнца, а вот нижнее в 79 нит – положительный результат, но устроит он все равно не всех. Особенно в том случае если приходится работать в полумраке или вовсе без внешнего освещения. Другое дело, что если вы так действительно работаете, то стоит задуматься об изменении условий для снижения нагрузки на глаза.
Если же вам захочется снизить минимальный уровень яркости, то определенно стоит снизить значение Contrast в OSD Menu. Благо запас по коэффициенту контрастности у монитора есть. Ничего страшного не произойдет, если он снизится до 2500-3000:1. Зато от меньшей яркости белого поля ваши глаза будут меньше напрягаться и медленнее уставать.
Скорость матрицы и инпут-лаг
В новинке заявлена матрица со временем отклика в 5 мс, измеренным по методике Gray-to-Gray, несмотря на то, что для той же панели инженеры BenQ заявляют 4 мс. Но у них, похоже, эта цифра просто запала во все отделы и отказываться от нее они не хотят. У Samsung и ASUS все куда стандартнее, а поэтому 5 мс – не больше и не меньше.
Для увеличения скорости в модели применена технология разгона Trace Free (она же OverDrive в общем понимании). Ее значение может находиться в диапазоне 0-100 с шагом в 20 единиц. По умолчанию, как и всегда, установлено значение 60. Посмотрим на полученные результаты:
Шлейфы на уровне хороших IPS без использования разгона, а вот артефакты все же есть. Для этого достаточно поводить курсором мышки с различной скоростью на разных по цвету фонах – самый простой тест. Далеко не во всех случаях вы их увидите, но на определенных оттенках, поверьте, они будут. Какой-либо существенной и видимой разницы в сравнении с BenQ GW2760HS и Samsung S27C750P нет и взяться ей неоткуда, поскольку в каждом из случаев разгон активирован по умолчанию.
Теперь рассмотрим влияние параметра Trace Free:
Для начала пройдемся по значениям выше 60. И тут все сразу становится ясно – артефакты оказываются еще сильнее и виднее, а шлейфы увеличиваются. При 40 все не так плохо, как при настройках по умолчанию, но не помешает снизить до 20, когда артефакты практически полностью исчезают, а длина шлейфов даже слегка уменьшается. При 0 разгон явно выключается и по скорости ASUS VN279QLB начинает напоминать огромное количество различных IPS/PLS моделей. Вывод же очевиден: выставлять значение Trace Free выше 20-40 не стоит! Иначе будет только хуже.
Говоря о разнице с IPS мониторами при условии отсутствия артефактов или их минимального присутствия, новые AMVA (AMVA+) панели практически от них не отличаются. Хотя если посмотреть некоторые тесты западных обозревателей, то на цифрах все равно пока что выигрывают IPS, пусть и не всегда с большим запасом.
реклама
Измеренный с помощью программы SMTT средний инпут-лаг на основании десяти фотографий составил 5.1 мс (при HDMI подключении). Максимальный же не превысил 6 мс, что является прекрасным результатом, который устроит подавляющее большинство пользователей любых мастей.
Углы обзора и Glow-эффект
Монитор ASUS VN279QLB – третий представитель 27-дюймовых моделей формата 16:9 с новой AMVA матрицей AUO среди протестированных в лаборатории Overclockers.ru. В очередной раз посмотрим на знакомые углы обзора (фотографии сделаны заново):
По представленному выше изображению прекрасно видно, что сильных изменений картинки при смене угла обзора нет. На мониторе ASUS снижение контрастности с увеличением угла просмотра происходит очень медленно, но лишь до определенной границы. Появление желтого оттенка при просмотре сверху заметно не сильно, а на светлых фонах вообще не проявляется – они просто становятся менее контрастными и высветляются.
реклама
В реальных условиях несерьезное изменение угла никак не сказывается на качестве отображения картинки и тут действительно VN279QLB начинает напоминать современные AH-IPS мониторы. Появление того или иного оттенка на части экрана при изменении положения головы от центра у новинки заметно очень слабо.
И все бы было очень хорошо, если бы не заметный эффект Black Crush, который некоторые пользователи спокойно могут приравнять к обычному Color Shift. Настраивай, калибруй – нет никакой разницы. Темные оттенки начинают высветляться (в зависимости от изначальной настройки могут становиться более различимыми друг от друга – касается крайних темных полутонов) при отклонении головы от перпендикуляра на 5 градусов и больше.
Эта проблема, повторю в который раз, ограничивает, с моей точки зрения, применение монитора. Он явно не сильно подходит под запросы людей с требованием стабильной цветопередачи (при рабочих углах обзора). Хотя если вы сидите всегда строго по центру, то с особенностями AMVA матриц вы не столкнетесь.
Видеоролик, размещенный ниже, прекрасно демонстрирует возможности исследуемого монитора. По нему можно наглядно представить ощущения пользователя при работе под тем или иным углом просмотра.
реклама
При диагональных углах обзора наблюдается заметное снижение контрастности, изображение покрывает слабое белое облако. При просмотре снизу этот эффект проявляется не так сильно, но при этом картинка становится несколько темнее, особенно в тенях.
Быстрее всего рассмотреть данную особенность можно, взглянув на угол экрана, находясь где-то в стороне от монитора в темное время суток. Фотография наглядно демонстрирует то, что вы должны увидеть. Также по ней можно судить об отсутствии паразитных оттенков при просмотре изображения под углом, которые возникают на некоторых 23-дюймовых e-IPS решениях и крайне редко на новых 27-дюймовых AH-IPS.
Разница по сравнению с IPS мониторами заключается в том, что никакого высветления по участкам вы не увидите. На ASUS VN279QLB все проще – меняется все изображение.
реклама
У исследуемого монитора при тестировании на цветных фонах (фотографиях, картинках) Glow эффект себя никак не проявлял. Скорее это было похоже на повальное падение контрастности вместе с небольшим снижением яркости, что происходит на любом LCD экране при изменении угла просмотра. Вот только AMVA матрицы по этому параметру все равно впереди планеты всей – в плохом смысла этого слова. И это несмотря на улучшенные в новой ревизии углы обзора.
Зато на черном фоне проблем в разы меньше, чем у самых лучших IPS дисплеев. Как можно видеть по фотографиям выше, говорить про черный цвет у AMVA под углом так же бессмысленно, как и про TN с IPS. Пусть у этой технологии и нет Glow в прямом понимании этого слова, но проблемы и особенности никуда полностью не исчезают.
Оценить поведение экрана (при яркости 200 нит) и сделать собственные выводы при работе с темными изображениями можно по двум видеороликам:
реклама
Использование Intel Processor Trace для трассировки кода System Management Mode
Эта статья посвящена тестированию возможности использования технологии Intel Processor Trace (Intel PT) для записи трассы в System Management Mode (SMM) режиме. Работа была выполнена в рамках Summer Of Hack 2019. Автор работы: @sysenter_eip.
Большинство использованных инструментов написаны другими людьми (в частности @d_olex, @aionescu). Результат представляет собой лишь объединение имеющихся инструментов с целью получения трассы исполнения кода в режиме SMM для одной конкретной материнской платы. Однако, материал может быть интересен для тех, кто захочет повторить это для своей платформы или просто интересуется работой SMM.
System Management Mode
SMM – особый, привилегированный режим процессора архитектуры x86, который доступен во время работы операционной системы, но совершенно невидим для нее. Он предназначен для низкоуровневого взаимодействия с железом, управления питанием, эмуляции легаси устройств, перехода в режим сна (S3), обращения к TPM и прочего. Работает полностью изолировано от ОС. На время исполнения SMM работа ОС полностью останавливается. Программный код, который исполняется в этом режиме, хранится в SPI-Flash памяти материнской платы и входит в состав прошивки UEFI BIOS.
Переход в режим SMM осуществляется при помощи специальных прерываний SMI (System Management Interrupt). Один из вариантов этого прерывания доступен для использования в нулевом кольце (т.е. из ядра ОС) – SMI-прерывание уровня приложений (Software SMI). Далее речь пойдет именно об этих прерываниях.
Ввиду своей высокой привилегированности, SMM представляет особый интерес для исследования безопасности. Компрометация SMM приводит к серьезным нарушениям целостности и конфиденциальности всей системы, и в большинстве случаев позволяет внедрить не удаляемый и не обнаруживаемый средствами операционной системы вредоносный код в прошивку UEFI BIOS.
Intel Processor Trace
Одним из подводных камней процесса отладки различных высоконагруженных приложений является оверхед – издержки инструментов отладки. Их можно сократить с помощью решения с аппаратной поддержкой.
После выполнения этой команды будет создан файл SMRAM_dump_cb000000_cb7fffff.bin, содержащий текущее состояние SMRAM. Значения cb000000 и cb7fffff – это, соответственно, физические адреса начала и конца SMRAM.
Работа с дампом SMRAM
Дамп SMRAM можно загрузить в дизассемблер или передать для анализа скрипту smram_parse.py, который извлечет для нас много полезной информации. Самыми важными для нас будут адреса точек входа SMI. Это адреса функций, на которые будет передано управлении при срабатывании SMI. У каждого CPU своя точка входа.
Рисунок 3. Вывод работы скрипта smram_parse
Посмотрим на их код. Так как SMM начинает свое исполнение в 16-битном Real Mode (при этом первые 4 Гб RAM отражаются на виртуальное пространство), первое, что делает код – это переключение в 64-битный режим. При этом весь SMRAM доступен с правами на запись и исполнение, так как был создан только один сегмент (существуют ли вендоры, которые делают по-другому?).
Нам бы не хотелось писать 16-битный код или подготавливать все необходимое для переключения в 64-битный режим самостоятельно, так что мы разместим наш перехватчик прямо перед вызовом функции диспетчера SMI (эта функция определяет, какому SMM модулю нужно передать исполнение в зависимости от того, какой сервис был вызван или какое событие произошло).
Рисунок 4. Место для размещения хука
Самый простой способ перехватить управление – подменить адрес диспетчера на наш. У всех точек входа одинаковый код, так что патч нужно повторить для каждой.
Примечание: Относительно места размещения кода перехватчика. Так как структура SMRAM нам до конца не известна, мы выбрали случайный кусок зануленной памяти рядом с одной из точек входа, где и разместили код перехватчика. Лучшим вариантом было бы добавить в прошивку свой SMM модуль, который UEFI бы легально разместил в SMRAM, чтобы не беспокоиться, что нашим кодом будет перезаписано что-то важное.
Реализация перехватчика диспетчера SMI
Обозначим, что конкретно мы ходим сделать внутри нашего перехватчика. Сперва нам необходимо определить, был ли включен Intel PT до перехода в SMM. Из документации Intel известно, что у каждого процессора есть своя база SMBASE (MSR 0x9E) и свое пространство для хранения состояния процессора (SMM Save State area) в момент перехода в SMM.
Рисунок 5. Схема расположения SMBASE
Определяем состояние Intel PT
В SMM Save State должно сохраняться значение MSR-регистра IA32_RTIT_CTL, который отвечает за управление трассировкой Intel PT. К сожалению, Intel Manual не указывает, куда процессор сохраняет состояние бита IA32_RTIT_CTL.TraceEn в момент перехода в SMM (включена ли трассировка, нулевой бит). Однако мы можем определить это самостоятельно, сделав дамп SMM Save State дважды: с включенной трассировкой и без.
Мы использовали инструмент WinIPT для активации трассировки на процессе интерпретатора Python (pid 1337), выделяя при этом 2^12 (4096) байт на буфер трассировки, а затем исполняли внутри интерпретатора скрипт SmmBackdoor.py (аргумент 0 – это флаги, для нас они не важны, так как в SMM все равно придется форсировать свои настройки трассировки).
Сравнив снимки SMRAM, мы определили расположение регистра IA32_RTIT_CTL в структуре SMM Save State. Он хранится на смещении SMBASE + 0xFE3C. Состояние бита IA32_RTIT_CTL.TraceEn – это главное условие переактивации Intel PT внутри SMM. Поле по этому смещению помечено в Intel Developer Manual как Reserved.
Рисунок 6. Пометка о том, что поля зарезервированы
Пишем shellcode
Нам не хотелось самостоятельно настраивать Intel PT внутри SMM, так как это бы усложнило наш shellcode (например, находясь в SMM, было бы сложно выделить большой кусок оперативной памяти так, чтобы он не был задействован самой операционной системой). Поэтому мы решили воспользоваться уже настроенным трейсером и просто «пропустить» его внутрь SMM, тем более у него уже есть функция сохранения трассы в файл.
Так как мы использовали для этих целей WinIPT, который на тот момент не поддерживал трассировку ядерного кода (CPL == 0), было очевидно, что даже при включении трассы в SMM в логе ничего не появится, так как код SMM исполняется при CPL=0. Нам необходимо модифицировать некоторые фильтры, чтобы трейсер мог работать на протяжении всего времени нахождения в SMM. Перечислим все, что необходимо проверить и установить:
Следует сказать несколько слов о PacketByteCnt. Этот счетчик определяет, в какой момент нужно вставить синхронизационные пакеты (последовательность из нескольких PSB-команд) внутрь трассы. Нам необходимо сбросить этот счетчик, иначе во время обработки трассы будет пропущен момент входа в SMM, и трасса начнется со случайного места, когда PSB будет сгенерирован естественным образом.
Ниже приведен использованный нами shellcode:
Этот код должен быть размещен в SMRAM, а переход на диспетчер SMI должен быть пропатчен для перехода на наш код. Все это делается при помощи SmmBackdoor.
Работа с трассой
Перехватчик диспетчера SMI позволил нам записать первую трассу кода из SMM. Следующей командой можно попросить WinIPT сохранить трассу в файл:
Отключение трассировки на процессе:
Можно попробовать дизассемблировать трассу с помощью утилиты dumppt из libipt.
Рисунок 7. Трасса первых инструкций SMM
Мы можем видеть некоторые адреса, однако использовать эту информацию крайне тяжело, так как она очень низкоуровневая.
Для получения более читаемого вида есть утилита ptxed (из libipt), которая сконвертирует трассу в лог исполненных ассемблерных инструкций. Конечно же, нам придется предоставить утилите дамп памяти SMRAM, так как IPT-лог не содержит информации о значениях ячеек памяти или о том, какие инструкции исполнялись; в нем есть только информация о том, какие изменения происходили в потоке управления.
Рисунок 8. Ассемблерный листинг, соответствующий логу IPT
Это выглядит уже намного лучше, однако если код содержит цикл, вывод будет забит одними и теми же инструкциями.
Определяем покрытие кода при помощи трассы
Чтобы получить визуализацию покрытия, мы выбрали плагин Lighthouse для IDA Pro, который использует формат drcov.
Готовых инструментов найдено не было, поэтому мы модифицировали ptxed так, чтобы он генерировал и файл покрытия в процессе своей работы. Пропатченый ptxed доступен в репозитории. Взгляните на историю коммитов, чтобы определить, что конкретно было добавлено.
После завершения исполнения ptxed появится файл SMRAM_dump_cb000000_cb7fffff.bin.log, который будет содержать информацию о покрытии в формате drcov.
Примечание: Существует небольшая проблема, связанная с синхронизацией дизассемблера по первому PSB. По не совсем понятной причине, если PSB генерируется до PGE (счетчик обнуляется до повторной активации трассировки), то ptxed не может синхронизоваться по нему. Для обхода этой проблемы мы сделали небольшой патч. Не ясно, является ли это проблемой самого ptxed, или мы делаем что-то не верно, сбрасывая IA32_RTIT_STATUS.PacketByteCnt.
Рисунок 9. Патч, который позволяет использовать PSB-блок, расположенный прямо перед PGE
Сгенерированные файлы покрытия можно загрузить в IDA Pro и получить красивую подсветку, а также статистику процента покрытия по каждой функции.
Рисунок 10. Плагин IDA Pro Lighthouse с информацией о покрытии кода
Примечание: Плагин Lighthouse немного странно работает на не до конца проанализированных базах (исполняемый код не размечен, функции не созданы). Мы проследили эту «проблему» до функции get_instructions_slice в файле \lighthouse\metadata.py, где она возвращает 0 инструкций даже для адреса, на котором была вручную создана функция. Кажется, плагин использует кэш и игнорирует новый определенный код. Это можно обойти, вызвав Reanalyze на программе и переоткрыв IDB. Только после этого плагин сможет увидеть новый код и начать учитывать его. Так как эта проблема очень мешает в случае SMRAM дампа (который при первой загрузке почти полностью состоит из неопределенного кода), мы внесли одно небольшое изменение в код Lighthouse, чтобы можно было определять новый код вручную быстрее.
Рисунок 11. Добавленное лог-сообщение, помогающее в определении нового кода
Поддержка Linux
Так как все наши тесты проводились на Windows 10 x64 (нам был нужен ipt.sys, который появился в Windows October Creators Update 2018), скажем несколько слов о возможности реализации подобного в Linux.
Вывод
Мы успешно справились с задачей получения трассы кода, исполняющегося в SMM, при помощи технологии Intel Processor Trace. Аналогичного результата можно было добиться при помощи дорогостоящего оборудования и ПО, которое продается не каждому. Нам же достаточно было иметь на руках одну материнскую плату и SPI-программатор. Скорость снятия трассы действительно впечатляющая, а к точности результата нет никаких претензий.
Мы надеемся, что эта статья поможет другим воспользоваться технологией Intel PT для изучения и поиска уязвимостей в коде SMM. Адаптация нашей работы к другим материнским платам не должна вызвать затруднений (не забудьте про Intel Boot Guard). Главное – полностью разобраться в том, как это устроено. Самое сложное – определить способ перехвата SMI-диспетчера и написать шеллкод для перехватчика. В нашем варианте использовались «вшитые» адреса, так что следует внимательно переносить шеллкод на другую систему.
Все использованные инструменты и скрипты доступны в репозитории на GitHub.
В любой системе возникает задача понять, как взаимодействуют компоненты между собой. Особенно важно это в распределённых системах. Как понять, какие компоненты обработали запрос, сколько времени это заняло, какой был порядок обработки. Всё это можно узнать, но нужно добавить немного инфраструктуры.
Егор Гришечко — работал разработчиком в компании 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 конференциям этого сезона.