2026 DeepSeek Harness OpenTelemetry: как включить без утечки сессий?

Во время разбора сбоя вы видите полезную трассировку, но не можете доказать, какие сообщения, результаты инструментов и пути с удалённого Mac покинули среду выполнения.

Быстрое решение: оставьте режим DISABLED, пока владелец данных не утвердит границы передачи; затем переходите к FEEDBACK_ONLY, подключайте изолированный OTLP/HTTP-адрес и только после проверки удаления рассматривайте FULL.

Эта статья для вас, если вы:

• централизованно расследуете сбои DeepSeek Harness на удалённых Mac;
• определяете, может ли содержимое сеанса покидать рабочую среду;
• передаёте Mac другой команде или завершаете аренду и должны закрыть телеметрию без «хвоста».

SECTION 01 Настройка OpenTelemetry в DeepSeek Harness начинается не с OTLP

Сеанс агента нельзя считать обычным техническим логом. В нём могут оказаться пользовательский запрос, фрагменты ответа модели, результаты shell-команд, содержимое файлов, имена репозиториев, пути рабочей директории, сообщения об ошибках и признаки действий оператора. Даже если формат экспорта называется OTLP logs, сам транспорт не определяет, какие поля допустимо передавать.

Официальный репозиторий DeepSeek Harness описывает проект как расширяемую агентную систему на основе плагинов и отдельно предупреждает о статусе developer preview, поэтому конфигурация и границы совместимости должны проверяться по текущей версии исходного кода, а не по старым примерам. Описание архитектуры и текущего статуса DeepSeek Harness (github.com)

До изменения настройки заведите короткую таблицу владельцев данных:

Если хотя бы один из этих пунктов не имеет владельца, разрешённой цели и процедуры удаления, оставляйте DISABLED. Это не «временная недоработка», а корректная политика минимизации данных.

Какие ограничения обычно обнаруживаются слишком поздно

Первое ограничение — содержание. Название события не говорит, содержит ли запись только длительность операции или также текст входа, вывод инструмента и контекст предыдущих ходов.

Второе — права изменения. Если любой оператор может переключить режим из FEEDBACK_ONLY в FULL, формально утверждённая политика перестаёт быть контролем. Изменение должно проходить через владельца конфигурации, журналироваться и быть связано с конкретной задачей.

Третье — конечная точка. Защищённый HTTPS не делает внешний коллектор доверенным автоматически. Нужно знать, кто владеет адресом, где хранятся записи, кто имеет к ним доступ и кто обязан удалить их после завершения теста.

Четвёртое — удалённая среда. На Mac могут сохраняться переменные среды, файлы конфигурации, журналы запуска или незавершённые буферы экспортера. Остановка UI не равна остановке процесса и не доказывает, что накопленные записи удалены.

Пятое — отказ сети. При недоступном OTLP-адресе необходимо выяснить поведение именно текущей версии Harness: блокирует ли экспорт основную задачу, пишет ли ошибку локально, сбрасывает ли буфер или продолжает работу без отправки. Нельзя подменять проверку предположением о стандартном поведении OpenTelemetry.

SECTION 02 Первый этап: зафиксируйте политику совместного использования

В текущем конфигурационном каталоге DeepSeek Harness указаны три режима: DISABLED, FEEDBACK_ONLY и FULL. Рассматривайте их как разные политики передачи данных, а не как три уровня подробности одного журнала.

Важный вывод для команды: FEEDBACK_ONLY не означает «без содержимого», а FULL не следует включать только потому, что расследование стало удобнее. В обоих случаях нужно доказать фактический набор экспортируемых полей по исходному коду и тестовой записи.

Минимальная схема согласования выглядит так:

1. владелец данных разрешает конкретные категории;
2. владелец платформы фиксирует режим и область действия;
3. специалист по безопасности утверждает endpoint, TLS и способ хранения секрета;
4. оператор выполняет тестовую отправку;
5. владелец приёмной системы подтверждает получение и срок удаления.

Если команда не может назвать человека, который имеет право изменить режим, конфигурация не готова к включению. Зафиксируйте это правило в репозитории конфигурации или в системе управления изменениями, а не только в инструкции для дежурного.

SECTION 03 Второй этап: поднимите отдельную тестовую точку OTLP

Для OTLP/HTTP используйте отдельный тестовый коллектор или изолированный приёмник, не связанный с рабочими логами. В конфигурации оставляйте только placeholders:

telemetry:
  sharing_mode: FEEDBACK_ONLY
  exporter:
    protocol: otlp_http
    endpoint: https://<test-collector.example>/v1/logs
    headers:
      authorization: <token-from-secret-store>
    tls:
      verify: true
  shutdown:
    timeout: <approved-duration>

Конкретные имена ключей необходимо сверить с конфигурационным каталогом и текущим тегом DeepSeek Harness. Не копируйте этот YAML в рабочую среду без проверки схемы: пример показывает порядок и границу секретов, а не гарантированный синтаксис конкретного релиза.

