Что это tracing: Tracing — что это за папка?

Введение в distributed tracing / Хабр

В один прекрасный момент вы можете переезжать из одного ДЦ в другой и понять, что не знаете свои системы: их поведение может стать неожиданным. В одной системе вы должны были работать гораздо быстрее, но теперь работаете медленно. В другой — не понимаете, куда приходит запрос, а в третьей столкнетесь с новыми проблемами.

Чтобы проще и быстрее понимать взаимосвязи между системами и легко их оптимизировать, вам прекрасно подойдет distributed tracing. Но как его выбрать, внедрить и не собрать все грабли?

Безкоровайный Денис, директор подразделения DevOps/DevSecOps в Proto Group и Панычев Дмитрий, руководитель разработки в Vprok.ru Перекресток, на конференции DevOps 2021 на примерах показали, как distributed tracing помог им решить бизнес-задачи. Читайте под катом, как они выбирали решение для distributed tracing и обходили грабли.

Кейс №1: долгий отбор товаров на WMS 

Представьте себе: складская система WMS (warehouse management system), склад и сборщики заказов. Чтобы сборщики собрали заказ как можно быстрее, логистика по складу и ПО выстроены так, чтобы время сбора заказа было, во-первых, минимально, а во-вторых, предсказуемо. Чтобы у сборщика руки были свободны и ничего не мешало ему собирать заказ, на руке у него закреплен терминал сбора данных, а на пальце —  сканер штрих-кодов. А любая его операция в ПО работает быстро (и должна работать быстро).

Но в какой-то момент алертинг сообщает, что процесс сборки затягивается — вместо десятых долей секунды он стал занимать слишком много времени:

График взлетел практически до небес — от десятых долей секунды до десятков секунд.

Проблема воспроизводилась только на одном из складов, и, как ни странно, не самом большом. Посмотрев на трейс от инцидента, стало понятно, что с оборудованием на ТСД и шлюзом проблем нет:

Но зато была замечательная коричневая линия, которая показывала запрос к БД. При этом тот же самый запрос с теми же самыми данными на других сервисах выполнялся быстро: 

В итоге виновным оказался планировщик базы: для данного конкретного сервиса он немного изменил план выполнения запроса, в результате чего запрос стал ходить мимо индекса:

Инженеры создали новый индекс, прибили старый, и всё заработало: запрос стал, как и раньше, выполняться за миллисекунды. Но, исследуя проблему по классическому пути, без distributed tracing, найти корневую причину заняло бы больше времени, то есть сборка на складе стояла бы существенно дольше.

Кейс №2: сетевая связанность с SSO

В один момент стало понятно, что есть проблема: не всегда работает SSO, который лишь часть внешней аутентификации через X5 ID. Он находится во внешнем контуре, а само решение (и сервис аутентификации, в том числе) — в двух различных ЦОДах. Хоть и не везде, но SSO начал падать по таймауту, что означало: клиенты не смогут авторизоваться тем способом аутентификации, который выбрали.

С внедренной системой distributed tracing посмотрели трейс, и действительно: запрос падает по таймауту. Система мониторинга не обманывает:

Тем не менее специалист SRE не обнаружил на карте сервисов ошибок при обращении к конкретному сервису. А раз сервис не отдает ошибки, то все запросы к тому самому внешнему SSO завершаются успешно. Но зато в том же самом трейсе был таймаут коннекта к Sentry — в том же самом контуре, где лежал SSO. 

Благодаря этому картина стала достаточно ясной. Система, не получая ответ и падая по таймауту от SSO, пыталась записать проблему в Sentry. Но не могла до него достучаться, поэтому соединение с Sentry тоже падало по таймауту. Это происходило на некоторых нодах, и очевидно, эти ноды потеряли сетевую связанность с внешним контуром.

Проблему исправили, переключив балансировку на первый ЦОД, потому что сетевую связанность потерял на самом деле только второй ЦОД. На исследование проблемы хватило меньше одной минуты, вторая была потрачена на переключение. Оставшиеся проблемы были решены в течение некоторого времени, но больше система не пятисотила.

Вы, наверное, уже думаете, что это классная штука, хорошо бы ее себе внедрить. Но давайте немного погрузимся в теорию и посмотрим, как это работает.

Как работает distributed tracing

Итак, допустим, у вас есть несколько сервисов, которые друг с другом взаимодействуют. Чем сложнее становится инфраструктура и чем она более микросервисная, тем сложнее будет это взаимодействие. Сами сервисы при этом могут быть написаны на разных языках: Node, Java, Go, PHP или еще каком-то. Задача в том, чтобы вся цепочка взаимодействий предстала в наглядном, визуально понятном представлении:

Как правило, в реальной жизни примеры гораздо более сложные 

Чтобы получить такую цепочку, нужно еще немного углубиться в теорию, и начнем мы с понятия вызова. В рамках отслеживаемого процесса — обычно это запрос между двумя сервисами — вызов описывает деятельность. Как правило, в микросервисной среде нам важно понять, как один сервис общается с другим, с базой, с очередью, с Elastic или кэш-системой. То, что происходит внутри самого процесса в микросервисной среде — в рассматриваемом контексте менее интересно.

