Зависимости

Экран «Зависимости» показывает, с чем взаимодействует ваш сервис вовне — базы данных, кеши и другие HTTP-сервисы, которые он вызывает, — с числом вызовов, задержкой и долей ошибок по каждому. Дополнительная настройка не нужна: данные берутся из тех же трейсов транзакций/спанов, что уже описаны в разделе Производительность.

Где находится

Экран открывается по ссылке «Зависимости» в меню раздела «Производительность» — URL /projects/<id>/dependencies. Фильтр сверху — окно времени (пресеты или произвольный диапазон); «Применить» перезагружает страницу с новым окном.

Как выводятся узлы

Каждая зависимость строится из client-op спанов — спанов, которые SDK записывает при исходящем вызове сервиса, — отфильтрованных по трём видам:

• спаны db (либо db.sql / db.query) → группируются как база данных, подписываются по db.system (например, postgresql, mysql), если SDK его прислал.
• остальные спаны db.* (например, клиент кеша, проинструментированный как db.redis) → группируются как кеш, подпись — часть имени операции после db..
• спаны http.client (либо http.client.*) → группируются как http, подпись — целевой хост (server.address, либо домен из URL запроса).

Спаны группируются по паре (вид, цель): тысяча вызовов одного и того же Postgres-инстанса — одна строка, а не тысяча. Спаны http.server (сама транзакция, то есть входящие запросы) и чисто внутренние спаны в подсчёт никогда не входят — зависимостью считается только исходящий вызов.

Как читать карту и таблицу

Над таблицей — карта: ваш сервис в центре, хранилища (базы данных и кеши) колонкой слева, HTTP-зависимости колонкой справа. В каждом узле — имя цели и строка метрик «вызовы · p95 · доля ошибок»; слишком длинное имя усекается, полное видно при наведении. Ребро от сервиса к зависимости окрашено по доле ошибок (нейтральное, жёлтое, красное), поэтому падающая зависимость видна сразу; при наведении на ребро — полный набор метрик. Стрелки на рёбрах показывают направление данных. На карту попадают 16 самых частых зависимостей, остальные — только в таблице (под картой — пометка, сколько ещё). Ниже — те же данные таблицей:

Таблица ограничена по размеру (в неё попадают самые частые зависимости по числу вызовов); если их больше, над таблицей — пометка, сколько показано. Если в проекте ещё не настроен трейсинг или в окне не было записано ни одного client-op спана, вместо таблицы показывается пустое состояние или состояние ошибки — как включить трейсинг в SDK, см. Производительность → Как отправлять данные.

Направление данных

Стрелки на карте и колонка «Данные» в таблице показывают, куда течёт информация между сервисом и зависимостью:

• ← читаем — сервис получает данные из зависимости (стрелка смотрит на сервис);
• → пишем — сервис отправляет данные в зависимость (стрелка смотрит на зависимость);
• ⇄ и то и другое — за окно были и чтения, и записи;
• — — операции не распознаны, стрелки на ребре нет.

Направление выводится из глагола операции каждого спана. Берётся атрибут спана — db.operation.name (либо db.operation) у баз данных и кешей, http.request.method (либо http.method) у HTTP-вызовов; если атрибута нет, глаголом считается первое слово описания спана (например, SELECT из SELECT * FROM users). Регистр не важен.

Какие глаголы куда:

Глагол вне списков (BEGIN, COMMIT, MULTI, нестандартные команды) не считается ни чтением, ни записью. Если у зависимости за окно не оказалось ни одной распознанной операции, стрелки на ребре нет, а в таблице — прочерк. Разделение на «чтение» и «запись» намеренно грубое — оно про направление потока данных, а не про семантику операции: HTTP GET считается чтением, даже если на той стороне он что-то меняет.

Чем это НЕ является

Это не карта топологии сервис→сервис. Узел здесь — внешняя зависимость: база данных, кеш или исходящий HTTP-вызов, а не другой ваш собственный сервис. Если сервис A вызывает сервис B и оба проинструментированы, этот экран покажет со стороны A одно ребро «http: b.internal» — он не сшивает трейсы A и B в общий граф и не покажет собственные зависимости B. Полная многосервисная топология требует распределённого трейсинга, который прокидывает общий контекст трейса между сервисами (одиночное приложение или сервисы, не прокидывающие заголовки трейса друг другу, такую связь не дадут).