Skip to main content
Veriqa инструментирован стандартными примитивами .NET — System.Diagnostics.Metrics и System.Diagnostics.ActivitySource — и сам ничего никуда не экспортирует. Инструменты принадлежат компонентам; хост подписывается на них и решает, куда уходят данные. Имена на этой странице — публичный контракт: стройте на них дашборды и алерты.

​
Включить экспорт

Образ уже подписан на оба метра и оба источника спанов, а также на инструментацию ASP.NET Core, HttpClient и рантайма .NET. Экспорт включается, когда стандартная переменная OpenTelemetry указывает на коллектор:
Без переменной ничего не экспортируется. С ней метрики, трассы и логи уходят по OTLP; остальные стандартные переменные OTEL_EXPORTER_OTLP_* (протокол, заголовки) и OTEL_SERVICE_NAME читает сам OpenTelemetry SDK, как обычно.Собственного scrape-эндпоинта у образа нет — /metrics не существует. Для Prometheus направьте образ на OpenTelemetry Collector, а метрики отдавайте или отправляйте уже из него.

​
Метрики

​
Транзакции — метр Veriqa.Core.TransactionEngine

  • initiated считает транзакции, вошедшие в жизненный цикл; terminated — дошедшие до терминального состояния, каждую один раз: повторный терминальный переход дважды не считается.
  • duration — время жизни от создания до терминального состояния. Когда в цикле человек, его определяет то, как долго он отвечает, а не сервер.
  • Воронка входа — initiated против terminated с исходом completed; доля отказов — доля остальных исходов, кроме superseded: это повторная попытка, а не отказ, и она считается отдельно от failed, чтобы повторы не поднимали долю сбоев.
completed — намеренно не confirmed. Пользователю в мессенджере показывается «подтверждено»; движок записывает completed шагом позже, когда личность разрешена и сохранена. Поэтому вход, подтверждённый в канале, всё ещё может закончиться исходом failed.

​
Каналы — метр Veriqa.Core.ChannelAdapter

  • notice.failures — первый кандидат на алерт: растущий ряд означает, что пользователи не получают запрос подтверждения (notice_kind = message) или итоговый исход (notice_kind = outcome). error_code — код ошибки адаптера, всегда из реестра кодов.
  • start.unserved делает видимой тишину. Пользователь открыл устаревшую ссылку или отсканировал старый QR, а канал без настроенного текста ответа не отвечает ничего — счётчик всё равно растёт.
  • event.foreign_transaction — отправителю отвечают ровно так же, как на неизвестную транзакцию, поэтому ответ ничего не раскрывает. Устойчивый поток — кто-то перебирает чужие идентификаторы.
В тегах метрик нет идентификаторов. Теги не несут идентификаторов транзакции, сессии и пользователя канала, получателя и текста сообщения. Каждый тег — закрытый перечень, поэтому число временных рядов ограничено вашими каналами и значениями выше.

​
Трассы

Вход — это две трассы, а не одна. Пользователь отвечает через произвольное время после запроса, а мессенджер контекст трассы не передаёт, поэтому входящее событие открывает собственную трассу. Сшиваются они атрибутом: veriqa.transaction.trace_id на входящем спане хранит идентификатор трассы, создавшей транзакцию. Чтобы перейти от ответа к запросу входа, ищите в своём бэкенде по этому значению.
  • Для входа сохраняется идентификатор трассы запроса /connect/authorize. Если ваше приложение передаёт traceparent, это трасса вашего приложения.
  • Для серверного подтверждения это correlation_id, переданный вами в запросе.
  • То же значение пишется в поле CorrelationId записи аудита, так что журнал аудита и трассы соединяются им же.
  • Хост без трассировки для входа значения не сохраняет — идентификатор взамен не выдумывается, — и входящий спан остаётся без атрибута.
Как читать статус спана. Спан помечается Error при сбое, который заканчивается внутри покрываемой им операции; причина — в error_code. Незаданный статус значит «здесь сбой не закончился», а не «операция прошла успешно»: исход транзакции — в метриках и журнале аудита.
В режиме Polling входящего HTTP-запроса нет, и спана veriqa.channel.inbound тоже; спан veriqa.transaction.complete при этом открывается.

​
Логи

В self-hosted образе логи включаются тем же переключателем, что и остальные сигналы: при заданной OTEL_EXPORTER_OTLP_ENDPOINT они экспортируются по OTLP, с отформатированным сообщением и областями (scopes) логирования. Записи, сделанные внутри спана, несут идентификаторы его трассы и спана, так что строка лога ведёт к своей трассе. Что пишется и не пишется в логи и на каком уровне — в разделе Безопасность и обработка данных.

​
Health-эндпоинты

Это эндпоинты self-hosted образа. Каналы намеренно не входят в readiness: недоступный мессенджер не должен выводить рабочую реплику из ротации. Что /health/channels сообщает и чего не сообщает — в quickstart self-hosted.