Каждый вызов при этом состоит из одного или нескольких спанов. А трейс состоит из одного или нескольких вызовов, объединяя их в одну цепочку. Эту концепцию и терминологию (трейсы, спаны и т.д.) довольно давно придумал и описал Google: «Dapper, Large-Scale Distributed Systems Tracing Infrastructure». А мы все теперь ее используем, в том числе, в концепции OpenTracing (The OpenTracing Semantic Specification).

Distributed Tracing: сущности

Когда некий сервис обращается ко второму сервису, то этот вызов сначала снимается с вызываемой системы, а потом он же — с вызывающей. В distributed tracing для этого есть понятия SpanId и TraceId — то, что вы как разработчик, сами прописываете, либо это автоматически делает какая-то другая система. В каждом спане есть основной и дочерние вызовы:

Мы понимаем, что вызов — дочерний, если он относится к тому же TraceId, который был в первом вызове, но его SpanId уже другой.

Чтобы понять, что эти несколько спанов относятся к одному вызову, используется TraceContext. Он описывает, какой из трейсов родительский,  какой — дочерний, и как они связаны друг с другом. Так, собрав два разных спана и склеив их вместе, мы можем понять, что это один и тот же вызов:

Например, GET /shop есть синий и желтый, но они оба описывают один и тот же вызов.

Зачем это всё нужно?

Distributed tracing — это тайминги и анализ производительности систем. Потому что, когда мы рассматриваем один и тот же вызов с разных сторон, склеивая все спаны в одну систему, то можем понять, сколько времени исполнялся каждый вызов и на что ушло это время:

Например, сколько времени один сервис ожидал вызова другого сервиса. Или мы понимаем, в какое время в сервисе была произведена какая-то работа — и мы знаем, сколько миллисекунд это заняло. Или же это была сетевая задержка. Причем необязательно при межсетевом взаимодействии, это могли быть задержки, связанные с межпроцессным взаимодействием или чем-то еще.

Если описывать коротко, то distributed tracing — это способ понять распределенную систему, что в ней происходит и какие сервисы как обрабатывают запросы:

• Через какие сервисы проходят запросы? Например, через какие сервисы проходит один запрос?

• Сколько времени обрабатываются запросы в том или ином сервисе?

• Если есть какие-то проблемы, то где именно они возникают в распределенной системе?

Также distributed tracing напрямую связан с KPI производительности — таким, как Golden Signals:

По сути, из анализа результатов работы distributed tracing можно получить данные, которые отвечают на вопросы:

• Какой процент вызовов завершились ошибкой?

• Какая длительность исполнения транзакций по 90-му перцентилю?

• Сколько вызовов в секунду обрабатывает сервис X?

В принципе, их можно взять просто как метрики, но по сути, вы можете косвенно, на основе анализа трейсов, эти метрики сразу получить. А это уже часть observability.

Distributed tracing – часть observability

Как мы знаем, observability — это логи, метрики и трейсы. Но не только это, а еще и контекст, в котором все эти данные обрабатываются и интерпретируются. Как правило, в трейсах уже содержится какая-то информация, связанная с ошибками. Практически все реализации distributed tracing собирают ошибки и логи напрямую с приложения, либо их можно туда отправить вручную.

То есть, внедрив distributed tracing, вы уже больше чем на треть приближаетесь к observability, потому что и метрики, и логи также можно получить из трейсов. 

Зачем тогда нужно observability? Мониторинг — это некий реактивный процесс: мы отвечаем на вопросы: что и когда сломалось, и, как правило, уже после того, как оно сломалось. В случае observability мы действуем проактивно и, как правило, отвечаем на более сложные вопросы: почему сломалось, как сломалось и как предотвратить, чтобы не ломалось дальше.

В случае кейса про SSO и сетевую связанность observability поможет не только быстро обнаружить виновника и причины проблемы, но и быстро, если не исправить проблему, то начать действовать и свести проблему к минимуму. Потому что distributed tracing — это не только метрики производительности. Есть замечательная метрика time to repair, и distributed tracing позволяет уменьшить время, которое необходимо на восстановление системы в работоспособном состоянии. Поэтому это очень важно для DevOps и SRE.

Distributed Tracing – плюсы использования для Dev и SRE

• Понимание всей картины распределенной системы;

• Детальный анализ прохождения запросов;

• Выявление узких мест;

• Возможность просмотреть транзакцию целиком.

Это такой helicopter view на всё. Но при этом вы можете как под микроскопом рассмотреть каждую конкретную транзакцию и понять, как проходит запрос в том или ином сервисе, какие есть узкие места. Ключевое — это понять, как улучшить систему, смотря на нее — с помощью distributed tracing — от общего обзора до мелких деталей. 

Что выбрать для distributed tracing

Чтобы понять, что лучше — купить инструментарий, сделать его самим или поискать OpenSource — определитесь с критериями. Например, инженерам Впрока нужно было внедрить distributed tracing быстро, но при этом покрыть весь имеющийся у них разнородный стек технологий. Для идеальной реализации вся система также должна была быть стабильной и поддерживаться вендором, а команда — обладать достаточным опытом работы с ней.

Если говорить про ручную инструментацию, даже на базе готовых инструментов — то это достаточно долго и дорого относительно тех ресурсов, которые необходимо потратить. И наконец, у компаний, которые пошли по этому пути, обычно есть проблема: когда запрос проходит через множество разных сервисов, часть которых еще не покрыта, то ценность distributed tracing сильно падает. То есть это нетривиальная задача: написать самим всё и сразу, особенно когда реализовать нужно достаточно быстро  — как это было во Впроке. Поэтому они выбрали коммерческое решение.

