O suporte a OpenTelemetry no GitHub Copilot app, anunciado em 22 de setembro de 2026, permite que empresas encaminhem dados de atividade dos agentes para ferramentas de observabilidade compatíveis com OTLP por meio de configurações gerenciadas. Antes de ativar a exportação, o ponto principal não é apenas escolher um endpoint: é entender quais sinais serão enviados, quais campos podem revelar conteúdo sensível e como validar se a política aplicada ao app corresponde ao que a documentação atual descreve.
O que mudou no Copilot app
Segundo o changelog do GitHub, o Copilot app passou a aceitar configuração de OpenTelemetry por meio de enterprise-managed settings. O objetivo é acompanhar a execução dos agentes em ferramentas de monitoramento já usadas pela organização, seguindo o fluxo de uma sessão, as chamadas a modelos e o uso de ferramentas.
O anúncio também destaca o controle centralizado: em vez de cada desenvolvedor configurar a telemetria individualmente, administradores podem definir a política em managed-settings.json. O conteúdo de prompts e respostas fica excluído por padrão, o que torna a configuração de captura de conteúdo um dos primeiros pontos a revisar antes do rollout.
Quais dados observar: traces, métricas e eventos
A documentação conceitual do GitHub organiza a telemetria de agentes em três tipos de sinal. Eles respondem a perguntas diferentes e devem ser analisados em conjunto.
| Sinal | O que mostra | Exemplo documentado | Uso prático |
|---|---|---|---|
| Traces | O encadeamento de uma sessão do agente e a relação entre suas etapas. | Uma chamada ao modelo, seguida do uso da ferramenta readFile, e depois nova chamada ao modelo. | Investigar onde uma sessão ficou lenta, tomou um caminho inesperado ou executou determinada ferramenta. |
| Métricas | Medições numéricas agregáveis ao longo do tempo. | Uso de tokens de entrada e de saída nas chamadas ao modelo. | Identificar tendências de consumo, comparar períodos e detectar mudanças de padrão. |
| Eventos | Ações pontuais associadas a um momento específico. | Evento de feedback de edição indicando se o usuário aceitou ou rejeitou uma edição do agente. | Relacionar decisões do usuário com a execução do agente e analisar resultados de interações específicas. |
Esse mapa ajuda a evitar uma leitura simplista da telemetria. Um pico de tokens, por exemplo, é uma métrica; a sequência que levou a esse consumo aparece em traces; e uma aceitação ou rejeição pode aparecer como evento. O backend de observabilidade precisa preservar contexto suficiente para cruzar esses sinais sem transformar toda sessão em conteúdo capturado.
Conteúdo sensível: o campo que merece mais atenção
Por padrão, a documentação informa que prompts, respostas e argumentos de ferramentas não são incluídos. A captura pode ser ativada, mas passa a poder transportar informações sensíveis, como código, conteúdo de arquivos e prompts de usuários.
Na prática, uma configuração inicial conservadora é manter captureContent desativado e validar primeiro o valor operacional de traces, métricas e eventos sem conteúdo. Caso a organização tenha um motivo claro para capturar conteúdo, a mudança deve ser tratada como decisão de governança de dados, com revisão de acesso ao backend, retenção, autenticação, compartilhamento e requisitos internos de segurança e privacidade.
O campo lockCaptureContent existe para impedir que usuários alterem a configuração de captura definida pela empresa. Isso é relevante quando a política precisa garantir que a exclusão de conteúdo permaneça uniforme entre equipes.
O que configurar em managed-settings.json
O changelog orienta a configurar a propriedade telemetry no arquivo de configurações gerenciadas da empresa. A referência de enterprise-managed settings documenta os seguintes campos para essa propriedade:
| Campo | Função | O que conferir antes de ativar |
|---|---|---|
| enabled | Liga ou desliga a exportação de telemetria. | Se o rollout será piloto ou amplo e quais grupos receberão a política. |
| endpoint | Define a URL do coletor OTLP. | Disponibilidade, TLS, roteamento de rede e propriedade do destino. |
| protocol | Seleciona o transporte, com valores documentados http/json ou http/protobuf. | Compatibilidade com o coletor e com os controles de rede existentes. |
| captureContent | Inclui ou exclui conteúdo de prompts e respostas na carga de telemetria. | Necessidade real da captura e impacto sobre dados sensíveis. |
| lockCaptureContent | Impede que usuários mudem a opção de captura de conteúdo. | Se a política de conteúdo precisa ser obrigatória. |
| serviceName | Define o nome do serviço usado como atributo de recurso no OTel. | Padrão de nomenclatura que permita distinguir Copilot de outros emissores. |
| resourceAttributes | Acrescenta atributos de recurso a toda telemetria exportada. | Evitar atributos desnecessários, sensíveis ou de alta cardinalidade. |
| headers | Inclui cabeçalhos HTTP nas requisições de telemetria, como autenticação do coletor. | Como segredos são provisionados, protegidos e rotacionados. |
Backend e fluxo de exportação
O GitHub recomenda um backend seguro compatível com OpenTelemetry Protocol. Se a plataforma de observabilidade não receber OTLP diretamente, a documentação sugere usar um OpenTelemetry Collector para receber, processar e encaminhar os dados.
Antes de habilitar clientes, vale testar o caminho completo: Copilot app, endpoint OTLP, autenticação, processamento no collector quando existir e persistência no backend. O teste deve confirmar que traces aparecem com hierarquia útil, que métricas chegam com unidades e dimensões esperadas e que eventos podem ser correlacionados sem exposição acidental de conteúdo.
Há uma divergência na documentação atual
O changelog de 22 de setembro afirma explicitamente que o GitHub Copilot app passou a suportar OpenTelemetry por enterprise-managed settings. O guia de introdução às configurações gerenciadas também lista o Copilot app entre os clientes suportados e observa que nem todo cliente oferece todas as propriedades.
Ao mesmo tempo, a seção telemetry da referência de enterprise-managed settings ainda declara, na documentação consultada em 27 de setembro de 2026, que essa propriedade é suportada para Copilot CLI e VS Code. Como as duas páginas oficiais não estão totalmente alinhadas, o procedimento mais seguro é tratar o changelog como anúncio do recurso e validar a aplicação da política no Copilot app usado pela empresa antes de um rollout amplo. O anúncio não informa um número de versão específico do app.
Como validar antes de liberar para toda a empresa
- Comece sem conteúdo. Mantenha captureContent desativado e confirme se traces, métricas e eventos já respondem às perguntas de observabilidade da equipe.
- Use um endpoint de teste controlado. Verifique autenticação, criptografia em trânsito, filtros e regras de retenção antes de apontar para o ambiente de produção.
- Defina identidade consistente. Use serviceName e resourceAttributes de forma estável para separar ambiente, equipe ou implantação sem incluir dados pessoais desnecessários.
- Valide a política no cliente. Em implantações server-managed, o GitHub informa que clientes suportados recebem alterações em cerca de uma hora; reiniciar o cliente ou entrar novamente pode antecipar a atualização.
- Compare o resultado com a política esperada. Confirme se o app exporta para o endpoint correto e se conteúdo de prompts, respostas e argumentos de ferramentas continua ausente quando a captura estiver desativada.
- Só depois amplie o escopo. Um piloto reduz o risco de descobrir problemas de volume, custo, cardinalidade ou privacidade depois de distribuir a configuração para toda a empresa.
O que a telemetria ajuda a responder
Com os sinais corretamente coletados, a equipe consegue reconstruir o fluxo de sessões, observar chamadas a modelos e ferramentas, acompanhar consumo de tokens e registrar determinados eventos de interação. Isso é útil para investigação operacional, análise de padrões e monitoramento centralizado.
OpenTelemetry, porém, não decide sozinho quais dados a organização deve reter nem substitui políticas de segurança, privacidade e acesso. A configuração técnica define o que é exportado; a governança define quem pode consultar, por quanto tempo os dados permanecem disponíveis e em que condições conteúdo mais sensível pode ser coletado.
