В этом материале
OTLP/gRPC и OTLP/HTTP — разные способы передачи телеметрии. Совпадение адреса Collector не делает их взаимозаменяемыми. Проверьте protocol, port, TLS, bind address и HTTP signal path на обеих сторонах, прежде чем менять instrumentation приложения.
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.
Сопоставьте транспорт буквально
Стандартные порты OTLP/gRPC и OTLP/HTTP — 4317 и 4318 соответственно, но конфигурация может их переопределять. Порт — подсказка, а не автоматическое согласование протокола. Для HTTP используются соответствующие signal paths, например /v1/traces. Некоторые exporter settings принимают base endpoint, другие signal-specific URL; сверяйте поведение конкретного SDK. Не добавляйте путь вслепую, иначе можно получить двойной suffix. TLS должен совпадать с ожидаемым режимом listener и trust 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; vllm localhost container port.