В принципе, на рынке есть несколько подходов к distributed tracing, чтобы всю инструментацию за вас делали агенты:

Возможно, теперь вы думаете, что реализация distributed tracing должна пройти без проблем, но на самом деле в таких проектах есть большое количество подводных камней, сложностей и граблей.

Проблемы и сложности при внедрении distributed tracing

Вот краткий список граблей, с которыми столкнулись инженеры Впрока.

Сложности

Если говорить про инструментацию всего, то это огромные объемы данных, которые генерит система distributed tracing. Кто-то для снижения нагрузки решает эту проблему сэмплированием трейсов. Но это не дает гарантии того, что когда вам нужно найти проблему, вы найдете именно ту транзакцию, тот трейс, который вам нужен.

Другая проблема связана с детализацией трейсов. Если у вас неполное покрытие, то вы не видите какую-то критичную часть, через которую проходит ваш запрос, и по сути, ценности очень сильно теряются.

Естественно, когда вы сами внедряете систему, нужно постоянно думать про TraceContext, не забывая его делать. Это решается частично шаблонами ваших микросервисов, но все равно это время разработчика, которое нужно затратить на инструментацию этих вещей.

Если говорить про стандарты, то не всегда они стыкуются с их конкретными реализациями, потому что одни и те же вещи можно назвать по-разному. Разные команды разработки могут использовать разные нотации. Хотя по сути данные одни и те же, но у них, например, разные названия тегов, и поэтому всё вместе сложно склеить, как и анализировать. Даже используя одни и те же, казалось бы, стандартизированные вещи, все равно можно столкнуться с разным подходом к реализации.

И, конечно, существуют риски, как в любом проекте: сроки, ресурсы и влияние на стабильность приложения. Посмотрим на примерах Впрока.

Нагрузка на CPU на проде

Что случилось? В один прекрасный момент на app-нодах (PHP) начало расти потребление CPU со временем, причем пропорционально нагрузке и достаточно непонятно.  При отключении агента всё возвращалось в норму

Кто виноват? От глубокого и долгого исследования инженеров спасло, во-первых, понимание, что агент — это JVM. Они знали об особенностях работы ее с процессором в некоторых случаях. А во-вторых — то, что сами по себе агенты были раскатаны на 20% нод. Всё это помогло достаточно быстро выявить прямую корреляцию агента с потреблением CPU. 

Что сделали? Во-первых, поставили reboot, чтобы после него JVM некоторое время она не перегружал процессор. На некоторых нодах reboot поставили раз в 3 часа. После чего стали разбираться с вендором и выяснили, что архитектура самого агента под этот кейс не совсем подходит. Потому что именно в этих условиях он архитектурно будет себя вести себя именно так. 

У агента отключили ряд функций, после чего вендор достаточно долго дорабатывал и пересматривал его архитектуру. И после того как выкатили обновленную версию агента с новой архитектурой, больше таких проблем не воспроизводится. Это ясная и понятная проблема, с которой может столкнуться каждый, кто внедряет в свои продовые процессы стороннее решение.

Автообновление агента на проде

Что случилось? Начал пятисотить сервис аутентификации, причем только он, иногда, и в Kubernetes. Но примерно 1 из 200 пользователей мог аутентифицироваться только со второго раза.  

Кто виноват? Ситуация не была такой уж очевидной — в APM, Sentry и логах ничего криминального не было. Разбирались достаточно долго, пока один из SRE-инженеров не попал на конкретный трейс процессов в момент исполнения, где неожиданно обнаружил следы агента. Когда отключили APM и distributed tracing, то внезапно пятисотки прекратились. Но у нас же везде то же самое, у нас же везде стоит — в чем проблема?

Все оказалось достаточно просто: агент конкретного решения автоматически обновляется в кластере k8s в случае, если не указано иное, если не зафиксирована версия. А новая версия агента приводила в некоторых случаях к крашу приложения. Да, ребята забыли, что версию нужно зафиксировать. Они фиксировали их на предыдущих сервисах, этот сервис был инструментирован позже. К тому же они не думали, что кому-то в здравом уме придет в голову что-то автоматически обновлять на чужом проде.

Что сделали? Зафиксировали версию агента, и проблема была решена. Коллег из этого конкретного решения попросили отключить обновление для всех.

Остаться без мониторинга?

APM — это круто и здорово, но альтернативные системы также нужны. Любое решение, которое полностью поставляет всю информацию о ваших сервисах и системах (особенно на достаточно небольших и достаточно простых инфраструктурно проектах), иногда может приводить к вопросам: а зачем нам другой мониторинг, зачем нам его вообще поддерживать? 

Но если падает APM, то есть вариант остаться вообще без мониторинга. Во Впроке был случай, когда на 20-30 минут инженеры остались без мониторинга, потому что одновременно с ним упал и APM. Такая ситуация возможна, и от нее нужно страховаться по максимуму.

Нужно больше места!

Абсолютно каждый запрос записывает всё, что он делает. И для хранения этого объема, как его ни архивируй, как ни складывай, необходимо очень много места. В Перекрестке уже не так, но когда-то было прямо совсем тяжело.

