El soporte de OpenTelemetry en GitHub Copilot App, anunciado el 22 de septiembre de 2026, permite que las empresas envíen datos de actividad de los agentes a herramientas de observabilidad compatibles con OTLP mediante configuraciones administradas. Antes de activar la exportación, la cuestión principal no es solo elegir un endpoint: hay que entender qué señales se enviarán, qué opciones pueden exponer contenido sensible y cómo verificar que la política aplicada a la app coincida con la documentación actual.
Qué cambió en Copilot App
Según el changelog de GitHub, Copilot App ahora admite la configuración de OpenTelemetry mediante enterprise-managed settings. El objetivo es observar la ejecución de los agentes en herramientas de monitoreo ya utilizadas por la organización, siguiendo el flujo de una sesión, las llamadas a modelos y el uso de herramientas.
El anuncio también destaca el control centralizado. En lugar de pedir a cada desarrollador que configure la telemetría de forma individual, los administradores pueden definir la política en managed-settings.json. El contenido de prompts y respuestas queda excluido de forma predeterminada, por lo que la captura de contenido es uno de los primeros puntos que deben revisarse antes del despliegue.
Qué datos observar: traces, métricas y eventos
La documentación conceptual de GitHub organiza la telemetría de agentes en tres tipos de señal. Cada uno responde a una pregunta diferente y resultan más útiles cuando se analizan en conjunto.
| Señal | Qué muestra | Ejemplo documentado | Uso práctico |
|---|---|---|---|
| Traces | El flujo de una sesión del agente y la relación entre sus etapas. | Una llamada al modelo, seguida del uso de la herramienta readFile, y luego otra llamada al modelo. | Investigar dónde una sesión se volvió lenta, tomó una ruta inesperada o ejecutó una herramienta determinada. |
| Métricas | Mediciones numéricas que pueden agregarse a lo largo del tiempo. | Uso de tokens de entrada y salida en las llamadas al modelo. | Identificar tendencias de consumo, comparar periodos y detectar cambios de comportamiento. |
| Eventos | Acciones individuales asociadas a un momento específico. | Un evento de feedback de edición que indica si el usuario aceptó o rechazó una edición del agente. | Relacionar decisiones del usuario con la ejecución del agente y analizar resultados de interacciones específicas. |
Este mapa ayuda a evitar una lectura simplificada de la telemetría. Un aumento de tokens es una métrica; la secuencia que llevó a ese consumo aparece en traces; y una aceptación o un rechazo puede aparecer como evento. El backend de observabilidad debe conservar suficiente contexto para correlacionar estas señales sin convertir cada sesión en contenido capturado.
Contenido sensible: la opción que merece más atención
De forma predeterminada, la documentación indica que no se incluyen prompts, respuestas ni argumentos de herramientas. La captura de contenido puede activarse, pero la carga puede pasar a contener información sensible, como código, contenido de archivos y prompts de usuarios.
Una configuración inicial conservadora consiste en mantener captureContent desactivado y validar primero el valor operativo de traces, métricas y eventos sin contenido. Si la organización tiene un motivo claro para capturar contenido, el cambio debe tratarse como una decisión de gobierno de datos, con revisión del acceso al backend, la retención, la autenticación, el uso compartido y los requisitos internos de seguridad y privacidad.
El campo lockCaptureContent impide que los usuarios cambien la configuración de captura de contenido definida por la empresa. Esto es importante cuando la política debe mantener la exclusión de contenido de forma uniforme entre equipos.
Qué configurar en managed-settings.json
El changelog indica que se debe configurar la propiedad telemetry en el archivo de configuraciones administradas de la empresa. La referencia de enterprise-managed settings documenta los siguientes campos para esa propiedad:
| Campo | Función | Qué comprobar antes de activar |
|---|---|---|
| enabled | Activa o desactiva la exportación de telemetría. | Si el despliegue será piloto o general y qué grupos recibirán la política. |
| endpoint | Define la URL del colector OTLP. | Disponibilidad, TLS, enrutamiento de red y propiedad del destino. |
| protocol | Selecciona el transporte, con valores documentados http/json o http/protobuf. | Compatibilidad con el colector y con los controles de red existentes. |
| captureContent | Incluye o excluye contenido de prompts y respuestas de la carga de telemetría. | Si el contenido es realmente necesario y su impacto sobre datos sensibles. |
| lockCaptureContent | Impide que los usuarios cambien la opción de captura de contenido. | Si la política de contenido debe ser obligatoria. |
| serviceName | Define el nombre del servicio utilizado como atributo de recurso de OTel. | Una convención de nombres que permita distinguir Copilot de otros emisores. |
| resourceAttributes | Añade atributos de recurso a toda la telemetría exportada. | Evitar atributos innecesarios, sensibles o de alta cardinalidad. |
| headers | Añade encabezados HTTP a las solicitudes de telemetría, por ejemplo para autenticar el colector. | Cómo se aprovisionan, protegen y rotan los secretos. |
Backend y flujo de exportación
GitHub recomienda un backend seguro compatible con OpenTelemetry Protocol. Si la plataforma de observabilidad no recibe OTLP directamente, la documentación sugiere utilizar un OpenTelemetry Collector para recibir, procesar y reenviar los datos.
Antes de activar los clientes, conviene probar el recorrido completo: Copilot App, endpoint OTLP, autenticación, procesamiento en el collector cuando exista y persistencia en el backend. La prueba debe confirmar que los traces muestran una jerarquía útil, que las métricas llegan con unidades y dimensiones esperadas y que los eventos pueden correlacionarse sin exposición accidental de contenido.
Hay una discrepancia en la documentación actual
El changelog del 22 de septiembre afirma de forma explícita que GitHub Copilot App incorporó soporte de OpenTelemetry mediante enterprise-managed settings. La guía de inicio de configuraciones administradas también incluye Copilot App entre los clientes compatibles y aclara que no todos los clientes admiten todas las propiedades.
Al mismo tiempo, la sección telemetry de la referencia de enterprise-managed settings todavía indica, en la documentación consultada el 27 de septiembre de 2026, que esta propiedad es compatible con Copilot CLI y VS Code. Como las dos páginas oficiales no están totalmente alineadas, el procedimiento más seguro es tratar el changelog como el anuncio de la función y validar la aplicación de la política en la Copilot App utilizada por la empresa antes de un despliegue amplio. El anuncio no informa un número de versión específico de la app.
Cómo validar antes de desplegar en toda la empresa
- Empieza sin contenido. Mantén captureContent desactivado y comprueba si traces, métricas y eventos ya responden a las preguntas de observabilidad del equipo.
- Usa un endpoint de prueba controlado. Verifica autenticación, cifrado en tránsito, filtros y reglas de retención antes de apuntar al entorno de producción.
- Define una identidad consistente. Usa serviceName y resourceAttributes de manera estable para separar entorno, equipo o despliegue sin añadir datos personales innecesarios.
- Valida la política en el cliente. Para despliegues server-managed, GitHub indica que los clientes compatibles reciben cambios en aproximadamente una hora; reiniciar el cliente o iniciar sesión de nuevo puede actualizar la configuración de inmediato.
- Compara el resultado con la política esperada. Confirma que la app exporta al endpoint correcto y que el contenido de prompts, respuestas y argumentos de herramientas sigue ausente cuando la captura está desactivada.
- Amplía solo después del piloto. Un despliegue limitado reduce el riesgo de descubrir problemas de volumen, coste, cardinalidad o privacidad después de distribuir la configuración por toda la empresa.
Qué puede y qué no puede responder la telemetría
Con las señales recopiladas correctamente, los equipos pueden reconstruir el flujo de las sesiones, observar llamadas a modelos y herramientas, seguir el uso de tokens y registrar determinados eventos de interacción. Esto sirve para investigación operativa, análisis de tendencias y monitoreo centralizado.
OpenTelemetry no decide qué datos debe retener una organización ni sustituye las políticas de seguridad, privacidad o acceso. La configuración técnica determina qué se exporta; el gobierno define quién puede consultar los datos, durante cuánto tiempo se conservan y en qué condiciones puede recopilarse contenido más sensible.