Спецификация OpenTelemetry указывает, что HTTP-экспортёр должен получать endpoint с путём конкретного сигнала; для логов это обычно /v1/logs. Если путь не задан, стандартная схема использует адрес вида http://localhost:4318/v1/{signal}, где {signal} заменяется на logs, traces или metrics. Схема конфигурации OTLP/HTTP (opentelemetry.io)

Не публикуйте в документации реальные значения Authorization, API-токены, cookies или полные заголовки. Секрет должен приходить из хранилища секретов или защищённой переменной среды, а его жизненный цикл должен включать:

• ограничение по назначению;
• запрет записи в обычный stdout;
• ротацию после теста;
• отзыв перед передачей Mac другой команде;
• проверку отсутствия значения в локальных файлах и истории shell.

Настройки OpenTelemetry обычно допускают передачу endpoint и headers через переменные среды, однако название переменной и приоритет источников зависят от реализации экспортера. В официальной документации OpenTelemetry конфигурационное свойство endpoint сопоставляется с переменной среды через префикс OTEL_, а для HTTP-протокола отдельно задаётся режим http/protobuf. Руководство по конфигурации экспортёра (opentelemetry.io)

Минимальный тест без чувствительного контекста

Используйте новую тестовую сессию, где:

• запрос не содержит клиентских данных;
• нет доступа к закрытому репозиторию;
• инструменты возвращают заранее подготовленные фиктивные значения;
• рабочий путь не раскрывает имя владельца или проекта;
• в ответе отсутствуют ключи и токены.

Затем сравните три источника:

1. событие, которое DeepSeek Harness считает экспортируемым;
2. сетевой запрос на тестовый endpoint;
3. запись, сохранённую приёмником.

Сопоставление должно быть двусторонним. Если приёмник показывает меньше данных, чем отправлял клиент, это ещё не доказывает безопасность: часть полей могла быть отброшена на сервере после передачи. Если приёмник показывает больше, чем вы ожидали, остановите тест и вернитесь к DISABLED.

SECTION 04 Третий этап: проверьте поля, отказ и повторную отправку

На этом этапе цель — не получить красивую панель, а установить границы поведения.

Проверьте по отдельности:

1. пользовательский ввод;
2. ответ модели;
3. результат каждого инструмента;
4. путь рабочей директории;
5. имя репозитория;
6. текст ошибки;
7. идентификатор сессии;
8. служебные метаданные и временные отметки.

Для каждого поля запишите результат как «присутствует», «отсутствует», «не подтверждено». Формулировка «не подтверждено» важнее ложного вывода «не передаётся».

После этого проведите отказной тест:

• запустите минимальную сессию в FEEDBACK_ONLY;
• временно сделайте тестовый endpoint недоступным;
• наблюдайте состояние Agent, локальный вывод и завершение процесса;
• восстановите endpoint;
• повторите тест с новой сессией;
• отдельно проверьте, появились ли записи, созданные во время недоступности.

Не указывайте заранее число повторов или гарантированный срок хранения, если это не подтверждено документацией либо воспроизведением на конкретной версии. Стандарт OpenTelemetry описывает транспорт и конфигурацию, но не может гарантировать бизнес-решение DeepSeek Harness о блокировке задачи, повторе или сбросе записи.

Документация по аутентификации API подтверждает модель Bearer-аутентификации для API-запросов, но это не следует автоматически переносить на ваш OTLP-приёмник: у экспортера может быть собственный токен, прокси или политика mTLS. Официальное описание HTTP-аутентификации API (api-docs.deepseek.com)

Что делать, если отправка телеметрии не удалась

Не отвечайте на этот вопрос общим правилом «задача продолжится». Для вашей версии возможны разные варианты:

• Agent продолжает выполнение, а ошибка экспортера видна только в служебном логе;
• задача получает ошибку из-за синхронного экспорта;
• запись остаётся в локальном буфере;
• запись отбрасывается;
• экспорт повторяется после восстановления соединения.

Разрешённым считается только поведение, которое вы подтвердили двумя способами: чтением соответствующего обработчика в исходном коде и тестом на рабочей версии. Если эти источники расходятся, до выяснения оставляйте DISABLED.

SECTION 05 Четвёртый этап: перенесите проверку на удалённый Mac

После локального теста повторите его на том же типе удалённой среды, где будут выполняться реальные задачи. Причина проста: на удалённом Mac появляются дополнительные границы — сетевой выход через управляющий слой, права фонового процесса, отдельный пользователь, автоматический запуск и принудительное завершение аренды.

Порядок проверки:

1. определите процесс DeepSeek Harness и его родительский процесс;
2. убедитесь, что режим телеметрии виден в фактической среде запуска;
3. проверьте, откуда читаются endpoint и секрет;
4. запустите безопасную тестовую сессию;
5. зафиксируйте сетевое соединение к разрешённому адресу;
6. корректно завершите сеанс;
7. дождитесь штатного завершения экспортера;
8. проверьте приёмник на наличие последней записи;
9. завершите процесс принудительно и повторите сравнение;
10. составьте акт о том, что было отправлено, принято и удалено.