Сейчас это порядка 30 Тб, но не с очень большим горизонтом хранения полностью детализированной информации для быстрого анализа — порядка 6-7 дней. Агрегированная информация хранится до 3-4 месяцев. При этом эти 30 Тб — это быстрые диски, поэтому это не всегда дешево.

Подведение итогов

На скриншоте слева обратите внимание на время — это 5:00 утра. Для экстренных собраний Впрок использует Discord, и некоторое время назад, когда еще не все сервисы были инструментированы, в пять утра можно было наблюдать две группы людей в двух переговорных. Сейчас инженеры стали спать лучше и больше:

В заключение хотелось бы сказать, что distributed tracing — очень эффективный инструмент для:

• Ответа на вечный вопрос «Кто виноват?» Distributed tracing помогает это понять до конкретного сервиса, эндпойнта и даже транзакции. А если есть интеграция с системой релизов, то и до конкретного человека.

• Понимания работы системы во всех её взаимосвязях. Чем более сложна ваша система, тем больше выгоды компания получает от внедрения distributed tracing в том или ином виде.

• Поиска узких мест. От общего вида (helicopter view) можно углубиться и под микроскопом посмотреть каждую транзакцию, каждое узкое место. Понять, почему оно узкое, сколько запросов обрабатывается, где конкретно проблема, избавиться от этих узких мест — и лучше и больше спать.

Видео выступления Дениса и Дмитрия на конференции DevOps Conf 2021:

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации — DevOpsConf 2022 — пройдет 9 и 10 июня в Москве, в Крокус-Экспо, совместно с TechLead Conf.

Обсудим инженерные процессы в IT от XP до DevOps & Beyond, must have инструменты и практики изменений в командах для быстрых и качественных релизов. Программный комитет сейчас в процессе формирования расписания. А пока вы можете посмотреть отобранные доклады и купить билеты.

Трассировка лучей что это и как работает в играх, Ray tracing в видеокартах NVIDIA и AMD

Содержание

1. Что такое Трассировка лучей или Ray tracing?
2. Принципы работы
3. Как включить трассировку лучей в игре?
4. Какие улучшения привносит рейтрейсинг?
5. Отражения
6. Тени
7. Окклюзия окружающей среды
8. Каустика
9. Глобальное освещение
10. Рейтрейсинг на видеокартах NVIDIA и AMD
11. Преимущества и недостатки рейтрейсинга
12. Будущее игровой графики — за рейтрейсингом?

Трассировка лучей как метод рендеринга оставалась долгое время инструментом только кинопроизводства, но с появлением новых высокопроизводительных графических чипов теперь и игровая индустрия претерпевает значительный скачок в плане реализма, благодаря реализации этой технологии в современных играх.

Что такое Трассировка лучей или Ray tracing?

Трассировка лучей или рейтрейсинг — это метод рендеринга в видеоиграх, позволяющий максимально точно имитировать отражение света от объектов, что в свою очередь создает более реалистичные тени, отражения и световые эффекты.

Впервые об исследованиях трассировки лучей и искусственного интеллекта и их применении в визуализации графики заговорили в 80-х годах прошлого века. Однако проблема заключалась в нехватке вычислительной мощности процессоров тех времен. Потребовалось несколько десятилетий для появления таких видеочипов, как NVIDIA Turing, которые ликвидировали этот пробел и позволили воплотить идеи прошлого в жизнь.

Принципы работы

В реальности все, что находится в поле нашего зрения, по сути, является результатом попадания света на объекты, которые мы наблюдаем. Различная степень поглощения, отражения и преломления света этими объектами формирует картинку для человеческого глаза.

Трассировка лучей представляет собой фактически обратный процесс, о чем свидетельствует само название: это метод создания изображения с помощью компьютера путем «отслеживания» пути света от воображаемого глаза или камеры к объектам на этом изображении.

Алгоритм трассировки лучей учитывает как тип материала, так и источник света. Например, два баскетбольных мяча одинакового оттенка не будут выглядеть одинаково, если один выполнен из кожи, а другой из резины, потому что свет будет взаимодействовать с ними по-разному. Объекты, попадающие на пути любых световых лучей, будут отбрасывать тени. А прозрачное или полупрозрачное вещество, такое как стекло или вода, будет преломлять свет.

Для понимания метода трассировки лучей представим сетку на схеме как монитор компьютера. Чтобы визуализировать сцену из современной видеоигры, компьютер отображает трехмерный виртуальный мир игры на двухмерной плоскости — мониторе. При этом компьютер должен определить цвет для каждого пикселя на экране.

Процесс начинается с проецирования одного или нескольких лучей со стороны наблюдателя и проверки на пересечение лучами треугольников — составных частей виртуальных объектов в компьютерной графике. Если луч действительно попадает в треугольник, алгоритм использует такие данные, как цвет треугольника и его расстояние от наблюдателя, чтобы вычислить финальный результат — цвет пикселя.

Кроме того, лучи могут отражаться от треугольника или проходить через него, создавая все больше и больше лучей, которые также нужно учесть. Чем больше таких лучей, тем выше качество изображения, но вместе с тем требуется больше вычислительных ресурсов.

Как включить трассировку лучей в игре?

Одной из первых игр, поддерживающих трассировку лучей, стала компьютерная инди-игра Minecraft.

На ее примере рассмотрим, как включить или отключить рейтрейсинг в настройках игры.

