В этом материале
Отсутствие prompt в одном log не доказывает отсутствие в telemetry pipeline. Проверяйте фактический экспорт всех путей, включая ошибки.
Для диагностики inference API обычно нужны время, outcome, модель и безопасные идентификаторы. Полное содержание prompt не должно попадать в каждый технический канал просто потому, что SDK умеет его захватывать. При этом удаление поля в одном logger ещё не означает, что оно исчезло из trace, exception или exporter. Провайдеру нужна проверяемая политика телеметрии с явным набором разрешённых данных и тестом всей цепочки.
Определите минимальную запись
OpenTelemetry о sensitive data описывает минимизацию, фильтрацию и redaction как отдельные меры. Начните с allowlist: endpoint, согласованное имя модели, duration, outcome и ограниченные технические поля. Для каждого значения назовите цель и место хранения. «Может пригодиться» слишком широко для автоматического включения содержимого пользователя.
Request ID может помогать корреляции, но его происхождение тоже важно. Если он сформирован клиентом и содержит произвольную строку, не считайте его безопасным только по имени поля. Внутренний тестовый идентификатор и реальный внешний payload требуют разных допущений о доверии.
Разведите metadata и content
GenAI span conventions отдельно рассматривают захват instructions, inputs и outputs. Такое содержимое может появляться в разных формах, включая вложенные структуры. Политика должна охватывать не только prompt string, но и messages, tool arguments, результаты инструментов и дополнительные поля ошибок.
Если content capture нужен для ограниченного диагностического сценария, он имеет собственные условия, права и срок хранения. Это не следует незаметно включать общей настройкой production exporter. Статья описывает архитектурную границу, а не объявляет конкретную политику обработки данных любого внешнего сервиса.
Проверьте propagation
OpenTelemetry context propagation связывает операции между компонентами. Однако baggage и headers могут переносить больше metadata, чем требуется. Сохраните allowlist передачи и точки удаления, особенно на границе внешнего запроса. Trace context не является разрешением копировать содержимое пользователя через всю инфраструктуру.
Для диагностики обычно достаточно связи безопасных IDs. Не создавайте новый секрет в имени span или metric label. Даже если основной payload очищен, такая строка способна оказаться в другой системе с иным доступом и retention. Проверка должна включать все наблюдаемые exported fields.
Создайте marker fixture
Используйте синтетический маркер SYNTHETIC_SECRET в обычном message, вложенном tool argument и контролируемом error path. Затем соберите фактический вывод тестового exporter. Ожидаемый результат — разрешённая metadata присутствует, запрещённый маркер не обнаруживается на выбранных проверяемых выходах.
Не проверяйте только функцию redaction unit-тестом. Другой middleware может записать исходный body до фильтра либо добавить exception с фрагментом входа. Integration fixture должен наблюдать последовательность до конечного тестового приёмника, сохраняя конфигурацию и версию SDK вместе с результатом проверки.
Сохраните границы доказательства
Отсутствие маркера на доступном выходе подтверждает именно этот путь и набор fixtures. Оно не доказывает отсутствие любых данных во всех внешних системах. Если часть exporter-chain недоступна наблюдению, отчёт честно сохраняет неизвестную область вместо универсальной формулировки «ничего не хранится».
Связанные темы — DLP шлюза и безопасность доступа. Здесь фокус на собственной telemetry pipeline: минимальный набор, проверка реального экспорта и ясная граница выводов без неподтверждённых обещаний приватности конкретной компании.