Параметр shutdown timeout нельзя подбирать «на глаз». В конфигурации указывайте только значение, подтверждённое официальным описанием текущей версии или вашим тестом. Отдельно измеряйте границу между штатным завершением и принудительным закрытием: именно в этот момент могут потеряться неотправленные записи или, наоборот, остаться локальные файлы.

Для сетевого контроля разрешите только необходимый исходящий маршрут к тестовому или рабочему коллектору. Не полагайтесь на один TLS-сертификат: проверяйте имя узла, цепочку доверия, срок действия, правила прокси и факт отсутствия обходного маршрута.

SECTION 06 Чек-лист перед расширением режима

• [ ] Владелец каждой категории данных назначен письменно.
• [ ] Для каждого поля указана разрешённая цель передачи.
• [ ] Запрещённые данные перечислены в тестовом плане.
• [ ] Режим DISABLED, FEEDBACK_ONLY или FULL связан с конкретной задачей.
• [ ] Право изменения режима ограничено и журналируется.
• [ ] Тестовый endpoint отделён от рабочего хранилища.
• [ ] TLS-проверка включена и проверена на удалённом Mac.
• [ ] Секрет не хранится в YAML, shell history или обычном журнале.
• [ ] Минимальная сессия не содержит чувствительных данных.
• [ ] Проверены запрос, запись приёмника и расхождения между ними.
• [ ] Проверено поведение при недоступном endpoint.
• [ ] Зафиксировано, что происходит с локальным буфером и неотправленными событиями.
• [ ] Проверено штатное завершение экспортера.
• [ ] Для аварийной остановки есть отдельный результат теста.
• [ ] Перед передачей Mac предусмотрены отключение телеметрии, отзыв секрета и удаление данных на стороне приёмника.

SECTION 07 Как закрыть телеметрию перед передачей или остановкой Mac

Перед окончанием аренды, сменой команды или передачей окружения не ограничивайтесь переключением интерфейса.

Выполните процедуру в таком порядке:

1. остановите новые задачи DeepSeek Harness;
2. дождитесь завершения активной сессии либо зафиксируйте её отмену;
3. переключите режим на DISABLED;
4. перезапустите процесс, если конфигурация читается только при запуске;
5. проверьте отсутствие активного соединения с OTLP endpoint;
6. удалите или отзовите токен приёмника;
7. очистите локальные временные файлы, если это предусмотрено политикой;
8. попросите владельца приёмной системы удалить тестовые и рабочие записи;
9. получите подтверждение удаления;
10. приложите к акту имя версии, режим, время остановки и результат проверки.

Для внутренней процедуры можно связать этот акт с политикой конфиденциальности VPSNIX, а технические вопросы по управлению окружением сверять через центр поддержки VPSNIX. Эти ссылки не заменяют вашу политику хранения: они лишь помогают не потерять операционную часть при передаче удалённого Mac.

Приёмная система должна иметь отдельного владельца удаления. Если ваша команда выключила экспорт, но не контролирует хранилище OTLP, данные всё ещё могут оставаться доступными. Поэтому «телеметрия отключена» и «ранее полученные записи удалены» — два разных пункта акта.

SECTION 08 Порог включения: когда переходить с DISABLED

Используйте такую последовательность решений:

• если не классифицированы пользовательский ввод, результаты инструментов и пути — оставайтесь на DISABLED;
• если нужна только ограниченная обратная связь и подтверждено отсутствие полного контекста — тестируйте FEEDBACK_ONLY;
• если FEEDBACK_ONLY не даёт нужного сигнала, сначала расширьте тестовую выборку и фильтрацию;
• переходите к FULL только при наличии письменного разрешения, защищённого endpoint, отзываемых credentials, проверенного отказа и процедуры удаления;
• при любом расхождении между документацией, исходным кодом и фактическим приёмником возвращайтесь к DISABLED.

Если вам нужна временная наблюдаемость для расследования удалённых задач, аренда Mac у VPSNIX может быть разумнее покупки отдельной машины: вы получаете контролируемое окружение на срок теста и можете заранее включить сетевой и операционный акт передачи. Но это не отменяет ограничений: удалённый Mac требует контроля исходящего трафика, а прекращение аренды не удаляет записи из вашего OTLP-хранилища автоматически. Для долгих постоянных нагрузок, обязательного физического доступа к устройству или строгого владения всем жизненным циклом данных собственный Mac может быть лучше. Для короткого пилота, временного диагностического узла и централизованного наблюдения главное преимущество — не сама аренда, а возможность заранее включить проверяемый процесс запуска и остановки.

Если команде нужно сначала проверить временное окружение и условия доступа, начните с описания вариантов удалённой инфраструктуры VPSNIX, а не с включения FULL. Правильный порядок остаётся тем же: классификация данных, минимальный режим, изолированный OTLP-тест, отказная проверка, штатное завершение и подтверждённое удаление.

Дополнительно

• Хранение ключа DeepSeek Harness: как ограничить доступ к секретам
• Приёмка фоновых задач DeepSeek Harness: проверка журналов, отмены и восстановления