1. Запустите игру через Microsoft Store, нажав кнопку Play;
2. Нажмите на пункт Marketplace в главном меню Minecraft;Кликните по лупе в строке поиска и введите «RTX»;
3. Выберите любой из официальных пакетов RTX от Nvidia и установите его;
4. Вернитесь в главное меню и нажмите «Играть»;
5. Нажмите «Создать» и выберите один из шаблонов RTX World;
6. После загрузки нажмите ESC и перейдите в «Настройки» и «Видео»;
7. Прокрутите страницу вниз и убедитесь, что ползунок напротив пункта «Ray Tracing» находится в активном состоянии.

В зависимости от модели видеокарты, расстояние рендеринга трассировки лучей по умолчанию может быть меньше 24. Измените этот параметр по своему усмотрению, чтобы изменить расстояние трассировки лучей и найти баланс между качеством графики и частотой кадров.

Какие улучшения привносит рейтрейсинг?

Отражения

Методы рендеринга, применяемые раньше, как, например, Screen Space Reflections (SSR), обладали некоторыми изъянами — это в первую очередь невозможность отображать предметы, не находящиеся в определенный момент в кадре. В рейтрейсинге же учитывается весь трехмерный мир, тем самым обеспечиваются максимально точные отражения.

Из-за отсутствия отражающей способности некоторых поверхностей эффект зачастую не столь заметен, но при этом ресурсозатратен. Для осуществления задач рейтрейсинга по отражениям необходим как минимум один луч на отражающий пиксель.

Тени

Наряду с прорисовкой отражений есть целый ряд приемов моделирования теней методами рейтрейсинга. Чтобы понять, как формируется изображение, достаточно представить исходящий луч в сторону источника света. Если исходящий луч попадает на поверхность предмета, прежде чем доберется до источника света, такой пиксель должен приобрести более темный оттенок. При вычислениях учитываются как расстояние до источника света, так и яркость, и цветовая температура.

Рейтрейсинг способен в том числе реалистично отбрасывать тени сквозь прозрачные поверхности, такие как разного рода ткани. В результате таких вычислений получаются более мягкие и точные тени со сложной неструктурированной полутенью.

Окклюзия окружающей среды

Модель затенения позволяет повторять сероватые тени, наблюдаемые в углах, щелях и небольших местах внутри и вокруг предметов. Алгоритм работает путем наблюдения за рядом коротких лучей в пределах одной области и проверки их на факт пересечения с ближайшими объектами — чем больше таких пересечений, тем более темной будет эта область.

Каустика

Трассировка лучей открывает возможность визуализировать результат отражения и преломления света, отраженного от изогнутых поверхностей. Каустики вычисляются по аналогии с обычными отражениями. Метод сводится к тому, что генерируются лучи, выделяются места их взаимодействия с поверхностью и рисуются отражения и преломления.

Несмотря на то, что 2D-каустика не требует существенных вычислительных мощностей, 3D-каустика может уже значительно нагрузить видеокарту.

Глобальное освещение

Отрисовка освещения — самое важная и при этом наиболее ресурсоемкая часть метода трассировки лучей. В ходе работы алгоритм отбрасывает лучи попиксельно на всю сцену и следит за всеми трансформациями, чтобы учесть даже малейшие изменения освещения.

Рейтрейсинг на видеокартах NVIDIA и AMD

NVIDIA. Для поддержки метода рендеринга видеокарты NVIDIA серии RTX 20 оборудованы специальным аппаратным решением, созданным для трассировки лучей. Архитектура Turing от NVIDIA на графических процессорах серии 20 использует ядра RT наряду с ядрами CUDA и Tensor от NVIDIA. Ядра RT предназначены исключительно для обработки трассировки лучей в реальном времени.

Выделенные ядра RT в графических процессорах серии RTX 20 на первый взгляд больше подходят для обеспечения рейтрейсинга, однако производительность такого решения оказалась недостаточной. Даже карта 2080Ti последнего поколения не справлялся с поддержкой игр с трассировкой лучей при запуске.

Новые графические процессоры RTX 3080 и 3090 имеют усовершенствованные ядра RT, благодаря чему достигается существенный прирост производительности. Эти карты не только быстрее, чем их аналоги последнего поколения — новые ядра RT также превосходят своих предшественников.

AMD. В течение последних нескольких лет AMD в своих продуктах пыталась обеспечить трассировку лучей с аппаратным ускорением, что по итогу вылилось в выпуск видеокарт серий RX 6800, 6800 XT и 6900 XT. Эти новые графические процессоры поддерживают трассировку лучей DirectX 12 и обеспечивают отличную производительность, хотя AMD пока все еще уступает NVIDIA в области трассировки лучей.

Кроме того, архитектура Big Navi, на которой работают карты AMD RX 6000, в значительной степени стала первым решением с поддержкой трассировки лучей. Это та же архитектура, которая обеспечивает визуальные эффекты в PlayStation 5 и Xbox Series X, обеспечивая в целом более низкий уровень производительности, чем флагманские карты NVIDIA.

Однако поскольку трассировка лучей все еще остается функцией консолей следующего поколения, значительное улучшения поддержки и оптимизации ожидается уже в обозримом будущем с появлением AMD FidelityFX Super Resolution (FSR) для игровых ПК, а также последних версий Microsoft Xbox.

