# Телеметрия не доходит в Collector: OTLP gRPC, HTTP и endpoint

Диагностика: Телеметрия не доходит в Collector: OTLP gRPC, HTTP и endpoint. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/otlp-protocol-endpoint-mismatch/
Language: ru

OTLP/gRPC и OTLP/HTTP — разные способы передачи телеметрии. Совпадение адреса Collector не делает их взаимозаменяемыми. Проверьте protocol, port, TLS, bind address и HTTP signal path на обеих сторонах, прежде чем менять instrumentation приложения.

## Сохраните пару exporter и receiver

Запишите версию SDK/exporter, его effective endpoint и Collector receiver configuration. Убедитесь, что receiver включён в нужный service pipeline, а не только объявлен в YAML. Collector может слушать localhost, недоступный удалённому процессу. В контейнере localhost относится к его сетевой области, а не автоматически к соседнему сервису. Сохраните, откуда устанавливается соединение и какое имя действительно разрешается, чтобы ошибка адреса не смешивалась с ошибкой wire protocol.


[Официальный источник 1](https://opentelemetry.io/docs/specs/otlp/).

## Сопоставьте транспорт буквально

Стандартные порты OTLP/gRPC и OTLP/HTTP — 4317 и 4318 соответственно, но конфигурация может их переопределять. Порт — подсказка, а не автоматическое согласование протокола. Для HTTP используются соответствующие signal paths, например /v1/traces. Некоторые exporter settings принимают base endpoint, другие signal-specific URL; сверяйте поведение конкретного SDK. Не добавляйте путь вслепую, иначе можно получить двойной suffix. TLS должен совпадать с ожидаемым режимом listener и trust configuration клиента.


[Официальный источник 2](https://opentelemetry.io/docs/collector/configuration/).

## Разберите два похожих отказа

В учебном примере gRPC exporter направлен на HTTP listener 4318. TCP соединение может установиться, но корректный OTLP обмен не происходит. Во втором случае HTTP exporter использует адрес без нужного signal path и получает неожиданный HTTP status. Оба случая отличаются от отсутствия сети. Сохраните response/error category и проверенный receiver protocol, используя синтетическую телеметрию. Пример относится к observability transport, а не описывает внешний LLM API endpoint.

| Слой | Что проверить |
| --- | --- |
| TCP | Достижим ли адрес и порт |
| TLS | Совпадает ли режим и доверие |
| OTLP transport | gRPC или HTTP на обеих сторонах |
| Signal routing | Путь и включённый pipeline |

## Исправьте один endpoint

Согласуйте exporter и receiver, сохранив имя сервиса и остальной pipeline. После изменения проверьте startup logs Collector и фактический listener. Не открывайте все interfaces без необходимости: адрес bind должен соответствовать доверенной сетевой области. Для теста используйте один тип signal и минимальный exporter, затем верните обычный поток. Если подключение успешно, но данных нет в backend, дальнейшая диагностика относится к processors/exporters и downstream очереди, а не к исходной несовместимости транспорта.

## Проверьте прохождение до получателя

Подтвердите приём тестового signal receiver, его обработку и появление в предназначенном backend. Временное debug output помогает увидеть payload, однако не должно раскрывать секреты. Артефакт содержит версии, exporter setting, receiver protocol, TLS mode и результат каждой стадии. Сохраните различие между connectivity и delivery: открытый 4317 не доказывает правильный trace pipeline. После обновления SDK повторите проверку endpoint semantics, поскольку поддерживаемые настройки и поведение переменных могут отличаться между реализациями.

Связанные разборы: [gpu monitoring scorecard](/ru/journal/gpu-monitoring-scorecard/); [vllm localhost container port](/ru/journal/vllm-localhost-container-port/).