Durante los últimos meses, GitHub ha ampliado considerablemente las opciones disponibles para medir la adopción y el uso de GitHub Copilot sin salir de la propia plataforma. Ahora contamos con métricas cada vez más completas por usuario, organización, modelo, lenguaje y superficie de uso.

Lo sé: es mucha información —o mucha telemetría 😅—. Si te has perdido alguno de los anuncios, estos son algunos de los más relevantes:

• GitHub Copilot app usage metrics now expand across report rollups
• Enterprise-managed OpenTelemetry export for VS Code and CLI
• GitHub Copilot for JetBrains adds improved OpenTelemetry configuration and model management
• New Copilot usage metrics impact dashboard
• Repository-level GitHub Copilot usage metrics generally available
• Add review cycles and time to adoption phases in the usage API

Las métricas de uso de GitHub Copilot son la mejor opción cuando necesitas analizar la adopción de forma agregada. Sin embargo, puede que quieras responder a preguntas diferentes o trabajar con otro nivel de detalle: qué agentes personalizados se utilizan, cómo se comporta cada sesión, qué herramientas invoca el agente, cuántos tokens consume o dónde se producen los errores.

Para esos casos, actualmente es posible habilitar OpenTelemetry en Visual Studio Code, los IDEs de JetBrains y GitHub Copilot CLI para exportar la telemetría directamente a un OpenTelemetry Collector. Desde ahí puedes enviarlas al backend de observabilidad que necesites. Si no conoces OpenTelemetry, o no sabes exactamente cómo funciona, hace muuuucho, mucho tiempo grabé un vídeo para mi canal de YouTube, cuando todavía estaba dando mis primeros pasos (no juzgar 🥲). Te lo dejo aquí por si sirve:

En esta prueba de concepto voy a utilizar Application Insights. De esta forma puedes analizar la actividad por sesiones y entender con bastante detalle cómo están trabajando los agentes.

Si esto es justo lo que necesitas, sigue leyendo 👇🏻, porque voy a contarte la prueba de concepto que he montado.

Lo que he montado

El flujo de este ejemplo es el siguiente:

1. Visual Studio Code emite señales de OpenTelemetry por cada interacción con Copilot Chat mediante los ajustes github.copilot.chat.otel.*.
2. Un OpenTelemetry Collector, ejecutándose en un contenedor de Docker, recibe las trazas, métricas y logs mediante OTLP/HTTP en localhost:4318.
3. El Collector reenvía esas señales a Application Insights mediante el exporter azuremonitor.
4. Desde Application Insights puedo consultar la información en Search o Logs, además de visualizarla mediante los dashboards de Grafana integrados o crear otros nuevos —spoiler alert 😄—.

En esta POC el Collector se ejecuta en local, pero en un escenario compartido podría desplegarse, por ejemplo, en Azure Container Apps o en un clúster de Kubernetes.

Prerrequisitos

• Docker instalado. Si utilizas Podman o WSL Containers, tendrás que adaptar el comando de ejecución.
• Visual Studio Code con GitHub Copilot Chat actualizado.
• Una suscripción de Azure.
• Azure CLI instalado, solo si quieres crear los recursos desde la terminal.

Para una POC pequeña, la franquicia gratuita de ingesta de Azure Monitor suele ser suficiente. Aun así, revisa siempre los límites y precios vigentes, especialmente antes de habilitar esta configuración para todo un equipo.

Paso 1: Crear el recurso de Application Insights

Opción A: Desde el portal de Azure

1. Ve al portal de Azure.
2. Selecciona Crear un recurso y busca Application Insights.
3. Elige la suscripción, el grupo de recursos, la región y el nombre.
4. Haz clic en Revisar y crear.
5. Una vez creado el recurso, abre Overview y copia el valor de Connection String.

Opción B: Desde Azure CLI

# Crea el grupo de recursos si todavía no existe
az group create \
  --name otel-poc \
  --location spaincentral
# Crea el recurso de Application Insights
az monitor app-insights component create \
  --app gh-copilot-otel-poc \
  --location spaincentral \
  --resource-group otel-poc \
  --application-type web
# Recupera la connection string
az monitor app-insights component show \
  --app gh-copilot-otel-poc \
  --resource-group otel-poc \
  --query connectionString \
  --output tsv

Guarda la connection string. Tendrá un formato similar a este:

InstrumentationKey=...;IngestionEndpoint=...;LiveEndpoint=...

Aunque no permite consultar la información almacenada, debes protegerla: cualquiera que tenga acceso a ella podría enviar telemetría a tu recurso de Application Insights.

Paso 2: Configurar el OpenTelemetry Collector

Crea un archivo llamado otel-collector-config.yml con el siguiente contenido:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch: {}
exporters:
  debug:
    verbosity: detailed
  azuremonitor:
    connection_string: ${env:APPLICATIONINSIGHTS_CONNECTION_STRING}
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, azuremonitor]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, azuremonitor]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, azuremonitor]

Además de enviar la información a Application Insights, he añadido el exporter debug. Así puedo revisar los logs del contenedor y confirmar que el Collector está recibiendo las señales correctamente.