Трассировка лучей быстро становится предпочтительным способом рендеринга. Одним из преимуществ трассировки лучей является то, что это более реалистичный режим рендеринга. Многие физически правильные явления можно легко смоделировать с помощью алгоритма трассировки лучей, поскольку алгоритм имитирует движение света в реальном мире.

Во многом этому способствуют значительные достоинства этого метода:

Поддержка рендеринга гладких объектов напрямую без вспомогательного полигонального приближения;

Возможность параллельной трассировки лучей, что существенно ускоряет вычисления;

Сложность сцены в трехмерном мире менее выраженно коррелируется со сложностью вычислений.

С другой стороны, по-прежнему огромным недостатком метода трассировки лучей является его скорость, которая сказывается на производительности в играх. Трассеры лучей и по сей день работают довольно медленно. В этой области проводится большая работа по распараллеливанию и разного рода оптимизации, однако вычислительная мощность оборудования играет гораздо большую роль в скорости рендеринга, чем возможные программные решения этой проблемы. Из соображений повышения производительности большинство 3D-приложений используют гибрид движков рендеринга с трассировкой лучей и сканирования строк.

Будущее игровой графики — за рейтрейсингом?

Трассировка лучей в реальном времени в видеоиграх только зарождается. Видеокарты NVIDIA RTX в настоящее время являются единственными графическими процессорами потребительского уровня, которые предлагают аппаратную поддержку этой технологии, поэтому количество игр, использующих эту функцию, невелико.

Но по мере того, как все больше и больше производителей начнет внедрять технологии рейтрейсинга, реализм в видеоиграх со временем может выйти на совершенно новый уровень. Вполне вероятно, что со временем AMD догонит своего конкурента в области рейтрейсинга, что создаст прочную основу для разработчиков игр и вескую причину для создания игр, поддерживающих функции трассировки лучей. В свою очередь в перспективе даже 5-10 лет это сулит будущим играм достичь беспрецедентного уровня реализма

Что такое трассировка? Все, что вам нужно знать

Трассировка или, точнее, распределенная трассировка или распределенная трассировка запросов — это возможность отслеживать запросы через систему, соединяя точки между всеми отдельными системными вызовами, необходимыми для обслуживания конкретного запроса.

Хотя журналы трассировки существуют уже некоторое время, тенденция к распределенным архитектурам, микросервисам и контейнеризации подняла их статус из разряда «хорошо иметь» в важный элемент головоломки наблюдаемости.

Для разработчиков программного обеспечения, групп SRE и инженеров DevOps, управляющих сложными распределенными системами, состоящими из десятков взаимозависимых сервисов, с несколькими экземплярами каждого из них, развернутыми через контейнеры в сочетании эфемерной облачной инфраструктуры и локальных серверов.

Наличие механизма, позволяющего понять поток логики и данных, необходимо для обслуживания и устранения неполадок.

Трассировки составляют один из трех столпов наблюдаемости, наряду с журналами и метриками. В то время как журналы предоставляют сведения о конкретных событиях, таких как отдельный вызов базы данных и запись в файл или сообщение об ошибке, трассировка соединяет цепочку связанных событий. Одна трассировка предоставляет сведения о каждом шаге, через который прошел запрос, количество времени, затраченное на каждый шаг, и общее время, затраченное на обработку запроса.

Представьте себе HTTP-запрос к веб-серверу: один запрос может породить несколько подзапросов к разным службам, которые необходимо выполнить, прежде чем можно будет обслужить ответ.

Это может включать получение соответствующего файла HTML, выполнение сценариев на стороне сервера, выполнение запросов к базе данных для заполнения определенных элементов страницы. В то время как журналы предоставляют подробные сведения о действиях, выполняемых каждой службой в процессе, ведение журнала трассировки обеспечивает полную запись цепочки событий, инициированных первоначальным запросом.

Эта информация бесценна для отладки сложных проблем, выявления узких мест в производительности и оптимизации дизайна вашей системы.

Запросить демонстрацию

Как работает трассировка?

Трассировка — это набор связанных событий, инициированных входными данными, такими как нажатие пользователем кнопки или запрос, сделанный внешней системой. Индивидуальная трассировка состоит из нескольких интервалов, и каждый интервал представляет собой операцию, выполненную в связи с инициирующим запросом.

При запуске трассировки создается родительский или корневой диапазон для инкапсуляции всей транзакции. Например, пользователь, нажимающий кнопку для размещения заказа на сайте электронной коммерции, обычно представляет собой такую ​​транзакцию, а корневой диапазон представляет всю транзакцию.

Предположим, транзакция включает несколько операций, таких как проверка подлинности пользователя, запрос к базе данных для подтверждения доступности продукта и получение сведений об учетной записи пользователя. В этом случае для каждой операции создается дочерний диапазон.

В случае дальнейшего сбоя операции, например при запросе службы авторизации, каждый потомок представляется внучатым диапазоном. Вы можете представить интервалы как иерархическую древовидную структуру, которая начинается с корневого интервала, с потомками для каждой зависимой операции и ветвями для операций, которые выполняются параллельно.

При создании корневого диапазона ему присваивается контекст или идентификатор, который распространяется на каждый дочерний диапазон. В дополнение к идентификатору каждый диапазон обычно записывает время начала и окончания операции вместе с необязательными дополнительными атрибутами, такими как идентификатор экземпляра службы. Этот процесс позволяет идентифицировать каждый запрос, вызов и процесс, составляющие конкретную транзакцию, порядок их выполнения и время, которое занимал каждый этап.

