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.
Seu agente vem com acesso interno aos serviços de Azure. Ele pode consultar Azure Monitor, Application Insights, Log Analytics e Azure Resource Graph. Os conectores estendem esse alcance para sistemas externos: clusters kusto, repositórios de código-fonte, ferramentas de colaboração e APIs personalizadas.
Observação
Conectores vs. plataformas de incidente:Conectores fornecem ao agente acesso a dados e ações – consultando logs, enviando notificações, lendo código. Plataformas de incidentes são um conceito separado: elas controlam de onde os alertas vêm e como seu agente responde a eles automaticamente.
Este artigo aborda conectores. Para plataformas de incidentes, consulte plataformas de incidentes.
O que seu agente pode fazer sem conectores
Mesmo sem conectores configurados, seu agente possui capacidades internas por meio de sua identidade gerenciada e permissões RBAC do Azure.
| Capacidade incorporada | O que ele fornece |
|---|---|
| Application Insights | Consultar telemetria, rastros e exceções do aplicativo |
| Log Analytics | Consulta a espaços de trabalho do Log Analytics. |
| Métricas do Azure Monitor | Listar e consultar métricas, analisar tendências e anomalias |
| Gráfico de Recursos do Azure | Descobrir e consultar qualquer recurso do Azure em todas as assinaturas |
| ARM/CLI do Azure | Ler e modificar qualquer tipo de recurso Azure |
| Diagnóstico de AKS | Executar comandos kubectl, diagnosticar problemas do Kubernetes |
as operações Azure Resource Graph e ARM funcionam com qualquer tipo de recurso do Azure incluindo Serviços de Aplicativo, Aplicativos de Contêiner, VMs, rede, armazenamento e muito mais. Se seus logs e métricas estiverem ativos no Azure Monitor e no Application Insights, seu agente poderá começar a investigar problemas imediatamente – nenhuma configuração de conector é necessária. Os conectores se tornam valiosos quando você precisa que o agente alcance sistemas outside Azure.
O que os conectores fornecem
Os conectores são classificados em quatro categorias com base no que oferecem ao agente.
Fontes de dados
Consultar logs, métricas e telemetria de seus bancos de dados.
| Conector | O que ele fornece |
|---|---|
| Log Analytics | Conecte workspaces específicos para que o seu agente tenha contexto persistente sobre seus dados de log e possa consultá-los de forma proativa. |
| Application Insights | Conectar recursos específicos do App Insights para que seu agente tenha contexto persistente sobre a telemetria do aplicativo |
| Consulta de banco de dados (Azure Data Explorer) | Executar consultas KQL pré-definidas em seus clusters Kusto |
| Indexação de banco de dados (Azure Data Explorer) | Aprenda automaticamente seu esquema Kusto para que o agente possa gerar consultas dinamicamente |
Dica
acesso integrado versus conectores para Log Analytics e Application Insights
Seu agente já pode consultar qualquer espaço de trabalho do Log Analytics ou recurso do Application Insights por meio de suas ferramentas embutidas — nenhum conector é necessário. A adição de um Log Analytics ou Application Insights conector vai além: ele fornece ao agente uma consciência persistente de workspaces específicos, inclui seus dados no contexto ambiente do agente e permite diagnósticos mais avançados baseados em MCP de seus recursos conectados.
Código-fonte e conhecimento
Forneça o contexto do agente sobre seus sistemas: código, wikis e documentação.
| Conector | O que ele fornece |
|---|---|
| GitHub servidor MCP | Acesso a repositórios, problemas, solicitações de pull e páginas wiki |
| GitHub OAuth | Acesso ao GitHub por meio do fluxo de autenticação OAuth |
| Azure DevOps OAuth | Acesso ao Azure DevOps por meio da autenticação OAuth |
| Documentação (Azure DevOps) | Indexar e pesquisar seus wikis de Azure DevOps |
Com esses conectores, seu agente pode pesquisar padrões de erro, ler documentação wiki, fazer referência a documentos de API durante a solução de problemas e conectar incidentes a solicitações de pull relacionadas.
Ferramentas de colaboração
Permitir que seu agente comunique as descobertas por meio dos canais que sua equipe já usa.
| Conector | O que ele fornece |
|---|---|
| Enviar notificação (Teams) | Postar descobertas e atualizações nos canais do Teams |
| Enviar email (Outlook) | Resumos e relatórios de investigação de email |
Conectores personalizados (servidores MCP)
O MCP (Protocolo de Contexto de Modelo) permite que você conecte seu agente a qualquer sistema, incluindo plataformas de observabilidade, repositórios de código-fonte, sistemas de tíquetes e APIs personalizadas. Seu agente descobre automaticamente ferramentas dos servidores conectados, monitora a saúde da conexão com pulsações de 60 segundos e se recupera automaticamente de falhas transitórias.
Dois tipos de transporte abrangem cada modelo de implantação: Streamable-HTTP para serviços de nuvem remota e stdio para processos locais em execução junto com seu agente. Conectores de parceiros pré-configurados para GitHub, Datadog, Splunk, New Relic e mais permitem configuração com um único clique.
Para obter um guia completo sobre arquitetura MCP, tipos de transporte, conectores de parceiros, monitoramento de integridade e gerenciamento de ferramentas, consulte conectores e ferramentas do MCP.
Para configurar seu primeiro conector MCP, consulte Configurar o conector MCP.
Navegando e gerenciando conectores
Abra a página Conectores (Construtor de Conectores>) para ver seus conectores organizados em grupos de categorias recolhíveis. Todos os grupos são expandidos por padrão.
| Categoria | O que ele inclui |
|---|---|
| Repositório de código | GitHub, Azure DevOps, código-fonte e conectores de documentação |
| Notificação | Conectores de mensagens do Teams e Outlook |
| Telemetria | Azure Data Explorer, Datadog, Dynatrace, Elasticsearch, New Relic, Splunk e outros conectores de monitoramento |
| Outras | Servidores e conectores MCP genéricos que não se encaixam em outras categorias |
Cada cabeçalho de categoria mostra o número de conectores nesse grupo. Quando você recolher uma categoria, um selo vermelho será exibido se algum conector desse grupo tiver um problema de conexão. Você pode detectar problemas rapidamente sem expandir todas as seções. Use os controles da barra de ferramentas para gerenciar sua exibição:
- Expanda tudo / Colapsar tudo para alternar todos os grupos de categorias de uma só vez.
- Filtro de categoria para mostrar apenas conectores em uma categoria específica.
- Pesquise para localizar conectores por nome (alterna para uma lista simples para pesquisa de palavra-chave).
Somente as categorias que contêm pelo menos um conector são exibidas. Quando você procura um conector por nome, a página alterna para uma exibição de lista simples para filtragem mais rápida.
Quem pode configurar conectores
O gerenciamento do conector requer permissão de gravação no agente. Na prática:
| Função | Pode configurar conectores? |
|---|---|
| Administrador do Agente SRE | Sim |
| Usuário Padrão do Agente SRE | Não — somente exibição |
| Leitor do Agente SRE | Não — somente exibição |
Durante a instalação, alguns conectores exigem OAuth consent de um usuário que tem as permissões certas no sistema externo (por exemplo, um membro da organização GitHub para conectores GitHub ou um administrador do AD Azure para Outlook/Teams). Esse consentimento é sobre permissões no serviço externo , não funções do Agente SRE.
Para conectores que usam a identidade gerenciada do agente (como o Azure Data Explorer), um administrador do sistema externo deve adicionar a identidade à lista de permissões.
Quando você configura conectores, todos os usuários do agente se beneficiam deles automaticamente. Eles apenas fazem perguntas ao agente e ele usa os conectores disponíveis nos bastidores.
Conectores e agentes personalizados
Você pode atribuir ferramentas mcp específicas a agentes personalizados especializados. Um agente personalizado de solução de problemas de banco de dados pode obter ferramentas do Kusto, enquanto um agente personalizado de implantação obtém acesso GitHub. Essa abordagem mantém cada agente personalizado focado e evita sobrecarregá-lo com muitas ferramentas.
Atribua ferramentas individualmente no seletor de ferramentas do portal ou use padrões curinga (connection-id/*) no YAML para adicionar todas as ferramentas de um servidor ao mesmo tempo. Para obter detalhes sobre a atribuição de ferramentas e a sintaxe curinga, consulte conectores e ferramentas MCP.
No portal, acesse Construtor>Construtor de agente personalizado, crie ou edite um agente personalizado e selecione Escolher ferramentas em configurações avançadas. O seletor de ferramentas exibe as ferramentas agrupadas pela conexão MCP. Selecione os que seu agente personalizado precisa.
No YAML, liste cada ferramenta pelo nome completo:
mcp_tools:
- azure-data-explorer_kusto_query
- azure-data-explorer_kusto_table_list
- azure-data-explorer_kusto_table_schema
Adicionar todas as ferramentas de um servidor MCP (curinga)
Aplica-se a: versão 26.2.9.0 e posterior
Quando um servidor MCP expõe muitas ferramentas e seu agente personalizado precisa de todas elas, use o padrão curinga em vez de listar cada ferramenta individualmente:
mcp_tools:
- azure-data-explorer/*
O {connection-id}/* padrão adiciona todas as ferramentas dessa conexão MCP. Seu agente expande o curinga na inicialização. Por exemplo, azure-data-explorer/* corresponde a todas as ferramentas registradas em uma conexão chamada azure-data-explorer (o padrão preenchido na versão 26.4.16.0 para o MCP do Azure com o conector Kusto). Substitua o nome que você deu ao conector.
Você pode combinar curingas com nomes de ferramentas individuais:
mcp_tools:
- azure-data-explorer/* # All tools from the Kusto connection
- grafana-mcp_dashboard # One specific tool from Grafana
Observação
Sintaxe curinga
O padrão deve usar {connection-id}/* com a barra invertida. Padrões como azure-data-explorer* (sem a barra) são tratados como nomes exatos de ferramentas, não como caracteres curingas.
A tabela a seguir compara a seleção individual de ferramentas e a abordagem curinga.
| Abordagem | Quando usar |
|---|---|
| Ferramentas individuais | Você deseja um controle preciso sobre quais ferramentas um agente personalizado pode acessar |
Curinga (connection-id/*) |
Você confia no servidor MCP e deseja todas as suas ferramentas, incluindo qualquer adição posterior |
| Mixed | Você deseja todas as ferramentas de um servidor, além de ferramentas específicas de outro |
Por que usar o curinga? Quando um servidor MCP adiciona novas ferramentas, o "wildcard" as detecta automaticamente sem reconfigurar seu agente personalizado. A seleção de ferramentas individuais fornece controle preciso. O curinga fornece cobertura automática.
Quando as ferramentas MCP ainda não estiverem prontas
Se um servidor MCP não estiver pronto quando o agente for iniciado, seu agente não poderá acessar ferramentas desse servidor. Seu agente lida com essa condição normalmente. Ele adia os agentes personalizados com curingas não resolvidos ou ferramentas ausentes e os carrega automaticamente assim que o seu agente estabelece a conexão MCP. Você não precisa tomar nenhuma ação manual.
Para obter mais informações, consulte Agentes Personalizados.
Próxima etapa
Conteúdo relacionado
| Recurso | Por que isso importa |
|---|---|
| Plataformas de incidentes | Como seu agente recebe e responde a incidentes automaticamente |
| Conectar código-fonte | Configurar conectores GitHub ou Azure DevOps |
| Configurar um conector MCP | Adicionar servidores MCP personalizados |
| Agentes Personalizados | Criar agentes especializados com acesso específico ao conector |
| Permissões | Configurar Azure acesso a recursos para seu agente |