Ahora exporta la connection string como variable de entorno:

export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=...;IngestionEndpoint=...;LiveEndpoint=..."

Y arranca el Collector:

docker run -d \
  --name otel-collector \
  --restart unless-stopped \
  -p 4317:4317 \
  -p 4318:4318 \
  -e APPLICATIONINSIGHTS_CONNECTION_STRING \
  -v "$(pwd)/otel-collector-config.yml:/etc/otelcol-contrib/config.yaml:ro" \
  otel/opentelemetry-collector-contrib:latest

Puedes comprobar que está funcionando y ver la telemetría recibida con:

docker logs -f otel-collector

Nota: Para simplificar la POC estoy utilizando la etiqueta latest. En un entorno compartido o productivo es mejor fijar una versión concreta de la imagen.

Paso 3: Configurar Visual Studio Code

Añade la siguiente configuración a tu archivo settings.json:

{
  "github.copilot.chat.otel.enabled": true,
  "github.copilot.chat.otel.exporterType": "otlp-http",
  "github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318",
  "github.copilot.chat.otel.captureContent": true
}

El ajuste captureContent merece especial atención. Cuando está habilitado, la telemetría puede incluir los prompts, las respuestas y el contenido relacionado con las llamadas a herramientas. Eso puede exponer código fuente, datos personales, secretos u otra información sensible.

En esta POC lo he activado para poder inspeccionar toda la interacción, pero no es necesario para obtener métricas de uso o identificar los agentes. En un entorno real, déjalo en false salvo que tengas un caso de uso claro y una política de privacidad y retención adecuada.

Después de guardar la configuración, Visual Studio Code te pedirá reiniciar o recargar la ventana para que los cambios surtan efecto.

Para organizaciones: GitHub también permite distribuir esta configuración mediante enterprise managed settings, definiendo el endpoint, el protocolo, los atributos, las cabeceras de autenticación y si se permite capturar contenido.

Paso 4: Consultar las trazas en Application Insights

Abre Copilot Chat en Visual Studio Code y envía una petición en modo agente. La telemetría debería aparecer en Application Insights normalmente en unos minutos.

La forma más rápida de comprobarlo es:

1. Abre el recurso de Application Insights en el portal de Azure.
2. Ve a Investigate > Search.

También puedes utilizar Monitoring > Logs para lanzar consultas KQL sobre los datos. Por ejemplo, una pregunta que suele aparecer en muchas organizaciones es qué custom agents se están utilizando.

Esta consulta devuelve el número de invocaciones y de sesiones por agente durante los últimos 30 días:

dependencies
| where timestamp > ago(30d)
| where cloud_RoleName == "copilot-chat"
| where name == "invoke_agent"
| extend agent = tostring(customDimensions["copilot_chat.mode_name"]),
         sessionId = tostring(customDimensions["gen_ai.conversation.id"])
| extend agent = iff(
    isempty(agent),
    "GitHub Copilot (predeterminado)",
    agent
  )
| summarize
    invocations = count(),
    sessions = dcount(sessionId)
  by agent
| order by invocations desc

En mi caso, el resultado incluye tanto el nombre de mis agentes personalizados como GitHub Copilot en su modo predeterminado.

Paso 5: Crear un dashboard personalizado con Grafana

Application Insights incluye una experiencia integrada llamada Dashboards with Grafana. Está disponible desde el portal de Azure sin necesidad de desplegar una instancia independiente de Azure Managed Grafana.

Dentro de esta sección encontrarás dashboards prediseñados para diferentes asistentes y agentes de código, entre ellos GitHub Copilot. El dashboard incluido permite visualizar operaciones, tokens de entrada y salida, sesiones de chat, llamadas a herramientas y latencia por modelo.

Pero también puedes adaptar esa experiencia a las necesidades de tu equipo. Para esta POC he partido del dashboard existente —puedes exportarlo mediante Export > JSON— y he creado una variante centrada en el uso de los custom agents.

Puedes descargar mi versión desde este gist.

Para importarla:

1. Abre tu recurso de Application Insights.
2. Ve a Monitoring > Dashboards with Grafana.
3. Selecciona New > Import.
4. Sube el archivo JSON.
5. Selecciona el recurso de Application Insights que contiene la telemetría.

Con esto puedes construir una vista adaptada a las preguntas reales de tu organización, en lugar de limitarte a un único dashboard genérico.

Conclusión

Las métricas nativas de GitHub Copilot son el punto de partida perfecto para analizar la adopción a escala. OpenTelemetry no las sustituye: las complementa cuando necesitas una visión más operativa y detallada de lo que ocurre dentro de cada sesión.

Con Visual Studio Code, un OpenTelemetry Collector y Application Insights puedes centralizar trazas, métricas y logs, consultar la actividad mediante KQL y construir dashboards adaptados a las necesidades de tu equipo. Y lo mejor es que el mismo Collector puede recibir telemetría de otros agentes, por lo que la arquitectura puede crecer contigo.

¡Nos vemos 👋🏻!