Преимущества отслеживания

Одним из основных преимуществ распределенной трассировки является возможность проследить путь транзакции от начала до конца. В традиционной монолитной архитектуре отследить ход запроса относительно просто.

Однако переход к распределенным контейнерным архитектурам, предлагающим множество преимуществ с точки зрения масштабируемости, простоты и скорости развертывания, значительно усложнил эту задачу.

Реализуя распределенную трассировку, вы можете отобразить весь поток запроса — даже за пределами сети и контекстов безопасности — и идентифицировать его составные части. Что касается отладки сложных проблем, эти данные трассировки могут помочь вам быстро определить источник проблемы и определить, на каких журналах трассировки следует сосредоточить свое внимание, сократив среднее время решения (MTTR).

Поскольку каждый интервал в трассировке записывает время начала и окончания операции, трассировки особенно эффективны для выявления зависимостей и узких мест в производительности. Используя трассировки для определения запросов, которые занимают больше всего времени, вы можете детализировать, чтобы определить, какие этапы процесса занимают больше всего времени, и определить, способствуют ли зависимости от других служб задержке.

Одним из преимуществ распределенных архитектур является то, что группы разработчиков программного обеспечения могут разрабатывать и развертывать изменения параллельно. Хотя это имеет много преимуществ, это может привести к разрозненности внутри предприятия.

Из-за меньшей видимости и понимания других элементов, составляющих приложение, командам становится все труднее понять, как их изменения влияют на другие части системы. Внедрение распределенной трассировки может помочь смягчить это, предоставляя более четкое представление о том, как отдельные части образуют единое целое.

Наконец, благодаря использованию распределенной трассировки как части решения для наблюдения, вы можете начать пожинать плоды сокращения времени отклика. Повышение уверенности в вашей способности быстро выявлять проблемы и реагировать на них означает, что вы можете начать выпускать изменения чаще и использовать это как возможность для проведения экспериментов, таких как тестирование новых функций с подмножеством пользователей.

Рекомендации по распределенной трассировке

Хотя распределенная трассировка предлагает множество преимуществ, необходимо помнить о некоторых потенциальных проблемах.

Генерация идентификаторов, их распространение на дочерние диапазоны и отправка данных этого диапазона в хранилище данных может повлиять на производительность и привести к созданию значительных объемов данных. По этой причине рекомендуется отслеживать репрезентативную выборку запросов, а не отслеживать журналы каждой транзакции.

Выборка может быть реализована двумя способами: на основе головы и на основе хвоста. При выборке на основе головы решение о том, следует ли отслеживать транзакцию, принимается при ее инициировании. Если это так, идентификатор трассировки будет распространяться на каждый диапазон. Способ принятия решения о выборке зависит от конфигурации выборки.

При использовании хвостовой выборки отслеживание применяется к каждой транзакции, и решение о том, какие запросы на выборку принимаются постфактум. Хотя это временно увеличивает хранилище, вы можете провести некоторый анализ, прежде чем выбирать, какие трассировки сохранить.

Инструменты для распределенной трассировки

Как и в случае с журналами и метриками, вам необходимо настроить код вашего приложения для создания трассировок и отправки их в серверную часть хранилища, чтобы сделать их доступными для анализа.

По мере того, как распределенная трассировка развивалась как практика в сообществе разработчиков программного обеспечения, вскоре была осознана необходимость в стандартизированных форматах данных и инструментах, чтобы избежать привязки к конкретному инструменту.

OpenTelemetry (ранее OpenCensus и OpenTracing), управляемый Cloud Native Computing Foundation, предоставляет этот открытый стандарт. OpenTelemetry включает инструментальные библиотеки для наиболее часто используемых языков программирования и поддержку экспорта трассировок (и других данных для наблюдения) в несколько открытых и проприетарных бэкэндов.

Выбор инструмента, соответствующего стандарту OpenTelemetry, означает, что в будущем вам будет проще менять поставщиков, не меняя реализацию трассировки. Популярные примеры с открытым исходным кодом включают Zipkin и Jaeger. Если вы используете AWS для размещения своей распределенной системы, вы можете рассмотреть инструмент Coralogix с полным стеком наблюдения.

Запросить демонстрацию

Резюме

Внедрение наблюдаемости в ваши системы может дать множество преимуществ. Сочетание журналов и метрик с распределенной трассировкой предоставит вам богатый набор данных, который вы можете использовать для наблюдения и понимания того, как ведут себя ваши приложения.

Вооружившись этим более глубоким пониманием того, как работает ваша система, вы сможете гораздо быстрее реагировать, когда что-то пойдет не так. Определив возникновение проблемы, трассировки соединяют точки между операциями, чтобы вы могли перейти к источнику проблемы и отточить журналы трассировки, которые предоставят дополнительные сведения, необходимые для отладки проблемы.

Хорошая видимость состояния вашей системы и способность быстрее реагировать на проблемы также снижают риск развертывания изменений, открывая возможности для инноваций и экспериментов.

Трассировка, регистрация и мониторинг: в чем разница? – BMC Software

