Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Microsoft OpenTelemetry Distro é uma distribuição de observabilidade unificada que fornece uma única experiência de onboarding para coletar rastreamentos, métricas e logs de aplicativos agentes e não-agentes. Ele dá suporte à observabilidade para Microsoft Agent 365, Microsoft Foundry, Azure Monitor e qualquer back-end compatível com OTLP (OpenTelemetry Protocol). A distribuição dá suporte a .NET, Node.js, e Python e substitui as configurações fragmentadas em várias pilhas de observabilidade por uma importação e uma chamada de configuração.
Note
Se você mantém uma integração existente que utiliza o SDK de Observabilidade do Agent 365 anterior, revise a documentação e os guias de migração do SDK obsoleto.
Principais benefícios
A distribuição Microsoft OpenTelemetry oferece estes benefícios:
- Um pacote, uma API: substitua vários pacotes de exportador e instrumentação por uma única dependência.
- Suporte a múltiplos backends: enviar telemetria para Azure Monitor, qualquer ponto de extremidade compatível com o protocolo OTLP (OpenTelemetry Protocol), como Datadog, Grafana ou New Relic, e Microsoft Agent 365 ao mesmo tempo.
- Instrumentações embutidas: use instrumentação automática para HTTP, bancos de dados, SDK do Azure, Azure Functions e muito mais sem configuração extra.
- Baseado em padrões: construa sobre o OpenTelemetry, a estrutura de observabilidade padrão do setor.
- Clichê mínimo: adicione uma importação e uma chamada de função ao ponto de entrada do aplicativo.
Instalação e configuração
Esta orientação mostra como adicionar observabilidade ao seu aplicativo com Microsoft OpenTelemetry Distro. A Distro coleta automaticamente traços, métricas e logs com instrumentações embutidas e exporta a telemetria para o Azure Monitor, qualquer endpoint OTLP (Protocolo OpenTelemetry) ou Microsoft Agent 365.
Instalar biblioteca
Para começar a usar o Microsoft OpenTelemetry Distro, instale a biblioteca apropriada para sua plataforma de desenvolvimento usando o gerenciador de pacotes do seu idioma.
Configuration
O exportador do Agente 365 não usa um cadeia de conexão. Ele descobre seu ponto de extremidade automaticamente com base no locatário. Para habilitar a exportação para o Agente 365, defina o destino do exportador e forneça um resolvedor de token que retorna um token de acesso para uma determinada ID de agente e ID de locatário.
Por padrão, a distro exporta pela rota delegada, que precisa da permissão delegada Agent365.Observability.OtelWrite e do consentimento do administrador. O a365 setup all comando não configura essa permissão para agentes blueprint, então use S2S com um resolver exclusivo de aplicativo para esses agentes. Uma instância de agente registrado pode exportar pela rota S2S sem permissão de Observabilidade ou consentimento do administrador.
Chame use_microsoft_opentelemetry() para habilitar a observabilidade.
from microsoft.opentelemetry import use_microsoft_opentelemetry
from microsoft.opentelemetry.a365.hosting.token_cache_helpers import AgenticTokenCache
token_cache = AgenticTokenCache()
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=lambda agent_id, tenant_id: (
(t := asyncio.run(token_cache.get_observability_token(agent_id, tenant_id)))
and t.token or None
),
)
Para resolução personalizada de token (em vez do resolvedor de token padrão), consulte o resolvedor de token manual.
Você pode personalizar o comportamento do exportador passando kwargs opcionais a365_* para use_microsoft_opentelemetry().
| Parâmetro | Description | Default |
|---|---|---|
a365_use_s2s_endpoint |
Quando True, usa o caminho do ponto de extremidade serviço-a-serviço. Use com um resolvedor de token exclusivo para aplicativos. |
False |
a365_max_queue_size |
Tamanho máximo da fila para o processador de lote. | 2048 |
a365_scheduled_delay_ms |
Atraso em milissegundos entre lotes de exportação. | 5000 |
a365_exporter_timeout_ms |
Tempo limite em milissegundos para a operação de exportação. | 30000 |
a365_max_export_batch_size |
Tamanho máximo do lote para operações de exportação. | 512 |
Propagar contexto
Para manter a observabilidade em operações distribuídas do Agente 365, propague o contexto. Ao propagar o contexto por meio de seus agentes e serviços, você garante que rastreamentos, logs e métricas estejam correlacionados corretamente em todo o ciclo de vida da solicitação. Essa correlação é necessária para uma experiência de monitoramento completa e eficaz do Microsoft agente 365.
Atributos de bagagem
Use BaggageBuilder para definir informações contextuais que se propagam por todos os trechos em uma requisição.
O SDK implementa um SpanProcessor que copia todas as entradas de bagagem não vazias para spans recém-iniciados sem sobrescrever atributos existentes.
from microsoft.opentelemetry.a365.core import BaggageBuilder
with (
BaggageBuilder()
.tenant_id("tenant-123")
.agent_id("agent-456")
.conversation_id("conv-789")
.build()
):
# Any spans started in this context will receive these as attributes
pass
Para preencher automaticamente o BaggageBuilder a partir do TurnContext, use a função auxiliar populate no pacote microsoft-opentelemetry. Esse auxiliar extrai automaticamente os detalhes do chamador, agente, inquilino, canal e conversa da atividade.
from microsoft.opentelemetry.a365.core import BaggageBuilder
from microsoft.opentelemetry.a365.hosting.scope_helpers.populate_baggage import populate
builder = BaggageBuilder()
populate(builder, turn_context)
with builder.build():
# Baggage is auto-populated from the TurnContext activity
pass
Middleware de bagagem
Se o agente usar o pacote de integração de hospedagem, registre o middleware de bagagem para preencher automaticamente a bagagem para cada solicitação de entrada. Esta etapa remove a necessidade de chamar BaggageBuilder manualmente em cada manipulador de atividades.
Em Python, registre o baggage middleware por meio de ObservabilityHostingManager.configure() em vez de diretamente no adaptador.
from microsoft.opentelemetry.a365.hosting import ObservabilityHostingManager, ObservabilityHostingOptions
options = ObservabilityHostingOptions(enable_baggage=True)
ObservabilityHostingManager.configure(adapter.middleware_set, options)
O middleware ignora a configuração de dados adicionais para respostas assíncronas (eventos ContinueConversation) para evitar substituir as informações que a solicitação de origem já estabeleceu.
Os dados de validação estão fluindo no produto
Para visualizar a telemetria do agente no Microsoft Purview ou Microsoft Defender, certifique-se de atender aos seguintes requisitos:
- Microsoft Purview: a auditoria deve ser ativada para sua organização. Para obter instruções, consulte Ativar ou desativar a auditoria.
-
Microsoft Defender: a busca avançada deve ser configurada para acessar a tabela
CloudAppEvents. Para obter detalhes, consulte a tabela CloudAppEvents no esquema de busca avançado.
Instrumentação automática
O Microsoft OpenTelemetry Distro combina pipelines padrão do OpenTelemetry com instrumentação selecionada pela Microsoft. A Distribuição pode coletar telemetria de aplicativo, telemetria de infraestrutura e telemetria de agente ou de IA generativa, dependendo da linguagem e da configuração.
| Category | O que ele aborda |
|---|---|
| Pipelines de sinal | Rastros, métricas e logs. |
| Detecção de recursos | Serviço, host, nuvem e contexto de execução do Azure onde houver suporte. |
| Instrumentação de infraestrutura | HTTP, ASP.NET Core, SDK do Azure, clientes de banco de dados e estruturas de log em que há suporte. |
| Instrumentação de IA generativa | OpenAI, Azure OpenAI, Kernel semântico, LangChain, OpenAI Agents SDK e Agent Framework onde houver suporte. |
| Escopos manuais do agente | Invocação do agente, execução da ferramenta, inferência e telemetria de saída, quando houver suporte. |
| Exportadores e processadores | Azure Monitor, Microsoft Agent 365, OTLP, saída do console, processadores de span, processadores de log e leitores de métricas. |
Cobertura de instrumentação
| Linguagem | Instrumentação de aplicativo comum | Agente comum e instrumentação de IA generativa |
|---|---|---|
| Python | Recursos, processadores, leitores, log, métricas e rastreamentos do OpenTelemetry. | Kernel semântico, SDK do OpenAI Agents, Agent Framework, LangChain, Microsoft Agent 365 e escopos do agente Microsoft 365. |
| Node.js | HTTP, SDK do Azure, Azure Functions, MongoDB, MySQL, PostgreSQL, Redis, Bunyan e Winston. | SDK de Agentes do OpenAI, LangChain, configuração do Agente Microsoft 365 e escopos do Agente Microsoft 365. |
| .NET | ASP.NET Core, HttpClient, SQL Client, SDK do Azure, detecção de recursos, métricas e logs. | Kernel semântico, OpenAI e Azure OpenAI, Agent Framework, Microsoft Agent 365 baggage e Microsoft Agent 365 scopes. |
A instrumentação automática escuta sinais de telemetria emitidos por estruturas e bibliotecas com suporte. A instrumentação manual é usada quando um aplicativo precisa descrever operações específicas do agente, como invocação, execução da ferramenta, inferência ou saída assíncrona.
Adicione fontes, medidores, processadores ou leitores personalizados do OpenTelemetry quando o aplicativo emitir telemetria que não é coberta pelas instrumentações internas.
Importante
A instrumentação automática popula somente atributos padrão do OpenTelemetry. Ele não inclui todos os atributos exigidos pelo Agente 365. Você deve adicionar atributos específicos Microsoft por meio de BaggageBuilder. Para ver quais atributos são necessários, consulte os atributos de validação do Store.
Bibliotecas de instrumentação embutidas
A instrumentação automática escuta a telemetria emitida por frameworks com suporte e a encaminha por meio do pipeline OpenTelemetry da Distro. Para cenários de agente, defina bagagem, como ID de locatário e ID do agente antes que a estrutura instrumentada crie intervalos.
| Framework | Python | Node.js | .NET |
|---|---|---|---|
| Núcleo Semântico | Supported | Sem suporte | Supported |
| OpenAI e SDK de Agentes da OpenAI | Supported | Supported | Supported |
| Estrutura do Agente | Supported | Sem suporte | Supported |
| LangChain | Supported | Supported | Não listado |
Núcleo Semântico
from microsoft.opentelemetry import use_microsoft_opentelemetry
def token_resolver(agent_id, tenant_id):
return "your-token"
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=token_resolver,
instrumentation_options={
"semantic_kernel": {"enabled": True},
},
)
OpenAI
from microsoft.opentelemetry import use_microsoft_opentelemetry
def token_resolver(agent_id, tenant_id):
return "your-token"
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=token_resolver,
instrumentation_options={
"openai_agents": {"enabled": True},
},
)
Estrutura do Agente
from microsoft.opentelemetry import use_microsoft_opentelemetry
def token_resolver(agent_id, tenant_id):
return "your-token"
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=token_resolver,
instrumentation_options={
"agent_framework": {"enabled": True},
},
)
LangChain
Note
A instrumentação automática para a estrutura LangChain também dá suporte a LangGraph e Deep Agents. A mesma instrumentação captura automaticamente a telemetria para agentes criados com qualquer uma dessas estruturas.
from microsoft.opentelemetry import use_microsoft_opentelemetry
def token_resolver(agent_id, tenant_id):
return "your-token"
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=token_resolver,
instrumentation_options={
"langchain": {"enabled": True},
},
)
Instrumentação manual
Use a instrumentação manual quando a instrumentação automática não consegue descrever a operação do agente com detalhes suficientes. Os escopos manuais permitem que um aplicativo descreva as atividades comuns do agente de forma consistente entre idiomas.
| Scope | Usar para |
|---|---|
InvokeAgentScope |
O início e a conclusão de uma invocação de agente. |
ExecuteToolScope |
Uma ativação de ferramenta feita por um agente. |
InferenceScope |
Uma operação de inferência de modelo de IA. |
OutputScope |
Saída que deve ser registrada após a conclusão do escopo original. |
Reutilize os mesmos valores de identidade de agente e de solicitação em diferentes escopos de uma solicitação para que a telemetria relacionada possa ser correlacionada.
Invocação do agente
from microsoft.opentelemetry.a365.core import (
AgentDetails,
Channel,
InvokeAgentScope,
InvokeAgentScopeDetails,
Request,
ServiceEndpoint,
)
agent_details = AgentDetails(
agent_id="agent-456",
agent_name="Email Assistant",
agent_description="An AI agent powered by Azure OpenAI",
agentic_user_id="auid-123",
agentic_user_email="agent@contoso.com",
agent_blueprint_id="blueprint-789",
tenant_id="tenant-123",
)
request = Request(
content="Please help me organize my emails",
session_id="session-42",
conversation_id="conv-xyz",
channel=Channel(name="msteams"),
)
scope_details = InvokeAgentScopeDetails(
endpoint=ServiceEndpoint(hostname="myagent.contoso.com", port=443),
)
with InvokeAgentScope.start(
request=request,
scope_details=scope_details,
agent_details=agent_details,
) as scope:
scope.record_input_messages(["Please help me organize my emails"])
# Run the agent invocation.
invoke_scope.record_output_messages(["I found 15 urgent emails."])
Execução da ferramenta
from microsoft.opentelemetry.a365.core import (
ExecuteToolScope,
ServiceEndpoint,
ToolCallDetails,
ToolType,
)
tool_details = ToolCallDetails(
tool_name="email-search",
arguments={"query": "from:manager@contoso.com"},
tool_call_id="tool-call-456",
description="Search emails by criteria",
tool_type=ToolType.FUNCTION.value,
endpoint=ServiceEndpoint(
hostname="tools.contoso.com",
port=8080,
protocol="https",
),
)
with ExecuteToolScope.start(
request=request,
details=tool_details,
agent_details=agent_details,
) as scope:
result = search_emails(tool_details.arguments)
scope.record_response(result)
Inferência
from microsoft.opentelemetry.a365.core import (
InferenceCallDetails,
InferenceOperationType,
InferenceScope,
)
inference_details = InferenceCallDetails(
operationName=InferenceOperationType.CHAT,
model="gpt-4o-mini",
providerName="azure-openai",
)
with InferenceScope.start(
request=request,
details=inference_details,
agent_details=agent_details,
) as scope:
scope.record_input_messages(["Summarize the following emails for me."])
response = call_llm()
scope.record_output_messages([response.text])
scope.record_input_tokens(response.usage.input_tokens)
scope.record_output_tokens(response.usage.output_tokens)
scope.record_finish_reasons(["stop"])
Saída
from microsoft.opentelemetry.a365.core import OutputScope, Response, SpanDetails
# Capture this before exiting the originating InvokeAgentScope context.
parent_context = invoke_scope.get_span_context()
response = Response(
messages=["Here is your organized inbox."],
)
with OutputScope.start(
request=request,
response=response,
agent_details=agent_details,
user_details=None,
span_details=SpanDetails(parent_context=parent_context),
) as scope:
pass
A documentação do produto deve definir todos os requisitos de validação específicos do produto para esses escopos.
Validação local
A validação local confirma que o aplicativo produz telemetria antes que um destino específico do produto seja validado. Use a saída do console ou um ponto de extremidade OTLP local para verificar se rastreamentos, métricas e logs estão sendo criados.
Validar com um ponto de extremidade OTLP local
Configurar a Distribuição para enviar telemetria para um coletor local ou outro endpoint compatível com OTLP.
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
from microsoft.opentelemetry import use_microsoft_opentelemetry
use_microsoft_opentelemetry()
Validar com resultado local
Use a saída local quando quiser confirmar a instrumentação antes de enviar telemetria para um destino remoto.
export ENABLE_A365_OBSERVABILITY_EXPORTER=false
from microsoft.opentelemetry import use_microsoft_opentelemetry
def token_resolver(agent_id, tenant_id):
return "local-validation-token"
use_microsoft_opentelemetry(
enable_a365=True,
a365_token_resolver=token_resolver,
)
# Run instrumented application code.
Revise a saída local para intervalos de fontes esperadas, como solicitações HTTP, chamadas do OpenAI ou Azure OpenAI, escopos de invocação do agente, escopos de execução de ferramentas ou escopos de inferência. A validação específica de destino pertence à documentação do produto referente àquele destino.
Configurar manualmente a autenticação
Ao usar o exportador do Agent 365, você deve fornecer um mecanismo para fornecer um token de autenticação. O resolvedor de token funciona por lote de exportação usando a ID do agente e a ID do locatário do contexto de bagagem ativa. A distribuição dá suporte a duas abordagens.
Para agentes blueprint habilitados para Agent 365 configurados com a365 setup all, use S2S com um resolvedor somente de aplicativo. O cache de token agentic embutido e os exemplos OBO nesta página usam a rota delegada, que precisa da permissão delegada Agent365.Observability.OtelWrite e do consentimento do administrador. O a365 setup all comando não configura essa permissão para agentes de blueprint.
Dica
Se você estiver criando agentes com o SDK de Agentes do Microsoft 365, consulte Observability Authentication Setup for Agent SDK para obter instruções passo a passo sobre como configurar a aquisição de token OBO e S2S para agentes agente e não agente.
Resolvedor de token manual
Use um resolver manual quando adquirir tokens fora do pipeline do Agent Framework, quando estiver construindo aplicativos que não sejam do Agent Framework ou quando usar autenticação service-to-service (S2S). O token que seu resolver retorna deve corresponder à rota. Para a rota delegada, retorne um token delegado com o Agent365.Observability.OtelWrite escopo. Para a rota S2S, devolva o token final exclusivo do aplicativo que você solicitar usando o escopo api://9b975845-388f-4429-889e-eab1ef63949c/.default. Um agente blueprint registrado no S2S não precisa do Agent365.Observability.OtelWrite cargo ou do consentimento do administrador.
Note
Para autenticação de serviço para serviço (S2S), você deve usar esta abordagem manual de resolução de token. O cache agêntico de tokens suporta apenas fluxos de autenticação on-behalf-of (OBO).
Os exemplos a seguir mostram o padrão do resolvedor de token OBO (em nome de) — o agente adquire um token de usuário por meio do manipulador de autenticação agêntica e o troca por um token com escopo para observabilidade. Esses exemplos exigem a permissão delegada Agent365.Observability.OtelWrite e o consentimento do administrador. Para obter exemplos de S2S (serviço a serviço) e uma comparação da autenticação OBO vs S2S, consulte a Configuração de Autenticação de Observabilidade para o SDK do Agente.
O resolvedor deve ser síncrono. Adquira o token no manipulador de atividades assíncronas (ou via MSAL) e armazene-o em cache para o resolvedor.
from microsoft.opentelemetry import use_microsoft_opentelemetry
from microsoft.opentelemetry.a365.runtime import get_observability_authentication_scope
_cached_token: str | None = None
def my_token_resolver(agent_id: str, tenant_id: str) -> str | None:
return _cached_token
use_microsoft_opentelemetry(enable_a365=True, a365_token_resolver=my_token_resolver)
@AGENT_APP.activity("message", auth_handlers=["AGENTIC"])
async def on_message(context: TurnContext, _state: TurnState):
global _cached_token
_cached_token = await AGENT_APP.auth.exchange_token(
context,
scopes=get_observability_authentication_scope(),
auth_handler_id="AGENTIC",
)
Cache de token agentic com aplicativos do Agent Framework
Para aplicativos do Agent Framework que usam autenticação em nome do usuário (OBO), a distribuição registra automaticamente IExporterTokenCache<AgenticTokenStruct> via DI quando você não define um TokenResolver personalizado. Seu agente chama RegisterObservability() em tempo de execução para fornecer credenciais, e o cache cuida da aquisição e atualização delegadas de tokens.
Note
Essa abordagem suporta apenas fluxos de autenticação on-behalf-of (OBO) na rota delegada, o que requer a permissão delegada Agent365.Observability.OtelWrite e o consentimento do administrador. Para autenticação service-to-service (S2S), incluindo agentes blueprint configurados com a365 setup all, use o resolvedor manual de tokens com um token somente de aplicativo. Para etapas de configuração, veja Agent 365-enabled using S2S.
from microsoft.opentelemetry import use_microsoft_opentelemetry
from microsoft.opentelemetry.a365.hosting.token_cache_helpers import AgenticTokenCache, AgenticTokenStruct
from microsoft.opentelemetry.a365.runtime import get_observability_authentication_scope
token_cache = AgenticTokenCache()
_cached_tokens: dict[tuple[str, str], str | None] = {}
# Keep the sync resolver side-effect free; refresh the cache in the async request handler.
def sync_token_resolver(agent_id: str, tenant_id: str) -> str | None:
return _cached_tokens.get((agent_id, tenant_id))
use_microsoft_opentelemetry(enable_a365=True, a365_token_resolver=sync_token_resolver)
@AGENT_APP.activity("message", auth_handlers=["AGENTIC"])
async def on_message(context: TurnContext, _state: TurnState):
agent_id = context.activity.recipient.id
tenant_id = context.activity.recipient.tenant_id
token_cache.register_observability(
agent_id=agent_id,
tenant_id=tenant_id,
token_generator=AgenticTokenStruct(
authorization=AGENT_APP.auth,
turn_context=context,
),
observability_scopes=get_observability_authentication_scope(),
)
_cached_tokens[(agent_id, tenant_id)] = await token_cache.get_observability_token(
agent_id, tenant_id,
)
Armazenar atributos de validação
Para validação bem-sucedida da loja, seu agente deve implementar InvokeAgentScope, InferenceScope e ExecuteToolScope. Cada escopo corresponde a uma operação de intervalo no esquema canônico:
| Escopo do SDK | Operação de abrangência | Código de referência universal |
|---|---|---|
InvokeAgentScope |
invoke_agent |
IA |
ExecuteToolScope |
execute_tool |
ET |
InferenceScope |
chat |
CH |
OutputScope |
output_messages |
OM |
Para obter as listas completas de atributos obrigatórios e opcionais por escopo, incluindo a semântica de cada atributo, as orientações para escolha de valores e quais atributos podem ser consultados na Busca Avançada do Microsoft Defender, consulte Referência de atributos de observabilidade do Agent 365. A coluna Aplica-se a identifica a qual escopo cada atributo pertence e a coluna Obrigatória distingue obrigatório (M) dos atributos opcionais (O).
Teste seu agente com observabilidade
Depois de implementar a observabilidade, verifique se a telemetria está sendo capturada:
- Ir para
https://admin.cloud.microsoft/#/agents/all. - Selecione seu agente e selecione Atividade.
- Verifique se as sessões e as chamadas de ferramenta aparecem.
Aplicativos de exemplo e configuração avançada
Para obter exemplos de trabalho e opções de configuração avançadas, consulte os repositórios de GitHub para cada idioma:
Referência de programação
Para revisar os tipos do Microsoft OpenTelemetry Distro, veja os seguintes artigos de referência de programação:
Troubleshooting
Esta seção descreve problemas comuns ao implementar e usar o Microsoft OpenTelemetry Distro com o Agente 365.
| Problema | Description |
|---|---|
| Os dados de observabilidade não são exibidos | Nenhuma telemetria é visível porque a exportação do Agent 365 não está ativada, a configuração não está completa ou a resolução do token falha. |
| ID do locatário ou do agente ausente – trechos ignorados | Os spans são filtrados antes da exportação quando os atributos de identidade necessários do locatário ou do agente estão ausentes. |
| Falha de resolução de token – exportação ignorada ou não autorizada | A exportação é ignorada ou rejeitada quando o resolvedor de token não retorna nenhum token ou quando ocorrem erros durante a obtenção do token. |
| HTTP 401 Não Autorizado | As solicitações chegam ao serviço, mas a autenticação falha porque o token é inválido, expirou ou para o público errado. |
| HTTP 403 Proibido | A autorização falha devido à falta de licenciamento do tenant, identidade S2S não registrada ou ausência de permissões de escrita de observabilidade quando são necessárias. |
| HTTP 403 Proibido – Incompatibilidade da ID do agente | O serviço rejeita a exportação quando a ID do agente na solicitação não corresponde à identidade do agente autorizado por token. |
| Erros HTTP 429 ou 5xx – Erros transitórios | Throttling temporário ou instabilidade no backend interrompe a exportação e pode exigir tentativas ou ajuste em lote. |
| Tempo limite de exportação | As operações de exportação excedem os limites de tempo de espera devido a atrasos na rede ou à latência na resposta do endpoint. |
| A exportação é bem-sucedida, mas a telemetria não aparece no Defender ou no Purview | A ingestão de dados é bem-sucedida, mas a visibilidade é atrasada ou bloqueada por pré-requisitos downstream e requisitos de esquema. |
Dica
O Guia de Solução de Problemas do Agente 365 contém recomendações de resolução de problemas de alto nível, melhores práticas e links para conteúdo de solução de problemas para cada parte do ciclo de desenvolvimento do Agente 365.
Os dados de observabilidade não aparecem
Sintomas:
- O agente está correndo
- Sem telemetria no centro administrativo
- Não consigo ver a atividade dos agentes
Causa raiz:
- A exportação do Agente 365 não está habilitada
- Erros de configuração
- Problemas do resolvedor de tokens
Soluções: Tente os seguintes passos para resolver o problema:
Verificar se a exportação do Agente 365 está habilitada
Você deve habilitar explicitamente o exportador do Agente 365. Quando você não o configurar, a distribuição pode recorrer a um exportador de console ou não exportar nada. Habilite-o no código:
from microsoft.opentelemetry import use_microsoft_opentelemetry use_microsoft_opentelemetry( enable_a365=True, a365_enable_observability_exporter=True, a365_token_resolver=my_token_resolver, )Ou defina a variável de ambiente:
export ENABLE_A365_OBSERVABILITY_EXPORTER=trueNote
ENABLE_A365_OBSERVABILITY_EXPORTERé uma opção de alternância secundária que só entra em vigor quandoenable_a365=Trueé definida no código. Você também pode controlá-lo por meio doa365_enable_observability_exporterkwarg.
Verifique a configuração do resolver de tokens
O exportador requer um resolvedor de token válido que retorna um token de portador para cada solicitação de exportação. Se o resolvedor de token estiver ausente ou retornar
null, a exportação será ignorada silenciosamente.Habilitar a exportação do console e verificar se há telemetria localmente
Adicione um exportador de console para verificar se a telemetria está sendo gerada antes de atingir o ponto de extremidade do Agente 365:
Ativar o registo verboso
Verificar os logs em busca de erros de exportação
Use o
az webapp log tailcomando para pesquisar os logs em busca de erros relacionados à observabilidade:az webapp log tail --name <your-app-name> --resource-group <your-resource-group> | Select-String "observability"
ID do locatário ou ID do agente ausente – intervalos ignorados
Sintomas: O sistema descarta silenciosamente intervalos e nunca os exporta. Algumas plataformas registram uma contagem de intervalos ignorados ou uma mensagem como No spans with tenant/agent identity found. Outros os descartam sem registrá-los em log.
Solução:
- Antes da exportação, as partições de distribuição são divididas pela identidade do locatário e do agente. Intervalos que não têm um ID de locatário ou um ID de agente são descartados e nunca enviados para o serviço.
- Verifique se
BaggageBuilderestá configurado com a ID do locatário e a ID do agente antes de criar intervalos. Esses valores se propagam por meio do contexto OpenTelemetry e são anexados a todos os intervalos criados dentro do escopo da bagagem. Para a API específica da plataforma, consulte atributos de bagagem. - Se você estiver usando o middleware de bagagem ou o auxiliar de contexto do pacote de integração de hospedagem, confirme se a
TurnContextactivity tem um destinatário válido com a identidade do agente.
Falha no processamento de token – exportação ignorada ou não autorizada
Sintomas: O resolvedor de token retorna null ou gera um erro. Dependendo da plataforma, a exportação é totalmente ignorada ou falha com HTTP 401.
Solução:
- O resolvedor de token é necessário. Se ele estiver ausente, o exportador gerará um erro na inicialização. Verifique se um resolvedor de token é fornecido e retorna um token de portador válido.
- Verifique se a ID de locatário correta e a ID do agente foram passadas para
BaggageBuilder, pois esses valores são encaminhados para o resolvedor de token. - Para S2S, retorne o token final de observabilidade somente de aplicativo para
9b975845-388f-4429-889e-eab1ef63949couapi://9b975845-388f-4429-889e-eab1ef63949c. Não devolva a asserção intermediária do blueprint, um token de blueprint, ou um token de usuário ou OBO. - Para a rota delegada, retorne um token delegado com o escopo
Agent365.Observability.OtelWrite. - Para agentes hospedados no Azure que exportam diretamente com uma identidade gerenciada, verifique se a identidade gerenciada tem a função de aplicativo
Agent365.Observability.OtelWrite. Instâncias registradas do blueprint agent no S2S não precisam disso. - Para aplicativos .NET usando o pacote de hospedagem do Agent Framework, a troca de tokens é tratada automaticamente por meio de DI. Se os tokens estiverem ausentes, confirme se
Microsoft.Agents.A365.Observability.Hostingestá instalado e registrado.
HTTP 401 Não Autorizado
Sintomas: A exportação falha com HTTP 401. O exportador não tenta novamente esse erro.
Solução:
- Verifique se a audiência do token é
9b975845-388f-4429-889e-eab1ef63949couapi://9b975845-388f-4429-889e-eab1ef63949c, e se o tipo de token corresponde à rota: um token delegado para a rota delegada, ou um token exclusivo de aplicativo para a rota S2S. - Para S2S, verifique se o resolver não está devolvendo um token de usuário delegado, uma asserção intermediária de blueprint, um token de blueprint, um token para um público incorreto ou um token expirado.
- Para a rota delegada, verifique se o claim do token
scpcontémAgent365.Observability.OtelWritee se o token não está expirado.
HTTP 403 Proibido
Sintomas: A exportação falha com HTTP 403. O exportador não tenta novamente esse erro.
Causa raiz: Um erro HTTP 403 pode ter causas diferentes. Verifique as resoluções a seguir na ordem correta.
Solução:
Missing license — verifique se seu locatário tem uma das seguintes licenças atribuídas no Centro de administração do Microsoft 365:
- Teste - Microsoft 365 E7
- Microsoft 365 E7
- Microsoft Agent 365 Frontier
Identidade não registrada no S2S — Uma instância registrada de agente blueprint pode exportar na rota S2S com um token exclusivo do aplicativo sem a função
Agent365.Observability.OtelWrite. Se a identidade não estiver registrada no Agente 365, o serviço retorna HTTP 403insufficient_scope. Para agentes blueprint,a365 setup allregistra a instância do agente. Para tentar novamente um registro falhado, executea365 setup all --agent-registration-only. A criação de uma identidade Microsoft Entra, por si só, não registra a instância do agente.Permissão ausente
Agent365.Observability.OtelWritequando é necessária — Conceda a permissão para a rota delegada ou para identidades não registradas, incluindo registros de aplicativo padrão. Agentes registrados de blueprint no S2S não precisam dessa permissão.
Conceder a permissão
Conceda Agent365.Observability.OtelWrite apenas quando você usar a rota delegada ou uma identidade não registrada. Agentes Blueprint registrados que usam S2S não precisam dessa permissão ou consentimento do administrador. Conceda apenas o tipo de permissão que sua rota utiliza:
- Rota delegada: Adicione a permissão delegada.
- Rota S2S com identidade não registrada, como o registro padrão de aplicativo que um agente de motor personalizado usa: Adicionar a permissão do aplicativo (função do app).
Use uma destas opções:
CLI do Agente 365 (agentes de blueprint na rota delegada)
Esse comando adiciona a permissão delegada ao seu blueprint e suas permissões herdáveis, e então concede consentimento de administrador. Não adiciona a permissão do aplicativo. É necessária uma conta de Administrador Global. Execute o comando do diretório do projeto agente que contém
a365.config.json, ou adicione--agent-name "<agent-name>".a365 setup permissions custom --resource-app-id 9b975845-388f-4429-889e-eab1ef63949c --scopes Agent365.Observability.OtelWritecentro de administração do Microsoft Entra (por qualquer uma das duas rotas)
Não são necessários arquivos de configuração; requer acesso de Global Administrator ao registro do aplicativo. Para um blueprint pela rota delegada, use essa opção apenas se o blueprint já tiver a API de Observabilidade em suas permissões herdáveis, como um blueprint configurado por uma versão anterior da CLI. Caso contrário, use a CLI do Agent 365.
- Vá ao centro de administração do Microsoft Entra, selecione Registros de aplicativo e então selecione seu blueprint ou registro padrão de app.
- Acesse Permissões de API>Adicionar uma permissão>APIs que minha organização usa> procurar por
9b975845-388f-4429-889e-eab1ef63949c. - Selecione permissões Delegadas para a rota delegada, ou permissões de Aplicação para uma identidade não registrada na rota S2S.
- Marque a caixa
Agent365.Observability.OtelWrite, e então selecione Adicionar permissões. - Selecione Conceder consentimento do administrador e confirme.
A permissão que você adicionou mostra o status
Granted.
HTTP 403 Proibido — incompatibilidade no ID do agente
Sintomas: A exportação falha com HTTP 403 e uma mensagem do servidor semelhante a 403 Forbidden, com falhas agent-ID-mismatch ao chamar os endpoints de rastreamento do Agent 365.
Causa principal: Esse erro ocorre quando você usa o ID do cliente do blueprint em vez do ID do cliente da instância do agente ao configurar os detalhes do agente. A ID do agente na URL de exportação não corresponde à identidade autorizada pelo token, portanto, o ponto de extremidade de rastreamento rejeita a solicitação.
Solução:
- Verifique se a ID do locatário foi adicionada à lista de locatários permitidos do Agente 365.
- Defina os detalhes do agente usando o ID do cliente da instância do agente (não o ID do cliente do blueprint).
- Verifique a URL de exportação gerada — ela é registrada se você habilitar o logger. Confirme se o ID do agente na URL corresponde ao ID do cliente da instância de agente.
- Para habilitar o registro de diagnóstico em log para cada SDK, consulte Validação local.
Erros HTTP 429 ou 5xx – Erros transitórios
Sintomas: A exportação falha com um código de status HTTP transitório, como 429 ou 5xx.
Solução:
- Esses erros geralmente são transitórios e resolvidos por conta própria. As distribuições Python e JavaScript automaticamente tentam novamente as solicitações HTTP ao receberem os códigos de status 408, 429 e 5xx. A distribuição do .NET não faz tentativas automáticas novamente.
- Se os erros persistirem, verifique o painel de integridade do serviço.
- Considere reduzir a frequência de exportação aumentando o atraso agendado entre lotes ou o tamanho máximo do lote de exportação. Para Python e JavaScript, use os parâmetros relevantes
exporterOptionsoua365_*documentados nos repositórios GitHub. Para .NET, useo.Agent365.Exporter.ScheduledDelayMillisecondseo.Agent365.Exporter.MaxExportBatchSize.
Tempo limite de exportação
Sintomas: Tempo limite de tentativas de exportação.
Solução:
Verifique a conectividade de rede com o endpoint de observabilidade.
O tempo limite de solicitação HTTP padrão é de 30 segundos em todas as plataformas. Se os tempos limite ocorrerem com frequência, aumente o valor de tempo limite nas opções do exportador:
A exportação é bem-sucedida, mas a telemetria não aparece no Defender ou no Purview
Symptoms: Logs mostram uma exportação bem-sucedida (HTTP 200), mas a telemetria não está visível em Microsoft Defender ou Microsoft Purview.
Solução:
- Verifique se você atende aos pré-requisitos para exibir logs exportados:
- Microsoft Purview: a auditoria deve ser ativada para sua organização. Consulte Ativar ou desativar a auditoria.
-
Microsoft Defender: a busca avançada deve ser configurada para acessar a tabela
CloudAppEvents. Consulte a tabela CloudAppEvents no esquema de busca avançado.
- A telemetria pode levar vários minutos para ser atualizada após uma exportação bem-sucedida. Aguarde antes de investigar mais.
- Verifique se os intervalos contêm atributos
microsoft.tenant.idegen_ai.agent.idválidos. Atributos de identidade ausentes fazem com que os intervalos sejam descartados no lado do servidor, mesmo que a exportação HTTP retorne 200.
Conteúdo relacionado
- Conceitos de observabilidade do Agente 365 – Fluxo de dados, modelos de identidade, autenticação, escopos e limites que se aplicam a cada caminho de integração.
- Referência de atributo de observabilidade do Agente 365 – esquema de atributo de intervalo canônico ao qual cada intervalo ingerido pelo Agente 365 deve estar em conformidade.