GitHub добавил поддержку OpenTelemetry (OTel) в приложение GitHub Copilot. Новая возможность предназначена для организаций, которым нужно наблюдать за работой Copilot-агентов и отправлять сведения об их активности в совместимые системы мониторинга.
Об изменении GitHub сообщил в записи Changelog, опубликованной 22 сентября 2026 года: https://github.blog/changelog/2026-09-22-opentelemetry-in-the-github-copilot-app
Настройка доступна через корпоративные управляемые параметры. Администратор может указать в файле managed-settings.json свойство telemetry, включить экспорт и задать конечную точку, на которую будут передаваться данные.
Какие данные получает организация
OpenTelemetry — открытый фреймворк для сбора и передачи телеметрии. Его используют для наблюдения за поведением программных систем, включая операции, задержки и ошибки. Общая документация проекта доступна на https://opentelemetry.io/docs/
В случае с GitHub Copilot речь идёт о данных, которые помогают анализировать работу агентов и их взаимодействие с моделями и инструментами. Это должно дать администраторам больше информации о том, как выполняются агентские задачи и на каких этапах возникают задержки или сбои.
GitHub не приводит в сообщении полный перечень доступных полей, метрик или событий. Поэтому из публикации нельзя сделать вывод, что организация сразу получит полный журнал всех действий агента либо детальную диагностику каждого ответа модели.
Известно другое ограничение: содержимое промптов и ответов по умолчанию исключено из телеметрии. Это означает, что базовая настройка не должна передавать в систему мониторинга текст запросов и результаты работы Copilot.
Как включается экспорт
Для активации функции администратору потребуется изменить корпоративный файл managed-settings.json. В нём задаётся параметр telemetry, а также указывается endpoint — адрес сервиса, который будет принимать данные.
Конкретный формат конфигурации и поддерживаемые варианты экспорта следует сверять с актуальной документацией GitHub. В записи Changelog описан сам факт появления настройки, но не приведён полный справочник параметров. Страница GitHub с документацией по корпоративному управлению Copilot находится по адресу https://docs.github.com/en/copilot
Таким образом, одной установки расширения или изменения локальных параметров разработчика недостаточно: функция связана именно с управляемой конфигурацией организации. Доступ к ней будет иметь смысл для компаний, где Copilot уже подключён централизованно и его работу контролируют команды платформенной инженерии, безопасности или эксплуатации.
Зачем это нужно командам, использующим агентов
Агентские функции Copilot выполняют более сложные задачи, чем обычная генерация фрагмента кода. Они могут обращаться к моделям и инструментам, выполнять последовательность операций и возвращать результат после нескольких этапов обработки. При возникновении проблемы пользователю не всегда понятно, что именно пошло не так: модель могла долго отвечать, инструмент мог завершиться ошибкой, а задача — потребовать повторного запуска.
Экспорт телеметрии позволяет перенести наблюдение за такими процессами в уже используемую организацией инфраструктуру. Команда сможет проверять, как часто возникают сбои, где появляются задержки и насколько стабильно агенты выполняют задачи. При этом GitHub в опубликованном обновлении не обещает конкретный набор интеграций и не называет готовые панели мониторинга.
Главное практическое следствие — Copilot можно рассматривать не только как пользовательский инструмент, но и как компонент корпоративной инженерной среды. Его работу потенциально можно сопоставлять с другими событиями эксплуатации, однако точный объём такой корреляции будет зависеть от передаваемых полей и возможностей принимающей системы.
Ограничение по содержимому промптов
Отдельного внимания требует настройка захвата контента. GitHub указывает, что промпты и ответы не экспортируются по умолчанию. Если организации нужны сведения о содержании запросов и результатов, администратору придётся отдельно изучить и изменить соответствующие параметры захвата.
Это не стоит путать с обычной диагностической телеметрией. Данные о задержке или факте вызова инструмента могут помочь найти техническую проблему, но не покажут, почему модель выбрала конкретный ответ. Для анализа качества результата иногда требуется видеть текст запроса и ответа, однако такая информация может содержать исходный код, внутренние инструкции или другие чувствительные сведения.
Перед включением content capture организации следует определить, какие именно данные необходимы для расследований и кто получит к ним доступ. Сам факт наличия настройки не означает, что захват содержимого обязателен для работы OpenTelemetry в Copilot.
Что пока нельзя утверждать
Публикация GitHub Changelog подтверждает появление конфигурации OpenTelemetry через enterprise-managed settings, но не раскрывает несколько важных деталей.
В частности, из неё нельзя определить:
- полный список событий, метрик и атрибутов;
- перечень поддерживаемых экспортёров и готовых интеграций;
- различия в доступности функции для разных вариантов GitHub Copilot;
- распространяется ли настройка на GitHub Enterprise Server или только на облачные сценарии;
- насколько подробными будут сведения о взаимодействии агента с отдельными моделями и инструментами.
Администраторам стоит сначала проверить доступность параметра в своей конфигурации и сопоставить фактический формат данных с требованиями внутренней системы мониторинга. Отдельно нужно убедиться, что endpoint принимает выбранный формат и что базовый режим действительно не передаёт содержимое промптов и ответов.
Для пользователей Copilot изменение означает прежде всего появление корпоративного контроля над наблюдаемостью агентов. Для GitHub это ещё один шаг к интеграции AI-инструментов в стандартные процессы эксплуатации, но оценить глубину мониторинга можно будет только после изучения реального набора экспортируемых данных и практических сценариев использования.