Независимо от того, являетесь ли вы системным администратором или разработчиком, вам вскоре захочется понять, как работает ваше программное обеспечение. От отдельного микросервиса до обширной монолитной системы ведение журнала, отслеживание и мониторинг — все это способы помочь обеспечить правильность вашей системы, отследить, что могло пойти не так, когда возникают проблемы, и улучшить общую функциональность.

Важно отметить, что ведение журнала, трассировка и мониторинг не являются разными словами для обозначения одного и того же процесса. Каждый из них работает уникальным образом. Даже если некоторые инструменты или технологии пересекаются, каждый процесс обеспечивает разные результаты для вашей ИТ-среды. Давайте взглянем.

Что такое ведение журнала?

Целью ведения журнала является централизованное отслеживание отчетов об ошибках и соответствующих данных. Ведение журнала следует использовать в больших приложениях, и его можно использовать в небольших приложениях, особенно если они выполняют важную функцию. Термин ведение журнала может относиться как к практике ведения журнала событий, так и к фактически полученным файлам журнала.

Файлы журналов могут отображать любое дискретное событие в приложении или системе, например сбой, ошибку или изменение состояния. Когда что-то неизбежно идет не так, такие преобразования в состоянии помогают указать, какое изменение на самом деле вызвало ошибку.

Ведение журнала в основном развертывается и используется системными администраторами на операционном уровне, преднамеренно предоставляя представление высокого уровня. Самые успешные лог-файлы не зашумлены; они не должны содержать посторонней или отвлекающей информации. Вместо этого файлы журнала должны регистрировать только то, что абсолютно необходимо, например элементы, требующие действий.

Из этих элементов, связанных с действиями, у вас могут быть два типа данных:

• Данные для нас, людей, которые предупреждают или предупреждают о ситуации паники (достаточно, чтобы начать расследование, но не подавляющее количество)
• Структурированные данные для машин (Некоторые спорят о том, нужны ли эти данные машинного уровня, но безопасность — это хороший случай.)

Учтите, что регистрация должна рассказывать убедительную историю, но как можно более кратко. Выбирая, что записывать, учитывайте:

• Кто использует журналы (обычно системные администраторы)
• Помогает ли ведение журналов только в профилактических мерах или в текущих исследованиях
• Все ли системные ошибки одинаковы, или предупреждение в определенной области служит предупреждением о критической ошибке в другом месте ?

Другие характеристики успешных журналов:

• Выходные данные часто основаны на стандартах
• Журналы локализованы
• Новые события не обязательно должны быть гибкими Действительно, передача, хранение и анализ журналов обходятся дорого, поэтому минимизация содержания файлов журналов может минимизировать затраты и ресурсы. Тем не менее, ведение журнала — это главное, особенно когда речь идет о традиционных монолитных архитектурах.

  Что такое трассировка?

  В то время как ведение журнала обеспечивает обзор дискретного, инициируемого событиями журнала, трассировка охватывает гораздо более широкое непрерывное представление приложения. Цель трассировки — следить за ходом программы и движением данных. Таким образом, в игре гораздо больше информации; трассировка может быть намного более шумной, чем регистрация, и это сделано намеренно.

  Во многих случаях трассировка представляет собой путешествие одного пользователя по всему стеку приложений. Его цель не реактивна, а сосредоточена на оптимизации. Отслеживая стек, разработчики могут выявить узкие места и сосредоточиться на повышении производительности.

  Когда возникает проблема, трассировка позволяет увидеть, как вы к ней пришли:

  • Какая функция
  • Продолжительность функции,
  • Переданные параметры
  • Насколько глубоко пользователь может проникнуть в функцию инструмент — это API профилирования в . NET.

    В идеальном мире для каждой функции включена трассировка. Но количество результирующих данных может быть слишком большим для сортировки, хотя облачные технологии, безусловно, помогают отслеживанию стать реальным вариантом на большее время. В отличие от регистрации, локализация не имеет значения, но новые сообщения должны быть гибкими.

    К другим недостаткам относятся:

    • Сложные слои
    • Изобилие кода реализации
    • Модель push, общий дизайн, который может повлиять на приложения быть более сложным, чем код, который они обслуживают. Иногда трассировка лучше всего подходит для микросервисов.

      Из-за задействованных данных отслеживание может быть дорогостоящим мероприятием. Прежде чем приступить к трассировке, помните, что это не является обязательным требованием. Вы захотите подумать, оправдана ли дополнительная сложность, какую ценность она принесет? Вы можете попасть в ловушку преждевременной оптимизации или сможете масштабироваться по горизонтали и какое-то время избегать такой оптимизации.

      Что такое мониторинг?

      Хотя мониторинг может быть случайным термином, который может применяться к отслеживанию, регистрации или ряду других действий, в этом контексте мониторинг является гораздо более конкретным: инструментирование приложения, а затем сбор, агрегирование и анализ показателей для улучшения вашего понимания. того, как ведет себя система.

      Этот тип мониторинга в первую очередь носит диагностический характер — например, предупреждение разработчиков о том, что система не работает должным образом. В идеальном мире, где стоимость не является проблемой, вы могли бы измерять и контролировать все свои услуги

      Системы мониторинга — лучший способ начать использовать метрики. Такие системы обеспечивают хранение, агрегацию, визуализацию и даже автоматические ответы. Эти системы мониторинга на удивление доступны по цене, хотя они в значительной степени зависят от данных. Поскольку компании используют облачные технологии и данные, чем больше у вас данных, тем полезнее может быть мониторинг.