As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Configurando recursos para AWS DevOps o Agent
AWS DevOps Os recursos do agente ampliam a funcionalidade do seu agente conectando-o às suas ferramentas e infraestrutura existentes. Configure esses recursos para permitir uma investigação abrangente de incidentes, fluxos de trabalho de resposta automatizados e integração perfeita com seu DevOps ecossistema.
Os recursos a seguir ajudam você a maximizar a eficácia do seu DevOps agente:
+ **AWS Configuração do EKS Access** - Permita a introspecção de clusters, registros de pods e eventos de cluster do Kubernetes para ambientes EKS públicos e privados
+ **Integração com o Azure** — Conecte assinaturas do Azure e DevOps organizações do Azure para investigar os recursos do Azure e correlacionar implantações do Azure DevOps com incidentes
+ **Integração de pipeline de CI/CD** - Connect GitHub e GitLab pipelines para correlacionar implantações com incidentes e rastrear alterações de código durante investigações
+ **Conexões de servidor MCP** - Estenda os recursos de investigação conectando ferramentas externas de observabilidade e sistemas de monitoramento personalizados por meio do Model Context Protocol
+ ** AWS Acesso a várias contas** - configure AWS contas secundárias para investigar recursos em toda a organização durante a resposta a incidentes
+ **Integração de fontes de telemetria** — Conecte plataformas de monitoramento como Datadog, Dynatrace, Grafana, New Relic e Splunk para acesso abrangente aos dados de observabilidade
+ **Integração de emissão de tíquetes e bate-papo** - Connect ServiceNow e Slack para automatizar fluxos de trabalho de resposta a incidentes e permitir a colaboração em equipe PagerDuty
+ **Configuração do webhook** - Permita que sistemas externos acionem automaticamente as investigações do DevOps agente por meio de solicitações HTTP
+ ** EventBridge Integração com a Amazon** — incorpore o AWS DevOps agente em aplicativos orientados por eventos roteando eventos do ciclo de vida de investigação e mitigação para os alvos da Amazon EventBridge
Você pode configurar cada recurso de forma independente com base nas necessidades específicas da sua equipe e na pilha de ferramentas existente. Comece com as integrações mais importantes para seu fluxo de trabalho de resposta a incidentes e, em seguida, expanda para recursos adicionais conforme necessário.
# Migração da versão prévia pública para a disponibilidade geral
Se você usou o AWS DevOps Agent durante a pré-visualização pública, você deve atualizar suas funções do IAM antes do lançamento do GA. Este guia explica como atualizar as funções de monitoramento e as funções do operador em suas contas.
## O que está mudando
1. [Os históricos de bate-papo sob demanda durante a pré-visualização não estão mais acessíveis](#on-demand-chat-history-from-public-preview)
1. [Novas políticas gerenciadas substituem as políticas disponíveis durante a versão prévia](#new-managed-policies)
1. [Os Agent Spaces podem ter um escopo de acesso ao aplicativo IAM Identity Center desatualizado](#reconnect-iam-identity-center-if-applicable)
## Histórico de bate-papo sob demanda a partir da pré-visualização pública
A versão GA introduz medidas de segurança adicionais para fortalecer os controles de acesso aos históricos de bate-papo. Como resultado dessas mudanças, os históricos de bate-papo sob demanda do período de pré-visualização pública (antes de 30 de março de 2026) não estão mais acessíveis. Os diários de investigação e as descobertas criadas durante a pré-visualização pública não são afetados. **Essa alteração se aplica somente às conversas de bate-papo sob demanda.**
## Novas políticas gerenciadas
Para o GA, AWS fornece novas políticas gerenciadas que substituem as políticas da era de pré-visualização:
| Tipo de função | Remover | Adicionar |
| --- | --- | --- |
| Monitoramento | Política gerenciada pelo AIOpsAssistantPolicy | Política gerenciada pelo AIDevOpsAgentAccessPolicy |
| Operador (IAM e IDC) | Política em linha | Política gerenciada pelo AIDevOpsOperatorAppAccessPolicy |
Além disso, as funções do operador exigem políticas de confiança atualizadas, e as funções do operador da IDC exigem uma nova política em linha.
### Pré-requisitos
+ Acesso às AWS contas em que suas funções de DevOps agente estão configuradas (contas primárias e todas as secundárias)
+ Permissões do IAM para modificar funções, políticas e relações de confiança
+ Seu ID do Agent Space, ID da AWS conta e região (visíveis no console do DevOps agente)
### Etapa 1: atualizar as funções de monitoramento
Atualize a função de monitoramento em sua conta principal e em cada conta secundária. Essas são as funções de Primary/Secondary origem configuradas na guia **Capacidades** em seu espaço de agente (exemplo de primary/secondary função:`DevOpsAgentRole-AgentSpace-3xj2396z`).
1. No console do DevOps agente, acesse seu Espaço do agente e escolha a guia **Capacidades**.
1. Encontre a função de monitoramento de suas Primary/Secondary fontes (por exemplo,`DevOpsAgentRole-AgentSpace-3xj2396z`) e escolha **Editar**.
1. Em **Políticas de permissões**, remova a política `AIOpsAssistantPolicy` AWS gerenciada.
1. Escolha **Adicionar permissões**, **Anexar políticas** e anexar a política `AIDevOpsAgentAccessPolicy` gerenciada.
1. Edite a política em linha e substitua seu conteúdo pelo seguinte, substituindo o ID da sua conta:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam:::role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
]
}
]
}
```
1. A política de confiança para a função de monitoramento não exige alterações. Verifique se ele corresponde ao seguinte:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnLike": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/*"
}
}
}
]
}
```
+ Repita as etapas de 2 a 6 para a função de monitoramento em cada conta secundária.
### Etapa 2: atualizar a função do operador (IAM)
1. No console do DevOps agente, escolha a guia **Acesso** e encontre a função do operador.
1. No console do IAM, remova a política embutida existente da função de operador.
1. Escolha **Adicionar permissões**, **Anexar políticas** e anexar a política `AIDevOpsOperatorAppAccessPolicy` gerenciada.
1. Escolha a guia **Relações de confiança** e escolha **Editar política de confiança**. Substitua a política de confiança pela seguinte, substituindo seu ID da conta, região e ID do espaço do agente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
}
}
}
]
}
```
### Etapa 3: Atualizar as funções do operador (IDC)
Se você usa o IAM Identity Center com o DevOps Agent, atualize cada função de operador da IDC.
1. No console do IAM, acesse **Roles** e pesquise `WebappIDC` para encontrar suas funções do DevOps Agent IDC (por exemplo,`DevOpsAgentRole-WebappIDC-`).
1. Para cada função da IDC:
a. Remova a política embutida existente.
b. Escolha **Adicionar permissões**, **Anexar políticas** e anexar a política `AIDevOpsOperatorAppAccessPolicy` gerenciada.
c. Escolha a guia **Relações de confiança** e escolha **Editar política de confiança**. Substitua a política de confiança pela seguinte, substituindo seu ID da conta, região e ID do espaço do agente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
}
}
},
{
"Sid": "TrustedIdentityPropagation",
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
},
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": [
"arn:aws:iam::aws:contextProvider/IdentityCenter"
]
},
"Null": {
"sts:RequestContextProviders": "false"
}
}
}
]
}
```
d. Crie uma nova política em linha com as seguintes permissões, substituindo o ID da sua conta:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowDevOpsAgentSSOAccess",
"Effect": "Allow",
"Action": [
"sso:ListInstances",
"sso:DescribeInstance"
],
"Resource": "*"
},
{
"Sid": "AllowDevOpsAgentIDCUserAccess",
"Effect": "Allow",
"Action": "identitystore:DescribeUser",
"Resource": [
"arn:aws:identitystore:::identitystore/*",
"arn:aws:identitystore:::user/*"
]
}
]
}
```
## Reconecte o IAM Identity Center (se aplicável)
Os Agent Spaces criados durante a pré-visualização pública podem ter um aplicativo IAM Identity Center configurado com um escopo de acesso desatualizado. Para GA, o escopo correto é **`aidevops:read_write`**. Se seu aplicativo do IAM Identity Center tiver o escopo anterior (**`awsaidevops:read_write`**), você deverá desconectar e reconectar o IAM Identity Center.
### Como verificar o escopo do aplicativo do IAM Identity Center
Execute o seguinte comando da AWS CLI para verificar o escopo do seu aplicativo do IAM Identity Center. **Você pode encontrar o ARN do aplicativo no console do IAM Identity Center em Aplicativos.**
```
aws sso-admin list-application-access-scopes \
--application-arn arn:aws:sso:::application//
```
A saída deve mostrar o escopo correto **`aidevops:read_write`**:
```
{
"Scopes": [
{
"Scope": "aidevops:read_write"
}
]
}
```
Se o escopo aparecer **`awsaidevops:read_write`**, ele está desatualizado. Siga as etapas abaixo para atualizá-lo.
### Como reconectar o IAM Identity Center
O escopo de acesso em um aplicativo AWS gerenciado do IAM Identity Center não pode ser atualizado diretamente. Você deve desconectar e reconectar:
1. No console do AWS DevOps agente, acesse seu Espaço do agente e escolha a guia **Acesso**.
1. Escolha **Desconectar** ao lado da configuração do IAM Identity Center.
1. Confirme a desconexão.
1. Escolha **Connect** para configurar o IAM Identity Center novamente. O serviço cria um novo aplicativo do IAM Identity Center com o escopo correto.
1. Reatribua usuários e grupos ao novo aplicativo no console do IAM Identity Center.
**Importante**
A desconexão remove o bate-papo individual do usuário e o histórico de artefatos associados às contas de usuário do IAM Identity Center. Os usuários precisarão fazer login novamente após a reconexão.
## Verificação
Depois de concluir todas as etapas:
1. Retorne ao console do DevOps Agente e verifique se nenhum erro de permissão aparece na guia **Acesso ao** Espaço do Agente.
1. Teste o aplicativo web do operador para confirmar se ele carrega e funciona corretamente.
1. Se você usa o IDC, verifique se os usuários podem autenticar e acessar a experiência do operador.
## Solução de problemas
**Erros de permissão negada após a migração**
+ Verifique se `AIOpsAssistantPolicy` foi removido e `AIDevOpsAgentAccessPolicy` está vinculado às funções de monitoramento.
+ Verifique se as políticas embutidas antigas foram removidas e `AIDevOpsOperatorAppAccessPolicy` se estão vinculadas às funções do operador.
+ Verifique se as políticas de confiança da operadora incluem`sts:TagSession`.
+ Confirme se você substituiu todos os valores de espaço reservado (````,,``) por valores reais.
**Contas secundárias não funcionam**
+ A função de monitoramento de cada conta secundária deve ser atualizada de forma independente. Faça login em cada conta e repita a Etapa 1.
**Falhas de autenticação do IDC**
+ Verifique se a política de confiança da IDC inclui tanto a `sts:TagSession` declaração`sts:AssumeRole`/quanto a `TrustedIdentityPropagation` declaração.
+ Confirme se a política em linha com`sso:ListInstances`,`sso:DescribeInstance`, e `identitystore:DescribeUser` foi criada.
**Histórico de bate-papo sob demanda ausente após a migração**
+ Os históricos de bate-papo sob demanda do período de pré-visualização pública não estão acessíveis após o lançamento do GA. Esse é o comportamento esperado devido às medidas de segurança aprimoradas introduzidas no GA. Os diários de investigação e as descobertas da prévia pública não são afetados.
# AWS Configuração de acesso ao EKS
Você pode permitir que o AWS DevOps Agente investigue problemas em seus clusters do Amazon EKS executando `kubectl` comandos somente de leitura em clusters públicos e privados. Você pode conectar qualquer número de clusters EKS ao mesmo Agent Space.
Depois de conectado, o agente pode ajudar a diagnosticar problemas operacionais em seus clusters, descrevendo recursos, recuperando registros do pod, inspecionando eventos do cluster, verificando a integridade dos nós e muito mais. O agente não pode criar, modificar ou excluir nenhum recurso no seu cluster.
## Pré-requisitos
Antes de configurar o acesso ao EKS, certifique-se de que o modo de autenticação do seu cluster EKS inclua a API EKS. Você pode verificar isso na guia **Acesso** no [console do Amazon EKS](https://console.aws.amazon.com/eks). Se o modo não incluir a API EKS, selecione um modo que inclua antes de continuar.
## Configuração
Essas etapas precisam ser concluídas no [console do Amazon EKS](https://console.aws.amazon.com/eks) para cada cluster para o qual você deseja criar uma entrada de acesso. Você pode encontrar o ARN da função do IAM no seu Espaço do agente (consulte[Criação de um espaço de agente](getting-started-with-aws-devops-agent-creating-an-agent-space.md)) em **Capacidades > Nuvem > Fonte primária > Editar**.
1. Vá até a guia **Acesso**. Se o modo de autenticação já indicar API EKS, você poderá adicionar entradas de acesso. Caso contrário, selecione um modo que inclua a API EKS.
1. Na guia Acesso, crie uma nova entrada de acesso do IAM. Copie o ARN da função do IAM da fonte de nuvem primária e insira-o como o principal do IAM para a entrada de acesso. Clique em **Next**.
1. Selecione a política de AIOps AssistantPolicy acesso AWS gerenciada da **Amazon** e selecione **Cluster** para o escopo de acesso. (Como alternativa, se você quiser que o agente acesse apenas determinados namespaces, selecione os namespaces **Kubernetes** desejados). Clique em **Adicionar política** e, em seguida, clique em **Avançar**.
1. Analise as alterações e confirme se a política de entrada de acesso e a função do IAM corretas foram escolhidas e crie sua entrada de acesso clicando em **“Criar”**.
Para verificar se o acesso ao EKS foi configurado corretamente, navegue até o aplicativo Operator e inicie uma nova investigação, fazendo uma pergunta ao agente sobre seu cluster, como “listar todos os pods no namespace padrão” ou “mostrar eventos recentes em meu cluster”.
## Solução de problemas
Se o agente não conseguir acessar seu cluster, verifique se a entrada de acesso está usando o ARN correto da função do IAM mostrado na caixa de diálogo de configuração e se a política de AIOps AssistantPolicy acesso da **Amazon** está anexada.
# Conectando o Azure
A integração com o Azure permite que o AWS DevOps Agente investigue recursos em seu ambiente Azure e correlacione implantações de DevOps pipeline do Azure com incidentes operacionais. Ao conectar o Azure, o agente ganha visibilidade em sua infraestrutura do Azure e pode realizar análises de causa raiz em ambos os recursos AWS e no Azure.
A integração com o Azure consiste em dois recursos independentes:
+ **Recursos do Azure** — Permite que o agente descubra e investigue os recursos de nuvem do Azure, como máquinas virtuais, clusters do Azure Kubernetes Service (AKS), bancos de dados e componentes de rede. O agente usa o Azure Resource Graph para consultar seus recursos durante investigações de incidentes.
+ **Azure DevOps** — permite que o agente acesse os DevOps repositórios do Azure e o histórico de execução do pipeline. O agente pode correlacionar mudanças e implantações de código com incidentes para ajudar a identificar possíveis causas-raiz.
Cada recurso é registrado no nível da AWS conta e pode então ser associado a espaços de agentes individuais.
## Métodos de registro
AWS DevOps O agente oferece suporte a dois métodos para se conectar ao Azure:
+ **Consentimento do administrador — Um fluxo simplificado baseado em consentimento** em que você autoriza o aplicativo AWS DevOps Agent Entra em seu locatário do Azure. No console, isso aparece como a opção de **consentimento do administrador**. Esse método requer entrar com uma conta que tenha permissão para realizar o consentimento do administrador no Microsoft Entra ID.
+ **Registro de aplicativos** — Uma abordagem autogerenciada em que você cria seu próprio aplicativo Entra com credenciais de identidade federadas usando o Outbound Identity Federation. No console, isso aparece como a opção **Registro do aplicativo**. Esse método é adequado quando você precisa de mais controle sobre a configuração do aplicativo ou quando as permissões de consentimento do administrador não estão disponíveis.
Ambos os métodos oferecem os mesmos recursos. Você pode usar um ou os dois métodos na mesma AWS conta.
## Limitações conhecidas
+ **Consentimento do administrador: uma AWS conta por inquilino do Azure** — Cada inquilino do Azure só pode ter seu aplicativo AWS DevOps Agent Entra associado a uma AWS conta por vez. Para associar o mesmo inquilino a uma AWS conta diferente, você deve primeiro cancelar o registro existente.
+ **Registro de aplicativo: aplicativo exclusivo por registro** — Cada registro de aplicativo deve usar um aplicativo diferente (ID do cliente). Você não pode registrar várias configurações com o mesmo ID de cliente.
+ **Azure DevOps: acesso ao código-fonte** — A DevOps integração com o Azure fornece acesso ao histórico de execução do pipeline, independentemente de onde o código-fonte esteja hospedado. No entanto, para acessar o código-fonte real, o repositório deve ser conectado separadamente por meio de um provedor de origem compatível (por exemplo,[Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md)). O código-fonte hospedado no Bitbucket não pode ser acessado diretamente por meio da DevOps integração com o Azure.
## Tópicos
+ [Conectando recursos do Azure](connecting-azure-connecting-azure-resources.md)
+ [Conectando o Azure DevOps](connecting-azure-connecting-azure-devops.md)
# Conectando recursos do Azure
A integração com os Recursos do Azure permite que o AWS DevOps Agente descubra e investigue recursos em suas assinaturas do Azure durante investigações de incidentes. O agente usa o Azure Resource Graph para descobrir recursos e pode acessar métricas, registros e dados de configuração em seu ambiente do Azure.
Essa integração segue um processo de duas etapas: registrar o Azure no nível da AWS conta e associar assinaturas específicas do Azure a Agent Spaces individuais.
## Pré-requisitos
Antes de conectar os Recursos do Azure, verifique se você tem:
+ Acesso ao console do AWS DevOps agente
+ Uma conta do Azure com acesso à assinatura de destino
+ Para o método de consentimento do administrador: uma conta com permissão para realizar o consentimento do administrador no Microsoft Entra ID
+ Para o método de registro de aplicativos: um aplicativo Entra com permissões para configurar credenciais de identidade federada e [federação de identidade de saída](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) ativada em sua conta AWS
**Observação:** você também pode iniciar o registro em um Espaço do Agente. Navegue até **Fontes secundárias**, clique em **Adicionar** e selecione **Azure**. Se o Azure Cloud ainda não estiver registrado, o console o guiará primeiro pelo registro.
## Registrando recursos do Azure por meio do consentimento do administrador
O método Admin Consent usa um fluxo baseado em consentimento com o aplicativo gerenciado pelo AWS DevOps agente.
### Etapa 1: iniciar o registro
1. Faça login no console AWS de gerenciamento e navegue até o console do AWS DevOps agente
1. Acesse a página **Provedores de Capacidades**
1. Localize a seção **Azure Cloud** e clique em **Registrar**
1. Selecione o método de registro **do Admin Consent**
### Etapa 2: Consentimento completo do administrador
1. Revise as permissões que estão sendo solicitadas
1. Clique para continuar — você será redirecionado para a página de consentimento do administrador do Microsoft Entra
1. Faça login com uma conta principal de usuário que tenha permissão para realizar o consentimento do administrador
1. Revise e conceda consentimento para a inscrição do AWS DevOps Agente
### Etapa 3: Concluir a autorização do usuário
1. Após o consentimento do administrador, você receberá uma solicitação de autorização do usuário para verificar sua identidade como membro do inquilino autorizado
1. Entre com uma conta pertencente ao mesmo locatário do Azure
1. Após a autorização, você é redirecionado de volta para o console do AWS DevOps agente com um status de sucesso
### Etapa 4: atribuir funções
Consulte [Atribuição de funções do Azure](#assigning-azure-roles) abaixo. Procure um **AWS DevOps agente** ao selecionar membros.
## Registrando recursos do Azure por meio do registro de aplicativos
O método de registro do aplicativo usa seu próprio aplicativo Entra com credenciais de identidade federadas.
### Etapa 1: iniciar o registro
1. No console do AWS DevOps agente, acesse a página **Capability Providers**
1. Localize a seção **Azure Cloud** e clique em **Registrar**
1. Selecione o método de **registro do aplicativo**
### Etapa 2: Crie e configure seu aplicativo Entra
Siga as instruções exibidas no console para:
1. Ative a federação de identidade de saída em sua AWS conta (no console do IAM, acesse **Configurações da conta** → Federação de **identidade de saída**)
1. Crie um aplicativo Entra em seu Microsoft Entra ID ou use um existente
1. Configurar credenciais de identidade federada no aplicativo
### Etapa 3: fornecer detalhes do registro
Preencha o formulário de inscrição com:
+ **ID do inquilino** — Seu identificador de inquilino do Azure
+ **Nome do inquilino — Um nome** de exibição para o inquilino
+ **ID do cliente** — O ID do aplicativo (cliente) do aplicativo Entra que você criou
+ **Público** — O identificador de público para a credencial federada
### Etapa 4: criar a função do IAM
Uma função do IAM será criada automaticamente quando você enviar o registro pelo console. Ele permite que o AWS DevOps Agente assuma as credenciais e invoque. `sts:GetWebIdentityToken`
### Etapa 5: atribuir funções
Consulte [Atribuição de funções do Azure](#assigning-azure-roles) abaixo. Pesquise o aplicativo Entra que você criou ao selecionar membros.
### Etapa 6: Concluir o registro
1. Confirme a configuração no console do AWS DevOps agente
1. Clique em **Enviar** para concluir o registro
## Atribuição de funções do Azure
Após o registro, conceda ao aplicativo acesso de leitura à sua assinatura do Azure. Essa etapa é a mesma para os métodos de consentimento do administrador e registro do aplicativo.
1. No Portal do Azure, navegue até sua assinatura de destino
1. Vá para **Controle de acesso (IAM)**
1. Clique em **Adicionar** > **Adicionar atribuição de função**
1. Selecione a função **Leitor** e clique em **Avançar**
1. Clique em **Selecionar membros**, pesquise o aplicativo (**AWS DevOps Agente** para consentimento do administrador ou seu próprio aplicativo Entra para registro do aplicativo)
1. Selecione o aplicativo e clique em **Revisar \$1 atribuir**
1. (Opcional) Para permitir que o agente acesse clusters do Azure Kubernetes Service (AKS), conclua a seguinte configuração de acesso ao AKS.
**Requisito de segurança:** O responsável pelo serviço deve receber somente a função de **Leitor** (e, opcionalmente, as funções somente de leitura do AKS listadas abaixo). A função Reader serve como um limite de segurança que restringe o agente a operações somente de leitura e limita o impacto de ataques indiretos de injeção imediata. A atribuição de funções com permissões de gravação ou ação aumenta significativamente o raio de explosão da injeção imediata e pode resultar no comprometimento dos recursos do Azure. AWS DevOps O agente executa somente operações de leitura. O agente não modifica, cria nem exclui recursos do Azure.
### Configuração de acesso AKS (opcional)
#### Etapa 1: acesso no nível do Azure Resource Manager (ARM)
Atribua a **função de usuário do Azure Kubernetes Service Cluster ao aplicativo**.
No Portal do Azure, acesse **Assinaturas** → selecione assinatura → **Controle de Acesso (IAM)** → **Adicionar atribuição de função** → selecione Função de **Usuário do Azure Kubernetes Service Cluster** → atribuir ao aplicativo (**AWS DevOps Agente** para Consentimento do Administrador ou seu próprio aplicativo Entra para Registro do Aplicativo).
Isso abrange todos os clusters do AKS na assinatura. Para definir o escopo para clusters específicos, atribua no nível do grupo de recursos ou do cluster individual.
#### Etapa 2: acesso à API Kubernetes
Escolha uma opção com base na configuração de autenticação do seu cluster:
**Opção A: Controle de Acesso Baseado em Função (RBAC) do Azure para Kubernetes (recomendado)**
1. **Ative o Azure RBAC no cluster, se ainda não estiver habilitado: Portal do Azure → Cluster AKS → **Configurações** → **Configuração de segurança** → **Autenticação e autorização** → selecione Azure RBAC**
1. Atribuir função somente para leitura: Portal do Azure → **Assinaturas** → selecionar assinatura → **Controle de acesso (IAM)** → **Adicionar atribuição de função → selecionar **Azure Kubernetes** Service RBAC Reader → atribuir** ao aplicativo
Isso abrange todos os clusters do AKS na assinatura.
**Opção B: Azure Active Directory (Azure AD) \$1 Kubernetes RBAC**
Use isso se seu cluster já usa a configuração padrão de autenticação do Azure AD e você prefere não habilitar o RBAC do Azure. Isso requer `kubectl` configuração por cluster.
1. Salve o seguinte manifesto como`devops-agent-reader.yaml`:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-agent-reader
rules:
- apiGroups: [""]
resources: ["namespaces", "pods", "pods/log", "services", "events", "nodes"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
verbs: ["get", "list"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: devops-agent-reader-binding
subjects:
- kind: User
name: ""
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: devops-agent-reader
apiGroup: rbac.authorization.k8s.io
```
1. ``Substitua pelo ID do objeto do seu diretor de serviço. Para encontrá-lo: Portal do Azure → Inserir ID → Aplicativos corporativos → pesquise o nome do aplicativo (**AWS DevOps Agente** para consentimento do administrador ou seu próprio aplicativo Entra para registro do aplicativo).
1. Aplique a cada cluster:
```
az aks get-credentials --resource-group --name
kubectl apply -f devops-agent-reader.yaml
```
**Observação:** clusters usando somente contas locais (sem o Azure AD) não são compatíveis. Recomendamos habilitar a integração do Azure AD em seu cluster para usar esse recurso.
### Função personalizada com menos privilégios (opcional)
Para um controle de acesso mais rígido, você pode criar uma função personalizada do Azure com escopo exclusivo para os provedores de recursos que o AWS DevOps Agente usa, em vez da função ampla do Reader:
```
{
"Name": "AWS DevOps Agent - Azure Reader",
"Description": "Least-privilege read-only access for AWS DevOps Agent incident investigations.",
"Actions": [
"Microsoft.AlertsManagement/*/read",
"Microsoft.Compute/*/read",
"Microsoft.ContainerRegistry/*/read",
"Microsoft.ContainerService/*/read",
"Microsoft.ContainerService/managedClusters/commandResults/read",
"Microsoft.DocumentDB/*/read",
"Microsoft.Insights/*/read",
"Microsoft.KeyVault/vaults/read",
"Microsoft.ManagedIdentity/*/read",
"Microsoft.Monitor/*/read",
"Microsoft.Network/*/read",
"Microsoft.OperationalInsights/*/read",
"Microsoft.ResourceGraph/resources/read",
"Microsoft.ResourceHealth/*/read",
"Microsoft.Resources/*/read",
"Microsoft.Sql/*/read",
"Microsoft.Storage/*/read",
"Microsoft.Web/*/read"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/{your-subscription-id}"
]
}
```
## Associando uma assinatura a um Agent Space
Depois de registrar o Azure no nível da conta, associe assinaturas específicas aos seus Agent Spaces:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. Na seção **Fontes secundárias**, clique em **Adicionar**
1. Selecione **Azure**
1. Forneça a **ID de assinatura** para a assinatura do Azure que você deseja associar
1. Clique em **Adicionar** para concluir a associação
Você pode associar várias assinaturas ao mesmo Espaço do Agente para dar visibilidade ao agente em todo o seu ambiente do Azure.
## Gerenciando conexões do Azure Resources
+ **Visualizando assinaturas conectadas** — Na guia **Capacidades**, a seção **Fontes secundárias** lista todas as assinaturas conectadas do Azure.
+ **Removendo uma assinatura** — Para desconectar uma assinatura de um Espaço do Agente, selecione-a na lista **Fontes secundárias** e clique em **Remover**. Isso não afeta o registro no nível da conta.
+ **Removendo o registro** — Para remover totalmente o registro do Azure Cloud, acesse a página **Capability Providers** e exclua o registro. Todas as associações do Agent Space devem ser removidas primeiro.
# Conectando o Azure DevOps
DevOps A integração com o Azure permite que o AWS DevOps Agente acesse repositórios e o histórico de execução do pipeline em sua DevOps organização do Azure. O agente pode correlacionar mudanças e implantações de código com incidentes operacionais para ajudar a identificar possíveis causas-raiz.
**Observação:** os DevOps pipelines do Azure podem usar o código-fonte do Azure Repos ou do GitHub Bitbucket. A DevOps integração com o Azure fornece acesso ao histórico de execução do pipeline, independentemente do provedor de origem. No entanto, para acessar o código-fonte real durante as investigações, o repositório deve ser conectado separadamente por meio de uma integração compatível, como[Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md). O código-fonte no Bitbucket não está diretamente acessível por meio dessa integração.
Essa integração segue um processo de duas etapas: registrar o Azure DevOps no nível da AWS conta e associar projetos específicos a Agent Spaces individuais.
## Pré-requisitos
Antes de conectar o Azure DevOps, verifique se você tem:
+ Acesso ao console do AWS DevOps agente
+ Uma DevOps organização do Azure com pelo menos um projeto contendo um histórico de repositório e pipeline
+ Permissões para adicionar usuários à sua DevOps organização do Azure
+ Para o método de consentimento do administrador: uma conta com permissão para realizar o consentimento do administrador no Microsoft Entra ID
+ Para o método de registro de aplicativos: um aplicativo Entra com permissões para configurar credenciais de identidade federadas e [federação de identidade de saída](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) ativada em sua conta AWS
**Observação:** você também pode iniciar o registro em um Espaço do Agente. Navegue até a seção **Pipelines**, clique em **Adicionar** e selecione **Azure DevOps**. Se o Azure ainda não DevOps estiver registrado, o console o guiará primeiro pelo registro.
## Registrando o Azure DevOps por meio do consentimento do administrador
O método Admin Consent usa um fluxo baseado em consentimento com o aplicativo gerenciado pelo AWS DevOps agente.
### Etapa 1: iniciar o registro
1. Faça login no console AWS de gerenciamento e navegue até o console do AWS DevOps agente
1. Acesse a página **Provedores de Capacidades**
1. Localize a DevOps seção **Azure** e clique em **Registrar**
1. Insira o **nome DevOps da sua organização do Azure** quando solicitado
### Etapa 2: Consentimento completo do administrador
1. Clique para continuar - você será redirecionado para a página de consentimento do administrador do Microsoft Entra
1. Faça login com uma conta principal de usuário que tenha permissão para realizar o consentimento do administrador
1. Revise e conceda consentimento para a inscrição do AWS DevOps Agente
### Etapa 3: Concluir a autorização do usuário
1. Após o consentimento do administrador, você receberá uma solicitação de autorização do usuário para verificar sua identidade como membro do inquilino autorizado
1. Entre com uma conta pertencente ao mesmo locatário do Azure
1. Após a autorização, você é redirecionado de volta para o console do AWS DevOps agente com um status de sucesso
### Etapa 4: conceder acesso no Azure DevOps
Consulte [Conceder acesso no Azure DevOps](#granting-access-in-azure-devops) abaixo. Pesquise o **AWS DevOps Agente** ao adicionar usuários.
## Registrando o Azure DevOps por meio do registro de aplicativos
O Registro do Aplicativo é compartilhado entre os Recursos do Azure e o Azure DevOps. Se você já concluiu o Registro do Aplicativo para Recursos do Azure, pode pular para [Conceder acesso no](#granting-access-in-azure-devops) Azure. DevOps
### Etapa 1: iniciar o registro do aplicativo ADO
1. No console do AWS DevOps agente, acesse a página **Capability Providers**
1. Localize a seção **Azure Cloud** e clique em **Registrar**
1. Selecione o método de **registro do aplicativo**
### Etapa 2: Crie e configure seu aplicativo Entra
Siga as instruções exibidas no console para:
1. Ative a federação de identidade de saída em sua AWS conta (no console do IAM, acesse **Configurações da conta** → Federação de **identidade de saída**)
1. Crie um aplicativo Entra em seu Microsoft Entra ID ou use um existente
1. Configurar credenciais de identidade federada no aplicativo
### Etapa 3: fornecer detalhes do registro
Preencha o formulário de inscrição com:
+ **ID do inquilino** — Seu identificador de inquilino do Azure
+ **Nome do inquilino — Um nome** de exibição para o inquilino
+ **ID do cliente** — O ID do aplicativo (cliente) do aplicativo Entra
+ **Público** — O identificador de público para a credencial federada
### Etapa 4: criar a função do IAM
Uma função do IAM será criada automaticamente quando você enviar o registro pelo console. Ele permite que o AWS DevOps Agente assuma as credenciais e invoque. `sts:GetWebIdentityToken`
### Etapa 5: Concluir o registro
1. Confirme a configuração no console do AWS DevOps agente
1. Clique em **Enviar** para concluir o registro
### Etapa 6: Conceder acesso no Azure DevOps
Consulte [Conceder acesso no Azure DevOps](#granting-access-in-azure-devops) abaixo. Pesquise o aplicativo Entra que você criou durante o registro do aplicativo ao adicionar usuários.
## Concedendo acesso no Azure DevOps
Após o registro, conceda ao aplicativo acesso à sua DevOps organização do Azure. Essa etapa é a mesma para os métodos de consentimento do administrador e registro do aplicativo.
1. No Azure DevOps, vá para **Configurações da organização** > **Usuários** > **Adicionar usuários**
1. Pesquise o aplicativo (seja **AWS DevOps Agent** for Admin Consent ou seu próprio aplicativo Entra para registro de aplicativos)
1. Defina o nível de acesso como **Básico**
1. Em **Adicionar aos projetos**, selecione os projetos que você deseja que o agente acesse
1. Em ** DevOps Grupos do Azure**, selecione **Project Readers**
1. Clique em **Adicionar** para concluir
**Requisito de segurança:** atribua somente o grupo de **leitores do projeto**. O acesso somente leitura serve como um limite de segurança que restringe o agente a operações somente de leitura e limita o impacto de ataques indiretos de injeção imediata. Atribuir grupos com permissões de gravação ou ação aumenta significativamente o raio de explosão da injeção imediata e pode resultar no comprometimento dos recursos do Azure. DevOps
## Associando um projeto a um Agent Space
Depois de registrar o Azure DevOps no nível da conta, associe projetos específicos aos seus Agent Spaces:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. **Na seção **Pipelines**, clique em Adicionar**
1. Selecione **Azure DevOps** na lista de provedores disponíveis
1. Selecione o projeto na lista suspensa de projetos disponíveis
1. Clique em **Adicionar** para concluir a associação
## Gerenciando DevOps conexões do Azure
+ **Visualizando projetos conectados** — Na guia **Capacidades**, a seção **Pipelines** lista todos os DevOps projetos conectados do Azure.
+ **Removendo um projeto** **— Para desconectar um projeto de um Espaço do Agente, selecione-o na seção **Pipelines** e clique em Remover.**
+ **Removendo o registro** — Para remover totalmente o DevOps registro do Azure, acesse a página **Provedores de Capacidade** e exclua o registro. Todas as associações do Agent Space devem ser removidas primeiro.
# Conexão a CI/CD tubulações
A integração do pipeline de CI/CD permite que o AWS DevOps Agente monitore implantações e correlacione alterações de código com incidentes operacionais durante as investigações. Ao conectar seus CI/CD provedores, o agente pode rastrear eventos de implantação e associá-los a AWS recursos para ajudar a identificar possíveis causas-raiz durante a resposta a incidentes.
AWS DevOps O Agent oferece suporte à integração com CI/CD plataformas populares por meio de um processo de duas etapas:
1. Registro **no nível da conta — Registre** seu CI/CD provedor uma vez no nível da AWS conta
1. **Conexão com o Agent Space** — Conecte projetos ou repositórios específicos a Agent Spaces individuais com base em suas necessidades organizacionais
Essa abordagem permite que você compartilhe registros de CI/CD provedores em vários Agent Spaces, mantendo um controle granular sobre quais projetos são monitorados por cada espaço.
## CI/CD Provedores compatíveis
AWS DevOps O Agent oferece suporte às seguintes CI/CD plataformas:
+ **GitHub**— Conecte repositórios de [GitHub.com](http://GitHub.com) usando o GitHub aplicativo AWS DevOps Agent.
+ **GitLab**— Conecte projetos de [GitLab.com,](http://gitlab.com) GitLab instâncias gerenciadas ou GitLab implantações auto-hospedadas acessíveis ao público.
**Tópicos**
+ [Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md)
+ [Conectando GitLab](connecting-to-cicd-pipelines-connecting-gitlab.md)
# Conectando GitHub
GitHub a integração permite que o AWS DevOps Agente acesse repositórios de código e receba eventos de implantação durante investigações de incidentes. Essa integração segue um processo de duas etapas: registro em nível de conta GitHub, seguido pela conexão de repositórios específicos a Agent Spaces individuais.
AWS DevOps O agente é compatível com GitHub instâncias.com (SaaS) e GitHub Enterprise Server (auto-hospedadas).
## Pré-requisitos
Antes de se conectar GitHub, verifique se você tem:
+ Acesso ao console de administração do AWS DevOps agente
+ Uma conta de GitHub usuário ou organização com permissões de administrador
+ Autorização para instalar GitHub aplicativos em sua conta ou organização
Para o GitHub Enterprise Server, você também precisa:
+ Uma instância do GitHub Enterprise Server (versão 3.x ou posterior) acessível por HTTPS
+ O URL HTTPS da sua instância do GitHub Enterprise Server (por exemplo,`https://github.example.com`)
+ (Opcional) Uma conexão privada, se sua instância do GitHub Enterprise Server não estiver acessível publicamente
## Registro GitHub (nível da conta)
GitHub é registrado no nível da AWS conta e compartilhado entre todos os Agent Spaces dessa conta. Você só precisa se registrar GitHub uma vez por AWS conta.
### Etapa 1: Navegar até os fornecedores de funil
1. Faça login no console AWS de gerenciamento
1. Navegue até o console do AWS DevOps agente
1. Vá para a guia **Capacidades**
1. Na seção **Pipeline**, clique em **Adicionar**
1. **GitHub**Selecione na lista de provedores disponíveis
Se GitHub ainda não tiver sido registrado, você será solicitado a registrá-lo primeiro.
### Etapa 2: Escolha o tipo de conexão
Na tela “Registrar GitHub conta/organização”, selecione se você está se conectando como usuário ou organização:
+ **Usuário** — Sua GitHub conta pessoal com nome de usuário e perfil
+ **Organização** — Uma GitHub conta compartilhada em que várias pessoas podem colaborar em vários projetos ao mesmo tempo
Se você estiver se conectando a uma instância do GitHub Enterprise Server, marque a caixa de seleção **Usar GitHub Enterprise Server** e insira a URL HTTPS da sua instância (por exemplo,`https://github.example.com`).
Se sua instância do GitHub Enterprise Server não estiver acessível publicamente, você pode, opcionalmente, configurar uma conexão privada para permitir que o AWS DevOps Agente acesse sua instância com segurança. Para obter mais informações, consulte [Conectando-se a ferramentas hospedadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
**nota**
**Não `/api/v3` inclua nenhum caminho final no URL — insira somente o URL base.
### Etapa 3: configurar o GitHub aplicativo
Clique em **Enviar** para iniciar o processo de configuração do aplicativo. As próximas etapas são diferentes dependendo se você está se conectando a GitHub .com ou ao GitHub Enterprise Server.
#### Para GitHub .com
1. Você será redirecionado para GitHub instalar o GitHub aplicativo AWS DevOps Agent.
1. Selecione em qual conta ou organização instalar o aplicativo.
1. O aplicativo permite que o AWS DevOps Agente receba eventos de repositórios conectados, incluindo eventos de implantação.
#### Para servidor GitHub corporativo
GitHub O Enterprise Server usa um fluxo de manifesto de GitHub aplicativo, que configura automaticamente um novo GitHub aplicativo na sua instância. Isso envolve dois redirecionamentos para sua instância do GitHub Enterprise Server.
1. Seu navegador será redirecionado para a página “Criar GitHub aplicativo” da sua instância do GitHub Enterprise Server.
1. Você verá o nome do aplicativo pré-preenchido. Sinta-se à vontade para alterar o nome conforme necessário. Clique em **Criar GitHub aplicativo**.
1. Você será redirecionado de volta para o AWS DevOps Agent, que troca o código do manifesto pelas credenciais do aplicativo.
### Etapa 4: selecionar repositórios e concluir a instalação
1. Você verá a página **Instalar e Autorizar** do GitHub aplicativo.
1. Selecione quais repositórios permitir que o aplicativo acesse:
+ **Todos os repositórios** — Conceda acesso a todos os repositórios atuais e futuros
+ **Selecione somente repositórios** — Escolha repositórios específicos da sua conta ou organização
1. Clique em **Instalar e autorizar.**
1. Você será redirecionado de volta ao console do AWS DevOps agente, onde GitHub aparecerá como registrado no nível da conta.
## Conectando repositórios a um Espaço do Agente
Depois de se registrar GitHub no nível da conta, você pode conectar repositórios específicos a Agent Spaces individuais:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. Na seção **Pipeline**, clique em **Adicionar**
1. **GitHub**Selecione na lista de provedores disponíveis
1. Selecione o subconjunto de repositórios relevantes para esse Espaço do Agente
1. Clique em **Adicionar** para concluir a conexão
Você pode conectar diferentes conjuntos de repositórios a diferentes Agent Spaces com base nas suas necessidades organizacionais.
## Entendendo o GitHub aplicativo
O GitHub aplicativo AWS DevOps Agent:
+ Solicita acesso somente de leitura aos seus repositórios
+ Recebe eventos de implantação e outros eventos do repositório
+ Permite que o AWS DevOps agente correlacione alterações de código com incidentes operacionais
+ Pode ser desinstalado a qualquer momento por meio de suas configurações GitHub
Para o GitHub Enterprise Server, o GitHub aplicativo é criado automaticamente na sua instância durante o registro. Você pode gerenciar o acesso ao repositório do aplicativo ou desinstalá-lo em **Configurações > Aplicativos > GitHub Aplicativos instalados**. Para excluir totalmente a definição do aplicativo, acesse **Configurações > Configurações do desenvolvedor > GitHub Aplicativos**.
## Gerenciando GitHub conexões
+ **Atualizando o acesso ao repositório** — Para alterar quais repositórios o GitHub aplicativo pode acessar, acesse as configurações da sua GitHub conta ou organização (ou as configurações da instância do GitHub Enterprise Server), navegue até os GitHub aplicativos instalados e modifique a configuração do aplicativo do AWS DevOps Agente.
+ **Visualizando repositórios conectados** — No console do AWS DevOps Agente, selecione seu Espaço do Agente e vá até a guia Capacidades para visualizar os repositórios conectados na seção Pipeline.
+ **Removendo a GitHub conexão** — Para se desconectar GitHub de um Espaço do Agente, selecione a conexão na seção Pipeline e clique em **Remover**. Para desinstalar completamente o GitHub aplicativo, desinstale-o das configurações da sua GitHub conta ou organização. Para o GitHub Enterprise Server, como o GitHub aplicativo é criado diretamente na sua instância durante o registro, você pode, opcionalmente, limpar o aplicativo por completo executando as duas ações a seguir:
+ **Desinstalar o aplicativo** — Vá para **Configurações > Aplicativos > GitHub Aplicativos instalados**, clique em **Configurar** no aplicativo e, em seguida, desinstale-o.
+ **Excluir o aplicativo** — Vá para **Configurações > Configurações do desenvolvedor > GitHub Aplicativos**, selecione o aplicativo, vá até a guia **Avançado** e escolha **Excluir GitHub aplicativo**. **Aviso:** a exclusão do GitHub aplicativo é permanente e não pode ser desfeita. Se você excluí-lo, precisará registrar novamente o GitHub Enterprise Server desde o início no console do AWS DevOps Agente para criar um novo aplicativo.
# Conectando GitLab
GitLab a integração permite que o AWS DevOps Agente monitore as implantações do GitLab Pipelines para informar as investigações causais durante a resposta a incidentes. Essa integração segue um processo de duas etapas: registro em nível de conta GitLab, seguido pela conexão de projetos específicos a Agent Spaces individuais.
## Registro GitLab (nível da conta)
GitLab é registrado no nível da AWS conta e compartilhado entre todos os Agent Spaces dessa conta. Os Agent Spaces individuais podem então escolher quais projetos específicos se aplicam ao seu Agent Space.
### Etapa 1: Navegar até os fornecedores de funil
1. Faça login no console AWS de gerenciamento
1. Navegue até o console do AWS DevOps agente
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Encontre **GitLab**na seção Provedores **disponíveis** em **Pipeline** e clique em **Registrar**
### Etapa 2: configurar a GitLab conexão
Na página GitLab de registro, configure o seguinte:
**Tipo de conexão** — Selecione se você está se conectando como pessoa ou grupo:
+ **Pessoal** (padrão) — Sua conta de GitLab usuário individual com nome de usuário e perfil
+ **Grupo** — Em GitLab, você usa grupos para gerenciar um ou mais projetos relacionados ao mesmo tempo
**GitLab tipo de instância** — Escolha a qual tipo de GitLab instância você está se conectando:
+ **GitLab.com** (padrão) — O GitLab serviço público
+ **Auto-hospedado publicamente acessível GitLab** — marque a caixa **Usar endpoint GitLab auto-hospedado** e forneça o URL para sua instância GitLab
**nota**
**Atualmente, somente GitLab instâncias acessíveis ao público são suportadas.
**Token de acesso** — Forneça um token de acesso GitLab pessoal:
1. Em uma guia separada do navegador, faça login na sua GitLab conta
1. Navegue até suas configurações de usuário e selecione **Tokens de acesso**
1. Crie um novo token de acesso pessoal com as seguintes permissões:
+ `read_repository`— Necessário para acessar o conteúdo do repositório
+ `read_virtual_registry`— Necessário para acessar as informações do registro virtual
+ `read_registry`— Necessário para acessar as informações do registro
+ `api`— Necessário para acesso à API de leitura e gravação
+ `self_rotate`- Necessário para tokens rotativos. No momento, esse recurso não é suportado pelo AWS DevOps Agente, mas será suportado em uma data posterior. Adicionar agora evita a necessidade de criar um novo token no futuro.
1. Defina a expiração do token para um máximo de 365 dias a partir da data atual
1. Copie o token gerado
1. Retornar ao console do AWS DevOps agente
1. Cole o token no campo “Token de acesso”
### Etapa 3: Concluir o registro
**(Opcional) Tags** — Adicione AWS tags ao GitLab registro para fins organizacionais.
Clique em **Avançar** para revisar sua configuração e, em seguida, clique em **Enviar** para concluir o processo de GitLab registro. O sistema validará seu token de acesso e estabelecerá a conexão.
## Conectando projetos a um Agent Space
Depois de se registrar GitLab no nível da conta, você pode conectar projetos específicos a Agent Spaces individuais:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. Na seção **Pipeline**, clique em **Adicionar**
1. **GitLab**Selecione na lista de provedores disponíveis
1. Selecione os GitLab projetos relevantes para o seu Espaço do Agente
1. Clique em **Salvar**
AWS DevOps O agente monitorará esses projetos para implantações da GitLab Pipelines para informar as investigações causais.
## Gerenciando GitLab conexões
+ **Atualização do token** de acesso — Se seu token de acesso expirar ou precisar ser atualizado, você poderá atualizá-lo no console do AWS DevOps agente modificando o GitLab registro no nível da conta.
+ **Visualização de projetos conectados** — No console do AWS DevOps agente, selecione seu Espaço do agente e vá até a guia Capacidades para visualizar os projetos conectados na seção Pipeline.
+ **Removendo a GitLab conexão** — Para desconectar GitLab projetos de um Espaço do Agente, selecione a conexão na seção Pipeline e clique em **Remover**. Para remover completamente o GitLab registro, primeiro remova-o de todos os Agent Spaces e, em seguida, exclua o registro no nível da conta.
# Conectando servidores MCP
Os servidores do Model Context Protocol (MCP) ampliam os recursos de investigação do AWS DevOps Agente fornecendo acesso aos dados de suas ferramentas externas de observabilidade, sistemas de monitoramento personalizados e fontes de dados operacionais. Este guia explica como conectar um servidor MCP ao AWS DevOps Agente.
## Requisitos
Antes de conectar um servidor MCP, certifique-se de que seu servidor atenda aos seguintes requisitos:
+ **Protocolo de transporte HTTP simplificável** — Somente servidores MCP que implementam o protocolo de transporte HTTP simplificável são suportados.
+ **Suporte de autenticação** — Seu servidor MCP deve suportar fluxos de autenticação OAuth 2.0 ou autenticação baseada em chave de API/token.
## Considerações sobre segurança
Ao conectar servidores MCP ao AWS DevOps Agente, considere estes aspectos de segurança:
+ **Lista de permissões de ferramentas —** Você deve listar somente as ferramentas específicas de que seu Espaço do Agente precisa, em vez de expor todas as ferramentas do seu servidor MCP. Consulte [Configurando ferramentas MCP em um Espaço do Agente](#configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers) para saber como permitir ferramentas de lista por Espaço do Agente.
Observe que o comprimento máximo da ferramenta de qualquer ferramenta MCP é 64.
+ **Riscos de injeção imediata** — servidores MCP personalizados podem introduzir riscos adicionais de ataques de injeção imediata. Consulte [Proteção imediata por injeção: AWS DevOps Agent Security](aws-devops-agent-security.md) para obter mais informações.
+ **Ferramentas e acesso somente para leitura — Liste somente as ferramentas** MCP somente para leitura e garanta que as credenciais de autenticação tenham permissão somente para acesso somente para leitura.
Consulte [AWS DevOps Segurança do agente](aws-devops-agent-security.md) para obter mais informações sobre injeção imediata e o modelo de responsabilidade compartilhada.
**nota**
Se o seu servidor MCP estiver em uma rede privada, consulte [Conectando-se a ferramentas hospedadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)
## Registrando um servidor MCP (nível de conta)
Os servidores MCP são registrados no nível da AWS conta e compartilhados entre todos os Agent Spaces nessa conta. Os Agent Spaces individuais podem então escolher quais ferramentas específicas precisam de cada servidor MCP.
### Etapa 1: detalhes do servidor MCP
1. Faça login no console AWS de gerenciamento
1. Navegue até o console do AWS DevOps agente
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre o **MCP Server** na seção Provedores **disponíveis** e clique em Registrar**
1. Na página de **detalhes do servidor MCP**, insira as seguintes informações:
+ **Nome** — Insira um nome descritivo para seu servidor MCP
+ **URL do endpoint** — insira o URL HTTPS completo do endpoint do servidor MCP
+ **Descrição** (opcional) — Adicione uma descrição para ajudar a identificar a finalidade do servidor
+ **Ativar registro dinâmico de clientes** — Marque essa caixa de seleção se quiser permitir que o AWS DevOps Agente se registre automaticamente no servidor de autorização do seu servidor MCP.
1. Clique em **Avançar**.
**nota**
**O URL do endpoint do servidor MCP será exibido nos AWS CloudTrail registros da sua conta.
### Etapa 2: fluxo de autorização
Selecione o método de autenticação para seu servidor MCP:
**OAuth Credenciais do cliente** — Se o servidor MCP usar o fluxo de credenciais OAuth do cliente:
1. Selecione as **credenciais OAuth do cliente**
1. Clique em **Avançar**.
**OAuth 3LO (Three-Legged OAuth)** — Se o seu servidor MCP usa OAuth 3LO para autenticação:
1. Selecione **OAuth 3LO**
1. Clique em **Avançar**.
**Chave de API** — Se seu servidor MCP usa autenticação de chave de API:
1. Selecione a **chave de API**
1. Clique em **Avançar**.
### Etapa 3: configuração da autorização
Configure parâmetros de autorização adicionais com base no método de autenticação selecionado:
**Para credenciais OAuth do cliente:**
1. **ID do cliente** — insira o ID do OAuth cliente
1. **Segredo** do cliente — Insira o segredo do OAuth cliente
1. **URL do Exchange** — Insira o URL do endpoint de troca de OAuth tokens
1. **Parâmetros de troca** — insira os parâmetros de troca de OAuth tokens para autenticação com o serviço
1. **Adicionar escopo** — Adicione OAuth escopos para autenticação
1. Clique em **Avançar**.
**Para OAuth 3LO:**
1. **ID do cliente** — insira o ID do OAuth cliente
1. **Segredo** do cliente — Insira o segredo do OAuth cliente se for exigido pelo seu OAuth cliente
1. **URL do Exchange** — Insira o URL do endpoint de troca de OAuth tokens
1. **URL de autorização** - Insira a URL do endpoint de OAuth autorização
1. **Suporte ao Code Challenge** - Marque essa caixa de seleção se seu OAuth cliente suportar o Code Challenge
1. **Adicionar escopo** — Adicione OAuth escopos para autenticação
1. Clique em **Avançar**.
**Para chave de API:**
1. Insira um nome de chave de API
1. Insira o nome do cabeçalho que conterá a chave de API na solicitação
1. Insira o valor da sua chave de API
1. Clique em **Avançar**.
### Etapa 4: revisar e enviar
1. Revise todos os detalhes da configuração do servidor MCP
1. Clique em **Enviar** para concluir o registro
1. AWS DevOps O agente validará a conexão com seu servidor MCP
1. Após a validação bem-sucedida, seu servidor MCP será registrado no nível da conta
## Configurando ferramentas MCP em um espaço de agente
Depois de registrar um servidor MCP no nível da conta, você pode configurar quais ferramentas desse servidor estão disponíveis para Agent Spaces específicos:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. **Na seção **Servidores MCP**, clique em Adicionar**
1. Selecione o servidor MCP registrado que você deseja conectar a este Espaço do Agente
1. Configure quais ferramentas desse servidor MCP devem estar disponíveis para o Espaço do Agente:
+ **Permitir todas as ferramentas** — Disponibiliza todas as ferramentas do servidor MCP
+ **Selecionar ferramentas específicas** — Permite que você escolha quais ferramentas serão permitidas na lista.
1. Clique em **Adicionar** para conectar o servidor MCP ao seu Espaço do Agente.
AWS DevOps Agora, o agente poderá usar as ferramentas da lista de permissões do seu servidor MCP durante as investigações neste Espaço do Agente.
## Gerenciando conexões do servidor MCP
**Atualização das credenciais de autenticação** — Se suas credenciais de autenticação precisarem ser atualizadas, você precisará registrar novamente o servidor MCP. Navegue até a página **Capability Providers** no console do AWS DevOps agente, localize seu servidor MCP, remova todas as associações ativas e clique em **Cancelar** registro. Em seguida, **registre** seu servidor MCP com as novas credenciais de autenticação e recrie todas as associações necessárias com seu Espaço do Agente.
**Visualizando servidores MCP conectados** — Para ver todos os servidores MCP conectados ao seu Espaço do Agente, selecione seu Espaço do Agente, vá até a guia **Capacidades** e verifique a seção Servidores **MCP.** Você também pode atualizar as ferramentas selecionadas aqui.
**Removendo conexões do servidor MCP** **— Para desconectar um servidor MCP de um Espaço do Agente, selecione o servidor na seção **Servidores MCP** e clique em Remover.** Para excluir completamente um registro do servidor MCP, primeiro remova-o de todos os Agent Spaces e, em seguida, exclua o registro no nível da conta.
## Tópicos relacionados
+ Segurança no AWS DevOps Agent
+ Configurando um Espaço do Agente
+ Proteção imediata de injeção
# Conectando várias AWS contas
AWS As contas secundárias permitem que o AWS DevOps Agente investigue recursos em várias AWS contas em sua organização. Quando seus aplicativos abrangem várias contas, adicionar contas secundárias garante que o agente tenha visibilidade de todos os recursos relevantes durante as investigações de incidentes. O maior acesso às contas e aos recursos que compõem um aplicativo garante maior precisão na investigação.
## Pré-requisitos
Antes de adicionar uma AWS conta secundária, verifique se você tem:
+ Acesso ao console do AWS DevOps agente na conta principal
+ Acesso administrativo à AWS conta secundária
+ Permissões do IAM para criar funções na conta secundária
## Adicionar uma AWS conta secundária
Além das etapas abaixo, você pode usar o [AWS DevOps Guia de integração do Agent CLI](getting-started-with-aws-devops-agent-cli-onboarding-guide.md) para adicionar contas secundárias de forma programática.
### Etapa 1: iniciar a configuração da conta secundária
1. Faça login no console AWS de gerenciamento e navegue até o console do AWS DevOps agente
1. Selecione seu espaço de agente
1. Vá para a guia **Capacidades**
1. Na seção **Nuvem**, localize a subseção **Fontes secundárias**
1. Clique em **Adicionar**
### Etapa 2: especificar o nome da função
1. No campo **Nome da sua função**, insira um nome para a função que você criará na conta secundária
1. Anote esse nome: você o usará novamente ao criar a função na conta secundária
1. Copie a política de confiança fornecida no console e salve-a em um espaço rascunho
### Etapa 3: criar a função na conta secundária
1. Abra uma nova guia do navegador e faça login no console do IAM na AWS conta secundária
1. Navegue até **IAM >** **Funções** > **Criar função**
1. Selecione **Política de confiança personalizada**
1. Cole a política de confiança que você copiou da Etapa 2
1. Clique em **Avançar**.
### Etapa 4: anexar a política AWS gerenciada
1. Na seção **Políticas de permissões**, pesquise **AIOpsAssistantPolicy**
1. Marque a caixa de seleção ao lado da política **AIOpsAssistantPolicy**gerenciada
1. Clique em **Avançar**.
### Etapa 5: nomear e criar a função
1. No campo **Nome da função**, insira o mesmo nome da função que você forneceu na Etapa 2
1. (Opcional) Adicione uma descrição para ajudar a identificar a finalidade da função
1. Revise a política de confiança e as permissões anexadas
1. Clique em **Criar função**
### Etapa 6: anexar a política em linha
1. No console do IAM, localize e selecione a função que você acabou de criar
1. Vá para a guia **Permissões**
1. Clique em **Adicionar permissões** > **Criar política em linha**
1. Mudar para a **guia JSON**
1. Cole a política que você salvou na Etapa 2
1. Cole a política no editor JSON no console do IAM
1. Clique em **Avançar**.
1. Forneça um nome para a política em linha (por exemplo, "DevOpsAgentInlinePolicy“)
1. Clique em **Criar política**
### Etapa 7: Concluir a configuração
1. Retorne ao console do AWS DevOps agente na conta principal
1. Clique em **Avançar** para concluir a configuração da conta secundária
1. Verifique se o status da conexão é exibido como **Ativo**
## Entendendo as políticas necessárias
AWS DevOps O agente exige três componentes de política para acessar recursos em uma conta secundária:
+ **Política de confiança** — permite que o AWS DevOps agente na conta principal assuma a função na conta secundária. Isso estabelece a relação de confiança entre as contas.
+ **AIOpsAssistantPolicy (política AWS gerenciada)** — Fornece as principais permissões de somente leitura que o AWS DevOps agente precisa para investigar recursos na conta secundária. Essa política é mantida AWS e atualizada à medida que novos recursos são adicionados.
+ **Política embutida** — fornece permissões adicionais específicas para sua configuração do Agent Space. Essa política é gerada com base nas configurações do seu Espaço do Agente e pode incluir permissões para integrações ou recursos específicos.
Na conta principal, a função do AWS DevOps Agent IAM deve ser capaz de assumir a função criada na conta secundária.
## Gerenciando contas secundárias
+ **Visualização de contas conectadas** — Na guia **Capacidades**, a subseção **Fontes secundárias** lista todas as contas secundárias conectadas com seu status de conexão.
+ **Atualização da função do IAM** — Se você precisar modificar as permissões, atualize a política embutida anexada à função na conta secundária. As alterações terão efeito imediatamente.
+ **Removendo uma conta secundária** — Para desconectar uma conta secundária, selecione-a na lista **Fontes secundárias** e clique em **Remover**. Isso não exclui a função do IAM na conta secundária.
# Conectando fontes de telemetria
AWS DevOps O agente fornece três maneiras de se conectar às suas fontes de telemetria.
## Integração bidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte aos usuários do Dynatrace com uma integração bidirecional integrada que permite o seguinte:
+ **Mapeamento de recursos de topologia** - O AWS DevOps agente aumentará sua topologia do espaço do DevOps agente com entidades e relacionamentos disponíveis por meio de um servidor Dynatrace MCP hospedado por um AWS DevOps agente.
+ **Acionamento automatizado de investigações - Os** fluxos de trabalho do Dynatrace podem ser configurados para acionar investigações de resolução de incidentes a partir de problemas do Dynatrace.
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria do Dynatrace enquanto investiga um problema por meio do servidor Dynatrace MCP hospedado pelo agente. AWS DevOps
+ **Atualizações de status** - O AWS DevOps agente publicará as principais descobertas da investigação, análises da causa raiz e planos de mitigação gerados na interface de usuário do Dynatrace.
Para saber mais sobre as integrações bidirecionais, consulte
+ [Conectando o Dynatrace](connecting-telemetry-sources-connecting-dynatrace.md)
## Integração unidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte AWS CloudWatch a usuários de Datadog, Grafana, New Relic e Splunk com integrações unidirecionais integradas.
**Prática recomendada de segurança:** ao configurar credenciais para integrações unidirecionais integradas, recomendamos definir o escopo das chaves e tokens da API para acesso somente leitura. AWS DevOps O agente usa essas credenciais somente para introspecção de telemetria e não exige acesso de gravação ao seu provedor de telemetria.
A integração unidirecional AWS CloudWatch integrada não requer configuração adicional e permite o seguinte:
+ **Mapeamento de recursos de topologia** - O AWS DevOps agente aumentará sua topologia do espaço do DevOps agente com entidades e relacionamentos disponíveis por meio de suas contas de nuvem primária e secundária AWS configuradas.
+ **Introspecção de telemetria** - O AWS DevOps agente pode fazer uma introspecção da AWS CloudWatch telemetria ao investigar um problema por meio das funções do IAM fornecidas durante a configuração da conta de nuvem primária e secundária. AWS
As integrações unidirecionais integradas do Datadog, Grafana, New Relic e Splunk exigem configuração e permitem o seguinte:
+ **Acionamento automatizado de investigações - os** eventos Datadog, Grafana, New Relic e Splunk podem ser configurados para AWS DevOps acionar investigações de resolução de incidentes do agente por meio de webhooks do agente. AWS DevOps
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria Datadog, Grafana, New Relic e Splunk enquanto investiga um problema por meio do servidor MCP remoto de cada provedor.
Para saber mais sobre integrações unidirecionais, veja o seguinte:
+ [Conectando DataDog](connecting-telemetry-sources-connecting-datadog.md)
+ [Conectando Grafana](connecting-telemetry-sources-connecting-grafana.md)
+ [Conectando a New Relic](connecting-telemetry-sources-connecting-new-relic.md)
+ [Conectando o Splunk](connecting-telemetry-sources-connecting-splunk.md)
## Bring-your-own fontes de telemetria
Para qualquer outra fonte de telemetria, incluindo as métricas do Prometheus, você pode aproveitar o suporte do AWS DevOps Agent para integração de webhook e servidor MCP.
Para saber mais sobre bring-your-own integrações, consulte o seguinte
+ [Invocando o DevOps Agente por meio do Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
+ [Conectando servidores MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
# Conectando o Dynatrace
## Integração bidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte aos usuários do Dynatrace com uma integração bidirecional integrada que permite o seguinte:
+ **Mapeamento de recursos de topologia** - O AWS DevOps agente aumentará sua topologia do espaço do DevOps agente com entidades e relacionamentos disponíveis em seu ambiente Dynatrace.
+ **Acionamento automatizado de investigações - Os** fluxos de trabalho do Dynatrace podem ser configurados para acionar investigações de resolução de incidentes a partir de problemas do Dynatrace.
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria do Dynatrace enquanto investiga um problema por meio do servidor Dynatrace MCP hospedado pelo agente. AWS DevOps
+ **Atualizações de status** - O AWS DevOps agente publicará as principais descobertas da investigação, análises da causa raiz e planos de mitigação gerados na interface de usuário do Dynatrace.
## Onboarding
### Processo de integração
A integração do seu sistema de observabilidade Dynatrace envolve três etapas:
1. **Connect** - Estabeleça uma conexão com o Dynatrace configurando as credenciais de acesso à conta, com todos os ambientes que você possa precisar
1. **Habilitar** - Ative o Dynatrace em espaços específicos do Agente com ambientes específicos do Dynatrace
1. **Configure seu ambiente Dynatrace** - baixe os fluxos de trabalho e o painel e importe para o Dynatrace, anotando os detalhes do webhook para acionar investigações nos espaços designados do agente
### Etapa 1: Conectar
Estabeleça conexão com seu ambiente Dynatrace
#### Configuração
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre o **Dynatrace** na seção Provedores **disponíveis** em **Telemetria e clique em Registrar****
1. **Crie um OAuth cliente no Dynatrace, com as permissões detalhadas.**
1. Veja a documentação do [Dynatrace](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)
1. Quando estiver pronto, pressione Avançar
1. Você pode conectar vários ambientes do Dynatrace e, posteriormente, o escopo a ambientes específicos para cada espaço de DevOps agente que você possa ter.
1. Insira seus detalhes do Dynatrace na configuração do OAuth cliente:
+ **Nome do cliente**
+ **ID do cliente**
+ **Segredo do cliente**
+ **URN da conta**
1. Clique em Avançar.
1. Revise e adicione
### Etapa 2: ativar
Ative o Dynatrace em um espaço de agente específico e configure o escopo apropriado
#### Configuração
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes
1. Selecione a guia Capacidades
1. Localize a seção Telemetria, pressione Adicionar
1. Você notará que o Dynatrace está com o status “Registrado”. Clique em adicionar para adicioná-lo ao seu espaço de agente
1. ID do ambiente Dynatrace - forneça a ID do ambiente Dynatrace que você gostaria de associar a esse espaço do agente. DevOps
1. Insira uma ou mais entidades da Dynatrace IDs - elas ajudam o DevOps agente a descobrir seus recursos mais importantes; exemplos podem ser serviços ou aplicativos. **Se você não tiver certeza, pode pressionar remover.**
1. Revise e pressione Salvar
1. Copie o URL do Webhook e o Segredo do Webhook. Consulte a [documentação do Dynatrace](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent) para adicionar essas credenciais ao Dynatrace.
### Etapa 3: Configurar seu ambiente Dynatrace
Para concluir a configuração do Dynatrace, você precisará executar determinadas etapas de configuração em seu ambiente Dynatrace. Siga as instruções na documentação do [Dynatrace](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent).
#### Esquemas de eventos compatíveis
AWS DevOps O agente suporta dois tipos de eventos do Dynatrace usando webhooks. Os esquemas de eventos compatíveis estão documentados abaixo:
##### Evento de incidente
Eventos incidentes são usados para acionar uma investigação. O esquema do evento é:
```
{
"event.id": string;
"event.status": "ACTIVE" | "CLOSED";
"event.status_transition": string;
"event.description": string;
"event.name": string;
"event.category": "AVAILABILITY" | "ERROR" | "SLOWDOWN" | "RESOURCE_CONTENTION" | "CUSTOM_ALERT" | "MONITORING_UNAVAILABLE" | "INFO";
"event.start"?: string;
"affected_entity_ids"?: string[];
}
```
##### Evento de mitigação
Os eventos de mitigação são usados para acionar a geração de um relatório de mitigação para a investigação das próximas etapas. O esquema do evento é:
```
{
"task_id": string;
"task_version": number;
"event.type": "mitigation_request";
}
```
## Remoção
A fonte de telemetria está conectada em dois níveis no nível do espaço do agente e no nível da conta. Para removê-lo completamente, você deve primeiro removê-lo de todos os espaços do agente em que ele é usado e, em seguida, ele pode ser cancelado.
### Etapa 1: Remover do espaço do agente
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Selecione Dynatrace
1. Pressione remover
### Etapa 2: Cancelar o registro da conta
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Role até a seção **Registrado atualmente**.
1. Verifique se a contagem de espaço do agente é zero (se não, repita a Etapa 1 acima nos outros espaços do agente)
1. Pressione Cancelar registro ao lado de Dynatrace
# Conectando DataDog
## Integração unidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte aos usuários do Datadog com integração unidirecional integrada, permitindo o seguinte:
+ **Acionamento automatizado de investigação - os** eventos do Datadog podem ser configurados para acionar investigações de resolução de incidentes do AWS DevOps agente por meio de webhooks do agente. AWS DevOps
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria do Datadog enquanto investiga um problema por meio do servidor MCP remoto de cada provedor.
## Onboarding
### Etapa 1: Conectar
Estabeleça conexão com seu endpoint MCP remoto Datadog com credenciais de acesso à conta
#### Configuração
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre **Datadog** na seção Provedores **disponíveis** em **Telemetria e clique em Registrar****
1. Insira os detalhes do seu servidor Datadog MCP:
+ **Nome do servidor** - Identificador exclusivo (por exemplo, my-datadog-server)
+ **URL do endpoint** - Seu endpoint do servidor Datadog MCP. O URL do endpoint varia dependendo do seu site Datadog. Veja a tabela de endpoints do site Datadog abaixo.
+ **Descrição - Descrição** opcional do servidor
1. Clique em Avançar.
1. Analisar e enviar
#### Endpoints do site Datadog
O URL do endpoint MCP varia dependendo do seu site Datadog. Para identificar seu site, verifique a URL em seu navegador quando estiver conectado ao Datadog ou consulte [Acessar o site do](https://docs.datadoghq.com/getting_started/site/#access-the-datadog-site) Datadog.
| Site Datadog | Domínio do site | URL do endpoint MCP |
| --- | --- | --- |
| US1 (padrão) | datadoghq.com | https://mcp.datadoghq.com/api/unstable/mcp-server/mcp |
| US3 | us3.datadoghq.com | https://mcp.us3.datadoghq.com/api/unstable/mcp-server/mcp |
| US5 | us5.datadoghq.com | https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp |
| EU1 | datadoghq.eu | https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp |
| AP1 | ap1.datadoghq.com | https://mcp.ap1.datadoghq.com/api/unstable/mcp-server/mcp |
| AP2 | ap2.datadoghq.com | https://mcp.ap2.datadoghq.com/api/unstable/mcp-server/mcp |
#### Autorização
OAuth Autorização completa por:
+ Autorizando como seu usuário na página Datadog OAuth
+ Se não estiver conectado, clique em Permitir, faça login e autorize
Depois de configurado, o Datadog fica disponível em todos os espaços do agente.
### Etapa 2: ativar
Ative DataDog em um espaço de agente específico e configure o escopo apropriado
#### Configuração
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes (se você ainda não criou um espaço do agente, consulte[Criação de um espaço de agente](getting-started-with-aws-devops-agent-creating-an-agent-space.md))
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Pressione Adicionar
1. Selecione Datadog
1. Próximo
1. Revise e pressione Salvar
1. Copie o URL do webhook e a chave da API
### Etapa 3: configurar webhooks
Usando o URL do Webhook e a chave de API, você pode configurar o Datadog para enviar eventos para acionar uma investigação, por exemplo, a partir de um alarme.
Para garantir que os eventos enviados possam ser usados pelo DevOps Agente, certifique-se de que os dados transmitidos ao webhook correspondam ao esquema de dados especificado abaixo. Eventos que não correspondam a esse esquema podem ser ignorados pelo DevOps Agente.
Defina o método e os cabeçalhos
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envie o corpo como uma string JSON.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
Envie webhooks com Datadog [https://docs.datadoghq.com/integrations/webhooks/](https://docs.datadoghq.com/integrations/webhooks/) (observe que não selecione nenhuma autorização e, em vez disso, use a opção de cabeçalho personalizado).
Saiba mais: [Datadog Remote MCP Server](https://www.datadoghq.com/blog/datadog-remote-mcp-server/)
## Remoção
A fonte de telemetria é conectada em dois níveis no nível do espaço do agente e no nível da conta. Para removê-lo completamente, você deve primeiro removê-lo de todos os espaços do agente em que ele é usado e, em seguida, ele pode ser cancelado.
### Etapa 1: Remover do espaço do agente
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Selecione Datadog
1. Pressione remover
### Etapa 2: Cancelar o registro da conta
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Role até a seção **Registrado atualmente**.
1. Verifique se a contagem de espaço do agente é zero (se não, repita a Etapa 1 acima nos outros espaços do agente)
1. Pressione Cancelar registro ao lado do Datadog
# Conectando Grafana
A integração com o Grafana permite que o AWS DevOps Agente consulte métricas, painéis e dados de alerta da sua instância do Grafana durante investigações de incidentes. Essa integração segue um processo de duas etapas: registro em nível de conta do Grafana, seguido pela conexão com Agent Spaces individuais.
Para melhorar a segurança, a integração com o Grafana permite apenas ferramentas somente de leitura. As ferramentas de gravação estão desativadas e não podem ser habilitadas. Isso significa que o agente pode consultar e ler dados da sua instância do Grafana, mas não pode criar, modificar ou excluir nenhum recurso do Grafana, como painéis, alertas ou anotações. Para obter mais informações, consulte [Segurança no AWS DevOps Agente](https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html).
## Requisitos da Grafana
Antes de conectar o Grafana, certifique-se de ter:
+ Grafana versão 9.0 ou posterior. Alguns recursos, principalmente operações relacionadas à fonte de dados, podem não funcionar corretamente com versões anteriores devido à falta de endpoints da API.
+ Uma instância do Grafana acessível por HTTPS. Há suporte para endpoints de rede pública e privada. Com conectividade de rede privada, sua instância do Grafana pode ser hospedada em uma VPC sem acesso público à Internet. Para obter detalhes, consulte [Conectando-se a ferramentas hospedadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
+ Uma conta de serviço da Grafana com um token de acesso que tem permissões de leitura apropriadas
## Registrando a Grafana (nível da conta)
Grafana é registrada no nível da AWS conta e compartilhada entre todos os Agent Spaces dessa conta.
### Etapa 1: Configurar o Grafana
1. Faça login no console AWS de gerenciamento
1. Navegue até o console do AWS DevOps agente
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre **Grafana** na seção Provedores **disponíveis** em **Telemetria e clique em Registrar****
1. Na página **Configurar Grafana**, insira as seguintes informações:
+ **Nome do serviço** (obrigatório) — Insira um nome descritivo para seu servidor Grafana usando somente caracteres alfanuméricos, hífens e sublinhados. Por exemplo, .`my-grafana-server`
+ **URL do Grafana** (obrigatório) — Insira o URL HTTPS completo da sua instância do Grafana. Por exemplo, .`https://myinstance.grafana.net`
+ **Token de acesso à conta de serviço** (obrigatório) — Insira um token de acesso à conta de serviço da Grafana. Os tokens geralmente começam com`glsa_`. Para criar um token de conta de serviço, navegue até sua instância do Grafana, acesse **Administração > Contas de serviço**, crie uma conta de serviço com o papel de Visualizador e gere um token.
+ **Descrição** (opcional) — Adicione uma descrição para ajudar a identificar a finalidade do servidor. Por exemplo, .`Production Grafana server for monitoring`
1. (Opcional) Adicione AWS tags ao registro para fins organizacionais.
1. Clique em **Avançar**.
### Etapa 2: revisar e enviar o registro da Grafana
1. Revise todos os detalhes de configuração da Grafana
1. Clique em **Enviar** para concluir o registro
1. Após o registro bem-sucedido, Grafana aparece na seção **Atualmente registrado da página Provedores** de Capacidades
## Adicionando Grafana a um espaço de agente
Depois de registrar o Grafana no nível da conta, você pode conectá-lo a Agent Spaces individuais:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. **Na seção **Telemetria**, clique em Adicionar**
1. Selecione **Grafana** na lista de provedores disponíveis
1. Clique em **Salvar**
## Configurando webhooks de alerta da Grafana
Você pode configurar o Grafana para acionar automaticamente as investigações do AWS DevOps Agente quando os alertas são disparados, enviando webhooks pelos pontos de contato da Grafana. Para obter detalhes sobre métodos de autenticação de webhook e gerenciamento de credenciais, consulte. [Invocando o DevOps Agente por meio do Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
### Etapa 1: criar um modelo de notificação personalizado
Na sua instância do Grafana, navegue até **Alertas > Pontos de contato > Modelos de notificação** e crie um novo modelo com o seguinte conteúdo:
```
{{ define "devops-agent-payload" }}
{
"eventType": "incident",
"incidentId": "{{ (index .Alerts 0).Labels.alertname }}-{{ (index .Alerts 0).Fingerprint }}",
"action": "{{ if eq .Status "resolved" }}resolved{{ else }}created{{ end }}",
"priority": "{{ if eq .Status "resolved" }}MEDIUM{{ else }}HIGH{{ end }}",
"title": "{{ (index .Alerts 0).Labels.alertname }}",
"description": "{{ (index .Alerts 0).Annotations.summary }}",
"service": "{{ if (index .Alerts 0).Labels.job }}{{ (index .Alerts 0).Labels.job }}{{ else }}grafana{{ end }}",
"timestamp": "{{ (index .Alerts 0).StartsAt }}",
"data": {
"metadata": {
{{ range $k, $v := (index .Alerts 0).Labels }}
"{{ $k }}": "{{ $v }}",
{{ end }}
"_source": "grafana"
}
}
}
{{ end }}
```
Este modelo formata os alertas do Grafana na estrutura de carga útil do webhook esperada pelo Agente. AWS DevOps Ele mapeia rótulos de alerta, anotações e status nos campos apropriados e inclui todos os rótulos de alerta como metadados.
**Nota:** Esse modelo processa somente o primeiro alerta em um grupo. Grafana agrupa vários alertas de disparo em uma única notificação por padrão. Para garantir que cada alerta seja enviado individualmente, configure suas políticas de notificação para agrupar por`alertname`. Além disso, esse modelo não escapa de caracteres JSON especiais em valores de rótulos ou anotações. Certifique-se de que os rótulos de alerta e a `summary` anotação não contenham caracteres como aspas duplas ou novas linhas, o que produziria um JSON inválido.
### Etapa 2: criar um ponto de contato de webhook
1. **No Grafana, navegue até **Alertas > Pontos de contato** e clique em Adicionar ponto de contato**
1. Selecione **Webhook** como o tipo de integração
1. Defina a **URL** para seu endpoint de webhook do AWS DevOps agente
1. Em **Configurações opcionais de webhook**, configure os cabeçalhos de autenticação com base no seu tipo de webhook. Consulte [Métodos de autenticação do Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) para obter detalhes.
1. Defina o campo **Mensagem** para usar seu modelo personalizado: `{{ template "devops-agent-payload" . }}`
1. Clique em **Salvar ponto de contato**
### Etapa 3: atribuir o ponto de contato a uma política de notificação
1. Navegue até **Alertas > Políticas de notificação**
1. Edite uma política existente ou crie uma nova
1. Defina o ponto de contato como o ponto de contato do webhook que você criou
1. Clique em **Salvar política**
Quando um alerta correspondente é acionado, a Grafana enviará a carga formatada ao AWS DevOps Agente, que iniciará uma investigação automaticamente.
## Limitações
+ **ClickHouse ferramentas de fonte de ClickHouse dados — as** ferramentas de fonte de dados não são suportadas atualmente.
+ **Prevenção proativa de incidentes** — atualmente [Prevenção proativa de incidentes](working-with-devops-agent-proactive-incident-prevention.md) não usa as ferramentas da Grafana. Support está planejado para uma versão futura.
### Considerações sobre o Amazon Managed Grafana
Se você estiver usando o [Amazon Managed Grafana](https://aws.amazon.com/grafana/) (AMG), esteja ciente das seguintes limitações:
+ **Os pontos de contato do webhook não são suportados** — atualmente, o AMG não oferece suporte aos pontos de contato do webhook em sua configuração de alerta. Você não pode usar o AMG para enviar webhooks de alerta diretamente para o Agente. AWS DevOps Para obter detalhes, consulte [Alertar pontos de contato no Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/v9-alerting-explore-contacts.html).
+ **Expiração do token da conta** de serviço — Os tokens da conta de serviço AMG têm uma expiração máxima de 30 dias. Você precisará alternar os tokens e atualizar seu registro da Grafana AWS DevOps no Agent antes que eles expirem. Consulte [Gerenciando conexões do Grafana](#managing-grafana-connections) para saber como atualizar as credenciais. Para obter detalhes sobre os limites do token AMG, consulte [Contas de serviço na Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/service-accounts.html).
## Gerenciando conexões da Grafana
+ **Atualização de credenciais** — Se o token da sua conta de serviço expirar ou precisar ser atualizado, cancele o registro do Grafana na página Capability Providers e registre-se novamente com o novo token.
+ **Visualização de instâncias conectadas** — No console do AWS DevOps agente, selecione seu Espaço do agente e vá até a guia Capacidades para visualizar as fontes de telemetria conectadas.
+ **Removendo o Grafana** **— Para desconectar o Grafana de um Espaço do Agente, selecione-o na seção Telemetria e clique em Remover.** Para remover completamente o registro, primeiro remova-o de todos os Agent Spaces e, em seguida, cancele o registro da página Capability Providers.
# Conectando a New Relic
## Integração unidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte aos usuários da New Relic com integração unidirecional integrada, permitindo o seguinte:
+ **Acionamento automatizado de investigações - os** eventos do New Relic podem ser configurados para acionar investigações de resolução de incidentes do AWS DevOps agente por meio AWS DevOps de webhooks do agente.
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria da New Relic enquanto investiga um problema por meio do servidor MCP remoto de cada provedor.
## Onboarding
### Etapa 1: Conectar
Estabeleça conexão com seu endpoint MCP remoto da New Relic com credenciais de acesso à conta
Use um usuário de plataforma completa (não básico/básico) na New Relic para habilitar as ferramentas MCP da New Relic.
#### Configuração
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre a **New Relic** na seção Provedores **disponíveis** em **Telemetria e clique** em Registrar**
1. Siga as instruções para obter sua chave de API New Relic
1. Insira os detalhes da chave de API do servidor New Relic MCP:
+ **ID da conta:** insira o ID da sua conta New Relic obtido acima
+ **Chave de API:** insira a chave de API obtida acima
+ **Selecione a região dos EUA ou da UE** com base na localização da sua conta New Relic.
1. Clique em Adicionar
### Etapa 2: ativar
Ative o New Relic em um espaço de agente específico e configure o escopo apropriado
#### Configuração
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes (se você ainda não criou um espaço do agente, consulte[Criação de um espaço de agente](getting-started-with-aws-devops-agent-creating-an-agent-space.md))
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Pressione Adicionar
1. Selecione New Relic
1. Próximo
1. Revise e pressione Salvar
1. Copie o URL do webhook e a chave da API
### Etapa 3: configurar webhooks
Usando o URL do Webhook e a chave de API, você pode configurar o New Relic para enviar eventos para acionar uma investigação, por exemplo, a partir de um alarme. Para obter mais detalhes sobre como configurar webhooks, consulte Webhooks de [rastreamento de alterações](https://docs.newrelic.com/docs/change-tracking/change-tracking-webhooks/).
Para garantir que os eventos enviados possam ser usados pelo DevOps Agente, certifique-se de que os dados transmitidos ao webhook correspondam ao esquema de dados especificado abaixo. Eventos que não correspondam a esse esquema podem ser ignorados pelo DevOps Agente.
Defina o método e os cabeçalhos
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envie o corpo como uma string JSON.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
[Envie webhooks com as notificações de webhook da New Relichttps://newrelic.com/instant-observability/.](https://newrelic.com/instant-observability/webhook-notifications) Você pode selecionar o token do portador para o tipo de autorização ou selecionar sem autorização e adicioná-lo `Authorization: Bearer ` como um cabeçalho personalizado.
Saiba mais: [https://docs.newrelic.com/docs/agentic-/ai/mcp/overview](https://docs.newrelic.com/docs/agentic-ai/mcp/overview/)
## Remoção
A fonte de telemetria está conectada em dois níveis no nível do espaço do agente e no nível da conta. Para removê-lo completamente, você deve primeiro removê-lo de todos os espaços do agente em que ele é usado e, em seguida, ele pode ser cancelado.
### Etapa 1: Remover do espaço do agente
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Selecione New Relic
1. Pressione remover
### Etapa 2: Cancelar o registro da conta
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Role até a seção **Registrado atualmente**.
1. Verifique se a contagem de espaço do agente é zero (se não, repita a Etapa 1 acima nos outros espaços do agente)
1. Pressione Cancelar registro ao lado da New Relic
# Conectando o Splunk
## Integração unidirecional integrada
Atualmente, o AWS DevOps Agent oferece suporte aos usuários do Splunk com integração unidirecional integrada, permitindo o seguinte:
+ **Acionamento automatizado de investigações - os** eventos do Splunk podem ser configurados para acionar investigações de resolução de incidentes do AWS DevOps agente por meio AWS DevOps de webhooks do agente.
+ Introspecção de **telemetria - O AWS DevOps agente pode fazer uma introspecção da** telemetria do Splunk enquanto investiga um problema por meio do servidor MCP remoto de cada provedor.
## Pré-requisitos
### Obtendo um token da API Splunk
Você precisará de um URL e token do MCP para conectar o Splunk.
### Etapas do administrador do Splunk
Seu administrador do Splunk precisa executar as seguintes etapas:
+ habilitar o [acesso à API REST](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ [habilite a autenticação de token](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.2.2406/authenticate-into-the-splunk-platform-with-tokens/enable-or-disable-token-authentication) na implantação.
+ crie uma nova função 'mcp\$1user', a nova função não precisa ter nenhum recurso.
+ atribua a função 'mcp\$1user' a qualquer usuário na implantação que esteja autorizado a usar o servidor MCP.
+ crie o token para os usuários autorizados com o público como 'mcp' e defina a expiração apropriada, caso o usuário não tenha permissão para criar tokens por conta própria.
### Etapas do usuário do Splunk
Um usuário do Splunk precisa realizar as seguintes etapas:
+ Obtenha um token apropriado do administrador do Splunk ou crie um por conta própria, se ele tiver permissão. O público do token deve ser 'mcp'.
## Onboarding
### Etapa 1: Conectar
Estabeleça uma conexão com seu endpoint MCP remoto da Splunk com credenciais de acesso à conta
#### Configuração
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. **Encontre o **Splunk** na seção Provedores **disponíveis** em **Telemetria e clique** em Registrar**
1. Insira os detalhes do seu servidor Splunk MCP:
+ **Nome do servidor** - Identificador exclusivo (por exemplo, my-splunk-server)
+ **URL do endpoint** - Seu endpoint do servidor Splunk MCP:
`https://.api.scs.splunk.com//mcp/v1/`
+ **Descrição - Descrição** opcional do servidor
+ **Nome do token** - O nome do token portador para autenticação: `my-splunk-token`
+ Valor do **token O valor** do token do portador para autenticação
### Etapa 2: Ativar
Ative o Splunk em um espaço de agente específico e configure o escopo apropriado
#### Configuração
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes (se você ainda não criou um espaço do agente, consulte[Criação de um espaço de agente](getting-started-with-aws-devops-agent-creating-an-agent-space.md))
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Pressione Adicionar
1. Selecione Splunk
1. Próximo
1. Revise e pressione Salvar
1. Copie o URL do webhook e a chave de API
### Etapa 3: configurar webhooks
Usando o URL do Webhook e a chave de API, você pode configurar o Splunk para enviar eventos para acionar uma investigação, por exemplo, a partir de um alarme.
Para garantir que os eventos enviados possam ser usados pelo DevOps Agente, certifique-se de que os dados transmitidos ao webhook correspondam ao esquema de dados especificado abaixo. Eventos que não correspondam a esse esquema podem ser ignorados pelo DevOps Agente.
Defina o método e os cabeçalhos
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envie o corpo como uma string JSON.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
Envie webhooks com o Splunk [https://help.splunk.com/en/splunk- enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use - a-webhook-alert-action](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use-a-webhook-alert-action) (observe que não selecione nenhuma autorização e, em vez disso, use a opção de cabeçalho personalizado)
### Saiba mais:
+ Documentação do servidor MCP da Splunk: [https://help.splunk.com/en/splunk-cloud-platform/-platform/ mcp-server-for-splunk](https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform) -splunk-platform about-mcp-server-for
+ Requisitos e limitações de acesso para a API REST do Splunk Cloud Platform: [https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ Gerencie tokens de autenticação na Splunk Cloud Platform: [https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage-or-delete-authentication-tokens)- or-delete-authentication-tokens
+ Crie e gerencie funções com o Splunk Web: [https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles](https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles)
## Remoção
A fonte de telemetria é conectada em dois níveis no nível do espaço do agente e no nível da conta. Para removê-lo completamente, você deve primeiro removê-lo de todos os espaços do agente em que ele é usado e, em seguida, ele pode ser cancelado.
### Etapa 1: Remover do espaço do agente
1. Na página de espaços do agente, selecione um espaço do agente e pressione visualizar detalhes
1. Selecione a guia Capacidades
1. Role para baixo até a seção Telemetria
1. Selecione Splunk
1. Pressione remover
### Etapa 2: Cancelar o registro da conta
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Role até a seção **Registrado atualmente**.
1. Verifique se a contagem de espaço do agente é zero (se não, repita a Etapa 1 acima em seus outros espaços do agente)
1. Pressione Cancelar registro ao lado de Splunk
# Conectando-se à emissão de bilhetes e ao bate-papo
AWS DevOps O agente foi projetado para atuar como membro da sua equipe, participando dos canais de comunicação existentes da sua equipe. Você pode conectar o DevOps Agent aos seus sistemas de emissão de tíquetes e alarmes, como ServiceNow e PagerDuty, para iniciar automaticamente investigações a partir de tíquetes de incidentes, acelerando a resposta a incidentes em seus fluxos de trabalho existentes para reduzir o tempo médio de recuperação (MTTR). Você também pode conectar seu DevOps agente aos sistemas de colaboração de sua equipe, como o Slack, para receber resumos de atividades do seu DevOps agente em um canal de bate-papo.
Para saber mais sobre como conectar integrações de tickets e chat, veja o seguinte:
+ [Conectando PagerDuty](connecting-to-ticketing-and-chat-connecting-pagerduty.md)
+ [Conectando ServiceNow](connecting-to-ticketing-and-chat-connecting-servicenow.md)
+ [Conectando o Slack](connecting-to-ticketing-and-chat-connecting-slack.md)
# Conectando PagerDuty
PagerDuty a integração permite que o AWS DevOps agente acesse e atualize dados de incidentes, agendas de plantão e informações de serviço de sua PagerDuty conta durante investigações de incidentes e respostas automatizadas. Essa integração usa OAuth 2.0 para autenticação segura.
**Importante**
** AWS DevOps O agente suporta somente a PagerDuty OAuth versão 2.0 mais recente (com escopo OAuth). O legado PagerDuty OAuth com uri de redirecionamento não é suportado.
## PagerDuty requisitos
Antes de se conectar PagerDuty, verifique se você tem:
+ Uma PagerDuty conta com seu ID de OAuth cliente e segredo de cliente
+ O subdomínio PagerDuty da sua conta (por exemplo, se sua PagerDuty URL for`https://your-company.pagerduty.com`, o subdomínio é) `your-company`
## Registrando PagerDuty
PagerDuty é registrado no nível da AWS conta e compartilhado entre todos os Agent Spaces dessa conta.
### Etapa 1: configurar o acesso no PagerDuty
1. Faça login no console AWS de gerenciamento
1. Navegue até o console do AWS DevOps agente
1. Vá para a página **Capability Providers** (acessível na navegação lateral)
1. Encontre **PagerDuty**na seção Provedores **disponíveis** em **Comunicação** e clique em **Registrar**
1. Siga a configuração guiada na PagerDuty página **Configurar acesso em**:
**Verifique sua região de serviço e subdomínio:**
+ **Escopo da conta** — Selecione sua PagerDuty região (**EUA** ou **UE**) e insira seu PagerDuty subdomínio. Por exemplo, se sua PagerDuty URL for`https://your-company.pagerduty.com`, insira`your-company`.
**Crie um novo aplicativo em PagerDuty:**
+ Em uma guia separada do navegador, faça login PagerDuty e navegue até **Integrações > Registro de aplicativos**
+ Crie um novo aplicativo usando **OAuth 2.0 Scoped OAuth**
+ Em **Permissões**, conceda os seguintes escopos mínimos obrigatórios:`incidents.read`,`incidents.write`, e `services.read`
+ Ative a **integração de eventos** para permitir a comunicação bidirecional entre o agente e AWS DevOps PagerDuty
**Configure OAuth as credenciais:**
+ **Escopo da permissão** — Os escopos mínimos necessários são:`incidents.read`,, `incidents.write` `services.read`
+ **Nome do cliente** — Insira um nome descritivo para seu OAuth cliente
+ **ID do cliente** — insira o ID do OAuth cliente do registro do seu PagerDuty aplicativo
+ **Segredo do cliente** — Insira o segredo do OAuth cliente do registro do seu PagerDuty aplicativo
### Etapa 2: revisar e enviar o PagerDuty registro
1. Revise todos os detalhes da PagerDuty configuração
1. Clique em **Enviar** para concluir o registro
1. Após o registro bem-sucedido, PagerDuty aparece na seção **Registrado atualmente** da página Provedores de capacidades
## Adicionando PagerDuty a um espaço de agente
Depois de se registrar PagerDuty no nível da conta, você pode conectá-la aos Agent Spaces individuais:
1. No console do AWS DevOps agente, selecione seu Espaço do agente
1. Vá para a guia **Capacidades**
1. Na seção **Comunicações**, clique em **Adicionar**
1. **PagerDuty**Selecione na lista de provedores disponíveis
1. Clique em **Salvar**
## Gerenciando PagerDuty conexões
+ **Atualização de credenciais** — Se suas OAuth credenciais precisarem ser atualizadas, cancele o registro PagerDuty na página Capability Providers e registre-se novamente com as novas credenciais.
+ **Visualizando conexões** — No console do AWS DevOps agente, selecione seu Espaço do agente e vá até a guia Capacidades para visualizar as integrações de comunicação conectadas.
+ **Removendo PagerDuty** — Para se desconectar PagerDuty de um Espaço do Agente, selecione-o na seção Comunicações e clique em **Remover**. Para remover completamente o registro, primeiro remova-o de todos os Agent Spaces e, em seguida, cancele o registro da página Capability Providers.
## Suporte para webhook
AWS DevOps O agente só oferece suporte a PagerDuty webhooks V3. As versões anteriores do webhook não são suportadas.
Para obter mais informações sobre assinaturas de webhook PagerDuty V3, consulte Visão geral de [webhooks](https://developer.pagerduty.com/docs/webhooks-overview#webhook-subscriptions) na documentação do desenvolvedor. PagerDuty
# Conectando ServiceNow
Este tutorial explica como conectar uma ServiceNow instância ao AWS DevOps Agent para permitir que ela inicie automaticamente investigações de resposta a incidentes quando um ticket é criado e publique suas principais descobertas no ticket de origem. Ele também contém exemplos de como configurar sua ServiceNow instância para enviar somente tickets específicos para um DevOps Agent Space e como orquestrar o roteamento de tickets em vários DevOps Agent Spaces.
## Configuração inicial
A primeira etapa é criar ServiceNow um cliente de OAuth aplicativo que AWS DevOps possa ser usado para acessar sua ServiceNow instância.
### Crie um cliente ServiceNow OAuth de aplicativo
1. Ative a propriedade do sistema de credenciais do cliente da sua instância
1. Pesquise `sys_properties.list` na caixa de pesquisa do filtro e pressione enter (não mostrará a opção, mas pressionar enter funciona)
1. Escolha Novo
1. Adicione o nome como `glide.oauth.inbound.client.credential.grant_type.enabled` e o valor como verdadeiro com o tipo verdadeiro \$1 falso
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/09ed6d5ff911.png)
1. Navegue até Sistema OAuth > Registro de aplicativos na caixa de pesquisa do filtro
1. Escolha “Novo” > “Nova experiência de integração de entrada” > “Nova integração” > “OAuth - Concessão de credenciais do cliente”
1. Escolha um nome e defina o usuário do OAuth aplicativo como “Administrador do problema”, clique em “Salvar”
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/aeff4c127f7c.png)
### Conecte seu ServiceNow OAuth cliente ao AWS DevOps agente
1. Você pode iniciar esse processo em dois lugares. Primeiro, navegando até a página **Provedores de Capacidades**, encontrando **ServiceNow**em **Comunicação** e, em seguida, clicando em **Registrar**. Como alternativa, você pode selecionar qualquer Espaço do DevOps Agente que você possa ter criado e navegar até Capacidades → Comunicações → Adicionar → ServiceNow e clicar em Registrar.
1. Em seguida, autorize o DevOps Agente a acessar sua ServiceNow instância usando o cliente do OAuth aplicativo que você acabou de criar.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/3db5a9aafc5f.png)
+ Siga as próximas etapas e salve as informações resultantes sobre o webhook
**Importante**
Você não verá essas informações novamente
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/80d0a319f87e.png)
### Configure sua regra ServiceNow de negócios
Depois de estabelecer a conectividade, você precisará configurar uma regra de negócios para enviar tickets ServiceNow para o (s) seu (s) espaço (s) de DevOps agente.
1. Navegue até Assinaturas de atividades → Administração → Regras de negócios e clique em Novo.
1. Defina o campo “Tabela” como “Incidente [incidente]”, marque a caixa “Avançado” e defina a regra a ser executada após Inserir, Atualizar e Excluir.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/6f2a7370e2c0.png)
1. Navegue até a guia “Avançado” e adicione o seguinte script de webhook, inserindo o segredo e o URL do webhook onde indicado, e clique em Enviar.
```
(function executeRule(current, previous /*null when async*/ ) {
var WEBHOOK_CONFIG = {
webhookSecret: GlideStringUtil.base64Encode('<<< INSERT WEBHOOK SECRET HERE >>>'),
webhookUrl: '<<< INSERT WEBHOOK URL HERE >>>'
};
function generateHMACSignature(payloadString, secret) {
try {
var mac = new GlideCertificateEncryption();
var signature = mac.generateMac(secret, "HmacSHA256", payloadString);
return signature;
} catch (e) {
gs.error('HMAC generation failed: ' + e);
return null;
}
}
function callWebhook(payload, config) {
try {
var timestamp = new Date().toISOString();
var payloadString = JSON.stringify(payload);
var payloadWithTimestamp =`${timestamp}:${payloadString}`;
var signature = generateHMACSignature(payloadWithTimestamp, config.webhookSecret);
if (!signature) {
gs.error('Failed to generate signature');
return false;
}
gs.info('Generated signature: ' + signature);
var request = new sn_ws.RESTMessageV2();
request.setEndpoint(config.webhookUrl);
request.setHttpMethod('POST');
request.setRequestHeader('Content-Type', 'application/json');
request.setRequestHeader('x-amzn-event-signature', signature);
request.setRequestHeader('x-amzn-event-timestamp', timestamp);
request.setRequestBody(payloadString);
var response = request.execute();
var httpStatus = response.getStatusCode();
var responseBody = response.getBody();
if (httpStatus >= 200 && httpStatus < 300) {
gs.info('Webhook sent successfully. Status: ' + httpStatus);
return true;
} else {
gs.error('Webhook failed. Status: ' + httpStatus + ', Response: ' + responseBody);
return false;
}
} catch (ex) {
gs.error('Error sending webhook: ' + ex.getMessage());
return false;
}
}
function createReference(field) {
if (!field || field.nil()) {
return null;
}
return {
link: field.getLink(true),
value: field.toString()
};
}
function getStringValue(field) {
if (!field || field.nil()) {
return null;
}
return field.toString();
}
function getIntValue(field) {
if (!field || field.nil()) {
return null;
}
var val = parseInt(field.toString());
return isNaN(val) ? null : val;
}
var eventType = (current.operation() == 'insert') ? "create" : "update";
var incidentEvent = {
eventType: eventType.toString(),
sysId: current.sys_id.toString(),
priority: getStringValue(current.priority),
impact: getStringValue(current.impact),
active: getStringValue(current.active),
urgency: getStringValue(current.urgency),
description: getStringValue(current.description),
shortDescription: getStringValue(current.short_description),
parent: getStringValue(current.parent),
incidentState: getStringValue(current.incident_state),
severity: getStringValue(current.severity),
problem: createReference(current.problem),
additionalContext: {}
};
incidentEvent.additionalContext = {
number: current.number.toString(),
opened_at: getStringValue(current.opened_at),
opened_by: current.opened_by.nil() ? null : current.opened_by.getDisplayValue(),
assigned_to: current.assigned_to.nil() ? null : current.assigned_to.getDisplayValue(),
category: getStringValue(current.category),
subcategory: getStringValue(current.subcategory),
knowledge: getStringValue(current.knowledge),
made_sla: getStringValue(current.made_sla),
major_incident: getStringValue(current.major_incident)
};
for (var key in incidentEvent.additionalContext) {
if (incidentEvent.additionalContext[key] === null) {
delete incidentEvent.additionalContext[key];
}
}
gs.info(JSON.stringify(incidentEvent, null, 2)); // Pretty print for logging only
if (WEBHOOK_CONFIG.webhookUrl && WEBHOOK_CONFIG.webhookSecret) {
callWebhook(incidentEvent, WEBHOOK_CONFIG);
} else {
gs.info('Webhook not configured.');
}
})(current, previous);
```
Se você optou por registrar sua ServiceNow conexão na página **Capability Providers**, agora você precisa navegar até o DevOps Agent Space no qual deseja investigar os tickets de ServiceNow incidentes, selecionar Capabilities → Communications e, em seguida, registrar a ServiceNow instância registrada na página Capability Providers. Agora, tudo deve estar configurado e todos os incidentes em que o chamador está configurado como “Administrador do problema” (para imitar as permissões que você concedeu ao AWS DevOps OAuth cliente) acionarão uma investigação de resposta a incidentes no Espaço do Agente configurado DevOps . Você pode testar isso criando um novo incidente ServiceNow e definindo o campo Chamador do incidente como “Administrador do problema”.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/4c7d24a85f88.png)
### ServiceNow atualizações de ingressos
Durante todas as investigações de resposta a incidentes acionados, seu DevOps agente fornecerá atualizações de suas principais descobertas, análises da causa raiz e planos de mitigação no ticket de origem. As descobertas do agente são publicadas nos comentários de um incidente e, atualmente, publicaremos apenas registros do agente do tipo`finding`,, `cause` `investigation_summary``mitigation_summary`, e atualizações do status da investigação (por exemplo`AWS DevOps Agent started/finished its investigation`).
## Exemplos de roteamento e orquestração de tickets
### Cenário: filtrando quais incidentes são enviados para um DevOps Espaço do Agente
Esse é um cenário simples, mas precisa de alguma configuração ServiceNow para criar um campo ServiceNow para rastrear a origem do incidente. Para fins deste exemplo, crie um novo campo Fonte (u\$1source) usando o construtor de formulários SNOW. Isso permitirá rastrear a origem do incidente e usá-la para rotear solicitações de uma fonte específica para um Espaço do DevOps Agente. O roteamento é realizado criando uma regra de negócios do Service Now e, na guia Quando executar, definindo os gatilhos “Quando” e “Condições do filtro”. Neste exemplo, as condições do filtro são definidas da seguinte forma:
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/fac7a186beee.png)
### Cenário: roteamento de incidentes em vários DevOps espaços de agentes
Este exemplo mostra como acionar uma Investigação no Espaço do DevOps Agente B quando a urgência é`1`, a categoria é `Software` ou o Serviço é`AWS`, e acionar uma Investigação no Espaço do DevOps Agente A quando o serviço é `AWS` e a origem é`Dynatrace`.
Esse cenário pode ser realizado de duas maneiras. O script do webhook em si pode ser atualizado para incluir essa lógica de negócios. Nesse cenário, mostraremos como fazer isso com uma regra de ServiceNow negócios, para transparência e simplificação da depuração. O roteamento é realizado com a criação de duas regras de negócios do Service Now.
+ Crie uma regra de negócios ServiceNow para o DevOps Agent Space A e crie uma condição usando o construtor de condições para enviar somente os eventos com base em nossa condição especificada.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/bca2f3928bf0.png)
+ Em seguida, crie outra regra de negócios ServiceNow para AgentSpace B, para a qual a regra de negócios só será acionada quando o serviço for AWS e a origem for o Dynatrace.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/bc29e4db1a76.png)
Agora, quando você cria um novo incidente que corresponda à condição especificada, ele aciona uma investigação no Espaço do DevOps Agente A ou no Espaço do DevOps Agente B, fornecendo a você um controle refinado sobre o roteamento de incidentes.
# Conectando o Slack
Você pode configurar o AWS DevOps Agente para atualizar um canal do Slack selecionado com as principais descobertas da investigação de resposta a incidentes, análises da causa raiz e planos de mitigação gerados.
## Antes de começar
O Slack precisa ser registrado no DevOps Agent antes de poder ser adicionado ao Agent Space. Para integrar o AWS DevOps Agent ao Slack, você deve atender aos seguintes requisitos:
+ Tenha acesso a um espaço de trabalho do Slack com a capacidade de instalar e autorizar aplicativos de terceiros
+ Identificou os canais do Slack para os quais você deseja que o AWS DevOps agente envie notificações
## Registre a integração do Slack com AWS DevOps o Agent
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/4034f56fad96.png)
1. Na página **Provedores de capacidades** no console do AWS DevOps agente, encontre o **Slack** na seção Provedores **disponíveis** em **Comunicação** e clique em **Registrar**.
1. Escolha o botão **Registrar**.
1. Você será redirecionado para o Slack para autorizar a inscrição do AWS DevOps Agente no seu espaço de trabalho.
1. Na página de autorização do Slack, instale diretamente nos espaços de trabalho, não no nível da organização.
1. Escolha um espaço de trabalho no menu suspenso. Não selecione um Enterprise Grid.
1. Instale por espaço de trabalho conforme necessário para sua organização.
1. Revise os escopos solicitados e clique em **Permitir** para autorizar a integração.
1. Após a autorização, você retornará ao console do AWS DevOps agente.
## Associe o Slack ao (s) seu (s) espaço (s) de DevOps agente
Depois de registrar o Slack no seu Espaço do DevOps agente, você pode associá-lo ao (s) seu (s) Espaço (s) do DevOps agente:
1. Na guia **Capacidades** em sua configuração AgentSpace, navegue até **Comunicações** > **Slack**.
1. Selecione **Adicionar Slack**
1. Insira o ID do canal
1. Escolha **Criar** para concluir a configuração do Slack.
**nota**
**O usuário bot do agente deve ser adicionado aos canais privados antes de poder publicar mensagens.
**Importante**
**A desinstalação do aplicativo Slack pode fazer com que o aplicativo Slack não possa ser reinstalado. Evite desinstalar o aplicativo Slack.
# Invocando o DevOps Agente por meio do Webhook
Os webhooks permitem que sistemas externos acionem automaticamente as investigações do AWS DevOps agente. Isso permite a integração com sistemas de emissão de bilhetes, ferramentas de monitoramento e outras plataformas que podem enviar solicitações HTTP quando ocorrem incidentes.
## Pré-requisitos
Antes de configurar o acesso ao webhook, verifique se você tem:
+ Um Espaço do Agente configurado no AWS DevOps Agente
+ Acesso ao console do AWS DevOps agente
+ O sistema externo que enviará solicitações de webhook
## Tipos de webhook
AWS DevOps O Agent oferece suporte aos seguintes tipos de webhooks:
+ **Webhooks específicos de integração** — gerados automaticamente quando você configura integrações de terceiros, como Dynatrace, Splunk, Datadog, New Relic ou Slack. ServiceNow Esses webhooks estão associados à integração específica e usam métodos de autenticação determinados pelo tipo de integração.
+ **Webhooks genéricos** — Podem ser criados manualmente para acionar investigações de qualquer fonte não coberta por uma integração específica. Atualmente, os webhooks genéricos usam autenticação **HMAC** (o token do portador não está disponível no momento).
+ **Webhooks de alerta do Grafana** — O Grafana pode enviar notificações de alerta diretamente AWS DevOps ao Agente por meio de pontos de contato do webhook. Para obter instruções de configuração, incluindo um modelo de notificação personalizado, consulte [Conectando o Grafana](connecting-telemetry-sources-connecting-grafana.md).
## Métodos de autenticação de webhook
O método de autenticação do seu webhook depende da integração à qual ele está associado:
**Autenticação HMAC** — Usada por:
+ Webhooks de integração com o Dynatrace
+ Webhooks genéricos (não vinculados a uma integração específica de terceiros)
**Autenticação de token do portador** — usada por:
+ Webhooks de integração com o Splunk
+ Webhooks de integração com Datadog
+ Webhooks de integração com a New Relic
+ ServiceNow webhooks de integração
+ Webhooks de integração com o Slack
## Configurando o acesso ao webhook
### Etapa 1: Navegue até a configuração do webhook
1. Faça login no console AWS de gerenciamento e navegue até o console do AWS DevOps agente
1. Selecione seu espaço de agente
1. Vá para a guia **Capacidades**
1. **Na seção **Webhook**, clique em Configurar**
### Etapa 2: gerar credenciais de webhook
**Para webhooks específicos de integração:**
Os webhooks são gerados automaticamente quando você conclui a configuração de uma integração de terceiros. O URL e as credenciais do endpoint do webhook são fornecidos no final do processo de configuração da integração.
**Para webhooks genéricos:**
1. Clique em **Gerar webhook**
1. O sistema gerará um par de chaves HMAC
1. Armazene com segurança a chave e o segredo gerados — você não poderá recuperá-los novamente
1. Copie o URL do endpoint do webhook fornecido
### Etapa 3: configurar seu sistema externo
Use o URL e as credenciais do endpoint do webhook para configurar seu sistema externo para enviar solicitações ao Agente. AWS DevOps As etapas específicas de configuração dependem do seu sistema externo.
## Gerenciando credenciais de webhook
**Removendo credenciais** **— Para excluir as credenciais do webhook, acesse a seção de configuração do webhook e clique em Remover.** Depois de remover as credenciais, o endpoint do webhook não aceitará mais solicitações até que você gere novas credenciais.
**Regeneração de credenciais** — Para gerar novas credenciais, primeiro remova as existentes e, em seguida, gere um novo token ou par de chaves.
## Usando o webhook
### Formato de solicitação de webhook
Para acionar uma investigação, seu sistema externo deve enviar uma solicitação HTTP POST para a URL do endpoint do webhook.
**Para a versão 1 (autenticação HMAC):**
Cabeçalhos:
+ `Content-Type: application/json`
+ `x-amzn-event-signature: `
+ `x-amzn-event-timestamp: <+%Y-%m-%dT%H:%M:%S.000Z>`
A assinatura HMAC é gerada assinando o corpo da solicitação com sua chave secreta usando SHA-256.
**Para a versão 2 (autenticação de token do portador):**
Cabeçalhos:
+ `Content-Type: application/json`
+ `Authorization: Bearer `
**Corpo da solicitação:**
O corpo da solicitação deve incluir informações sobre o incidente:
```
json
{
"title": "Incident title",
"severity": "high",
"affectedResources": ["resource-id-1", "resource-id-2"],
"timestamp": "2025-11-23T18:00:00Z",
"description": "Detailed incident description",
"data": {
"metadata": {
"region": "us-east-1",
"environment": "production"
}
}
}
```
### Código de exemplo
**Versão 1 (autenticação HMAC) -: JavaScript**
```
const crypto = require('crypto');
// Webhook configuration
const webhookUrl = 'https://your-webhook-endpoint.amazonaws.com/invoke';
const webhookSecret = 'your-webhook-secret-key';
// Incident data
const incidentData = {
eventType: 'incident',
incidentId: 'incident-123',
action: 'created',
priority: "HIGH",
title: 'High CPU usage on production server',
description: 'High CPU usage on production server host ABC in AWS account 1234 region us-east-1',
timestamp: new Date().toISOString(),
service: 'MyTestService',
data: {
metadata: {
region: 'us-east-1',
environment: 'production'
}
}
};
// Convert data to JSON string
const payload = JSON.stringify(incidentData);
const timestamp = new Date().toISOString();
const hmac = crypto.createHmac("sha256", webhookSecret);
hmac.update(`${timestamp}:${payload}`, "utf8");
const signature = hmac.digest("base64");
// Send the request
fetch(webhookUrl, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'x-amzn-event-timestamp': timestamp,
'x-amzn-event-signature': signature
},
body: payload
})
.then(res => {
console.log(`Status Code: ${res.status}`);
return res.text();
})
.then(data => {
console.log('Response:', data);
})
.catch(error => {
console.error('Error:', error);
});
```
**Versão 1 (autenticação HMAC) - cURL:**
```
#!/bin/bash
# Configuration
WEBHOOK_URL="https://event-ai.us-east-1.api.aws/webhook/generic/YOUR_WEBHOOK_ID"
SECRET="YOUR_WEBHOOK_SECRET"
# Create payload
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%S.000Z)
INCIDENT_ID="test-alert-$(date +%s)"
PAYLOAD=$(cat <
### Se você não receber um 200
Um 200 e uma mensagem como webhook recebida indicam que a autenticação foi aprovada e a mensagem foi colocada na fila para o sistema verificar e processar. Se você não obtiver um 200, mas um 4xx, provavelmente há algo errado com a autenticação ou os cabeçalhos. Tente enviar manualmente usando as opções de curl para ajudar a depurar a autenticação.
### Se você receber um 200, mas a investigação não começar
A causa provável é uma carga com formato incorreto.
1. Verifique se o carimbo de data/hora e o ID do incidente estão atualizados e exclusivos. As mensagens duplicadas são desduplicadas.
1. Verifique se a mensagem é um JSON válido
1. Verifique se o formato está correto
### Se você receber uma nota de 200 e a investigação for imediatamente cancelada
Provavelmente você atingiu o limite do mês. Fale com seu AWS contato para solicitar uma alteração do limite de tarifa, se apropriado.
## Tópicos relacionados
+ [Criação de um espaço de agente](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
+ [O que é um DevOps Agent Web App?](about-aws-devops-agent-what-is-a-devops-agent-web-app.md)
+ [DevOps Permissões do Agent IAM](aws-devops-agent-security-devops-agent-iam-permissions.md)
# AWS DevOps Agente de integração com a Amazon EventBridge
Você pode integrar o AWS DevOps Agent aos seus aplicativos orientados por eventos usando eventos que ocorrem durante os ciclos de vida de investigação e mitigação. AWS DevOps O agente envia eventos para a Amazon EventBridge quando o estado de uma investigação ou mitigação muda. Em seguida, você pode criar EventBridge regras que atuem com base nesses eventos.
Por exemplo, você pode criar regras que executem as seguintes ações:
+ Invoque uma função AWS Lambda para processar os resultados da investigação quando uma investigação for concluída.
+ Envie uma notificação do Amazon SNS quando uma investigação falhar ou atingir o tempo limite.
+ Atualize um sistema de emissão de tíquetes quando uma nova investigação for criada.
+ Inicie um fluxo de trabalho do AWS Step Functions quando uma ação de mitigação for concluída.
## Como EventBridge direciona os eventos AWS DevOps do Agent
AWS DevOps O agente envia eventos para o barramento de eventos EventBridge padrão. EventBridge em seguida, avalia os eventos em relação às regras que você cria. Quando um evento corresponde ao padrão de eventos de uma regra, EventBridge envia o evento para os destinos especificados.
O diagrama a seguir mostra como EventBridge roteia os eventos AWS DevOps do Agente.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/eventbridge-integration-how-it-works.png)
1. AWS DevOps O agente envia um evento para o barramento de eventos EventBridge padrão quando o estado do ciclo de vida de uma investigação ou mitigação muda.
1. EventBridge avalia o evento em relação às regras que você criou.
1. Se o evento corresponder ao padrão de evento de uma regra, EventBridge envia o evento para os destinos especificados na regra.
## AWS DevOps Eventos do agente
AWS DevOps O agente envia os seguintes eventos para EventBridge. Todos os eventos usam a fonte`aws.aidevops`.
### Eventos de investigação apoiados
| detail-type | Description |
| --- | --- |
| Investigation Created | Uma investigação foi criada no espaço do agente. |
| Investigation Priority Updated | A prioridade de uma investigação foi alterada. |
| Investigation In Progress | Uma investigação iniciou uma análise ativa. |
| Investigation Completed | Uma investigação foi concluída com sucesso com as descobertas. |
| Investigation Failed | Uma investigação encontrou um erro e não pôde ser concluída. |
| Investigation Timed Out | Uma investigação excedeu a duração máxima permitida. |
| Investigation Cancelled | Uma investigação foi cancelada antes da conclusão. |
| Investigation Pending Triage | Uma investigação está aguardando a triagem antes do início da análise ativa. |
| Investigation Linked | Uma investigação foi vinculada a um incidente ou ticket relacionado. |
### Eventos de mitigação suportados
| detail-type | Description |
| --- | --- |
| Mitigation In Progress | Uma ação de mitigação foi iniciada. |
| Mitigation Completed | Uma ação de mitigação foi concluída com sucesso. |
| Mitigation Failed | Uma ação de mitigação encontrou um erro e não pôde ser concluída. |
| Mitigation Timed Out | Uma ação de mitigação excedeu a duração máxima permitida. |
| Mitigation Cancelled | Uma ação de mitigação foi cancelada antes da conclusão. |
Para obter descrições de campo detalhadas e exemplos de eventos, consulte[AWS DevOps Referência detalhada de eventos do agente](integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-devops-agent-events-detail-reference.md).
## Criação de padrões de eventos que correspondam aos eventos AWS DevOps do Agente
EventBridge as regras usam padrões de eventos para selecionar eventos e encaminhá-los aos alvos. Um padrão de evento corresponde à estrutura dos eventos que ele manipula. Você cria padrões de eventos para filtrar eventos do AWS DevOps Agente com base nos campos de eventos.
Os exemplos a seguir mostram padrões de eventos para casos de uso comuns.
**Combine todos os eventos AWS DevOps do Agent**
O padrão de eventos a seguir corresponde a todos os eventos do AWS DevOps Agente.
```
{
"source": ["aws.aidevops"]
}
```
**Combine apenas eventos de investigação**
O padrão de evento a seguir usa uma correspondência de prefixo para selecionar somente eventos do ciclo de vida da investigação.
```
{
"source": ["aws.aidevops"],
"detail-type": [{"prefix": "Investigation"}]
}
```
**Combine apenas eventos de conclusão e falha**
O padrão de eventos a seguir corresponde aos eventos de investigações e mitigações concluídas ou fracassadas.
```
{
"source": ["aws.aidevops"],
"detail-type": [
"Investigation Completed",
"Investigation Failed",
"Mitigation Completed",
"Mitigation Failed"
]
}
```
**Combine eventos para um espaço de agente específico**
O padrão de eventos a seguir corresponde aos eventos de um espaço de agente específico.
```
{
"source": ["aws.aidevops"],
"detail": {
"metadata": {
"agent_space_id": ["your-agent-space-id"]
}
}
}
```
Para obter mais informações sobre padrões de eventos, consulte os [padrões de EventBridge eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) da *Amazon no Guia EventBridge do usuário* da Amazon.
## EventBridge Permissões da Amazon
AWS DevOps O agente não precisa de permissões adicionais para realizar eventos EventBridge. Os eventos são enviados automaticamente para o barramento de eventos padrão.
Dependendo dos alvos que você configura para suas EventBridge regras, talvez seja necessário adicionar permissões específicas. Para obter mais informações sobre as permissões necessárias para os alvos, consulte [Uso de políticas baseadas em recursos para a Amazon EventBridge no Guia EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) *do usuário da Amazon*.
## EventBridge Recursos adicionais
Para obter mais informações sobre EventBridge conceitos e configuração, consulte os seguintes tópicos no *Guia do EventBridge usuário da Amazon*:
+ [EventBridge ônibus para eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)
+ [EventBridge eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)
+ [EventBridge padrões de eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [EventBridge regras](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)
+ [EventBridge alvos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)
# AWS DevOps Referência detalhada de eventos do agente
Eventos de AWS serviços têm campos de metadados comuns`source`, incluindo`detail-type`,`account`,`region`, e. `time` Esses eventos também contêm um `detail` campo com dados específicos do serviço. Para eventos do AWS DevOps Agente, o `source` é sempre `aws.aidevops` e `detail-type` identifica o evento específico.
## Eventos de investigação
Os `detail-type` valores a seguir identificam os eventos da investigação:
+ `Investigation Created`
+ `Investigation Priority Updated`
+ `Investigation In Progress`
+ `Investigation Completed`
+ `Investigation Failed`
+ `Investigation Timed Out`
+ `Investigation Cancelled`
+ `Investigation Pending Triage`
+ `Investigation Linked`
Os `detail-type` campos `source` e estão incluídos abaixo porque contêm valores específicos para eventos AWS DevOps do agente. Para obter definições dos outros campos de metadados que estão incluídos em todos os eventos, consulte [Estrutura de eventos na Amazon EventBridge Events](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) *Reference*.
A seguir está a estrutura JSON para eventos de investigação.
```
{
. . .,
"detail-type" : "string",
"source" : "aws.aidevops",
. . .,
"detail" : {
"version" : "string",
"metadata" : {
"agent_space_id" : "string",
"task_id" : "string",
"execution_id" : "string"
},
"data" : {
"task_type" : "string",
"priority" : "string",
"status" : "string",
"created_at" : "string",
"updated_at" : "string",
"summary_record_id" : "string"
}
}
}
```
**`detail-type`**Identifica o tipo de evento. Para eventos de investigação, esse é um dos nomes de eventos listados anteriormente.
**`source`**Identifica o serviço que gerou o evento. Para eventos AWS DevOps do Agent, esse valor é`aws.aidevops`.
**`detail`**Um objeto JSON que contém dados específicos do evento. O `detail` objeto inclui os seguintes campos:
+ `version`(string) — A versão do esquema dos detalhes do evento. Atualmente`1.0.0`.
+ `metadata.agent_space_id`(string) — O identificador exclusivo do espaço do agente em que o evento se originou.
+ `metadata.task_id`(string) — O identificador exclusivo da tarefa.
+ `metadata.execution_id`(string) — O identificador exclusivo da execução. Presente quando uma execução foi atribuída à investigação.
+ `data.task_type`(string) — O tipo de tarefa. Valor:`INVESTIGATION`.
+ `data.priority`(string) — O nível de prioridade. Valores:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(string) — O status atual. Valores:`PENDING_START`,`IN_PROGRESS`,`COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`,`PENDING_TRIAGE`,`LINKED`.
+ `data.created_at`(string) — Registro de data e hora ISO 8601 quando a tarefa foi criada.
+ `data.updated_at`(string) — Registro de data e hora ISO 8601 de quando a tarefa foi atualizada pela última vez.
+ `data.summary_record_id`(string) — O identificador do registro resumido contendo os resultados da investigação. Incluído quando um resumo é gerado para a investigação concluída. Você pode recuperar o conteúdo resumido por meio da API do AWS DevOps agente usando esse identificador para pesquisar o registro do diário com um tipo de registro de`investigation_summary_md`.
**Exemplo: Evento de investigação concluído**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789015",
"detail-type": "Investigation Completed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:10:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "b2c3d4e5-6789-01ab-cdef-example22222"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "COMPLETED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:10:00Z",
"summary_record_id": "d4e5f6g7-6789-01ab-cdef-example44444"
}
}
}
```
**Exemplo: Evento de falha na investigação**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789016",
"detail-type": "Investigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:10:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "b2c3d4e5-6789-01ab-cdef-example22222"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:10:00Z"
}
}
}
```
## Eventos de mitigação
Os `detail-type` valores a seguir identificam eventos de mitigação:
+ `Mitigation In Progress`
+ `Mitigation Completed`
+ `Mitigation Failed`
+ `Mitigation Timed Out`
+ `Mitigation Cancelled`
Os `detail-type` campos `source` e estão incluídos abaixo porque contêm valores específicos para eventos AWS DevOps do agente. Para obter definições dos outros campos de metadados que estão incluídos em todos os eventos, consulte [Estrutura de eventos na Amazon EventBridge Events](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) *Reference*.
A seguir está a estrutura JSON para eventos de mitigação.
```
{
. . .,
"detail-type" : "string",
"source" : "aws.aidevops",
. . .,
"detail" : {
"version" : "string",
"metadata" : {
"agent_space_id" : "string",
"task_id" : "string",
"execution_id" : "string"
},
"data" : {
"task_type" : "string",
"priority" : "string",
"status" : "string",
"created_at" : "string",
"updated_at" : "string",
"summary_record_id" : "string"
}
}
}
```
**`detail-type`**Identifica o tipo de evento. Para eventos de mitigação, esse é um dos nomes de eventos listados anteriormente.
**`source`**Identifica o serviço que gerou o evento. Para eventos AWS DevOps do Agent, esse valor é`aws.aidevops`.
**`detail`**Um objeto JSON que contém dados específicos do evento. O `detail` objeto inclui os seguintes campos:
+ `version`(string) — A versão do esquema dos detalhes do evento. Atualmente`1.0.0`.
+ `metadata.agent_space_id`(string) — O identificador exclusivo do espaço do agente em que o evento se originou.
+ `metadata.task_id`(string) — O identificador exclusivo da tarefa.
+ `metadata.execution_id`(string) — O identificador exclusivo da execução. Presente quando uma execução foi atribuída à mitigação.
+ `data.task_type`(string) — O tipo de tarefa. Valor:`INVESTIGATION`.
+ `data.priority`(string) — O nível de prioridade. Valores:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(string) — O status atual. Valores:`IN_PROGRESS`,`COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`.
+ `data.created_at`(string) — Registro de data e hora ISO 8601 quando a tarefa foi criada.
+ `data.updated_at`(string) — Registro de data e hora ISO 8601 de quando a tarefa foi atualizada pela última vez.
+ `data.summary_record_id`(string) — O identificador do registro resumido contendo as descobertas de mitigação. Incluído quando um resumo é gerado para a mitigação concluída. Você pode recuperar o conteúdo resumido por meio da API do AWS DevOps agente usando esse identificador para pesquisar o registro do diário com um tipo de registro de`mitigation_summary_md`.
**Exemplo: Evento de mitigação concluído**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-12345678901c",
"detail-type": "Mitigation Completed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:20:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "c3d4e5f6-7890-12ab-cdef-example33333"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "COMPLETED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:20:00Z",
"summary_record_id": "e5f6g7h8-7890-12ab-cdef-example55555"
}
}
}
```
**Exemplo: evento de falha na mitigação**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-12345678901d",
"detail-type": "Mitigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:20:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "c3d4e5f6-7890-12ab-cdef-example33333"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:20:00Z"
}
}
}
```
# Registros e métricas vendidas
Você pode monitorar seus espaços de agentes e operações de serviço usando CloudWatch métricas e registros vendidos pela Amazon. Este tópico descreve as CloudWatch métricas que o AWS DevOps Agente publica automaticamente em sua conta e os registros vendidos que você pode configurar para entrega em seus destinos preferidos.
## Métricas vendidas CloudWatch
AWS DevOps O agente publica automaticamente métricas CloudWatch na Amazon em sua conta. Essas métricas estão disponíveis sem nenhuma configuração. Você pode usá-los para monitorar o uso, rastrear a atividade operacional e criar alarmes.
### Perfil vinculado ao serviço
Para que CloudWatch as métricas da Amazon sejam publicadas em sua conta para esse serviço, o AWS DevOps agente criará automaticamente a [função vinculada ao serviço **AWSServiceRoleForAIDevOps** Service-Linked](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) Role para você. Se a função do IAM que invoca a API não tiver a permissão apropriada, a criação do recurso falhará com um InvalidParameterException.
**Importante**
Os clientes que criaram sua função AgentSpace antes de 13 de março de 2026 precisarão criar manualmente a função vinculada ao serviço de **AWSServiceRoleForAIDevoperações** para que CloudWatch as métricas do AWS DevOps agente sejam publicadas em suas contas.
### Crie manualmente uma função vinculada ao serviço (para clientes existentes)
Execute um destes procedimentos:
+ No console do IAM, crie a função **AWSServiceRoleForAIDevOps** no serviço **AWS DevOps Agent**.
+ Na AWS CLI, execute o seguinte comando:
```
aws iam create-service-linked-role --aws-service-name aidevops.amazonaws.com
```
### Namespace
Todas as métricas são publicadas no `AWS/AIDevOps` namespace.
### Dimensões
Todas as métricas incluem a seguinte dimensão.
| Dimensão | Description |
| --- | --- |
| AgentSpaceUUID | O identificador exclusivo do espaço do agente. Para agregar métricas em todos os espaços de agentes em sua conta, use expressões CloudWatch matemáticas ou omita o filtro de dimensão. |
### Referência de métricas
| Nome da métrica | Description | Unidade | Frequência de publicação | Estatísticas úteis |
| --- | --- | --- | --- | --- |
| ConsumedChatRequests | O número de solicitações de bate-papo que o espaço de um agente consumiu. Para obter a contagem total da sua conta, use a SUM estatística em todas as AgentSpaceUUID dimensões. | Contagem | A cada 5 minutos | Soma, média |
| ConsumedInvestigationTime | O tempo gasto conduzindo investigações em um espaço de agente. | Segundos | A cada 5 minutos | Soma, média, máximo |
| ConsumedEvaluationTime | O tempo gasto executando avaliações em um espaço de agente. | Segundos | A cada 5 minutos | Soma, média, máximo |
| TopologyCompletionCount | O número de conclusões do processamento de topologia. AWS DevOps O agente emite essa métrica quando uma topologia termina o processamento, seja desde a criação inicial durante a integração, uma atualização manual ou uma atualização diária programada. | Contagem | Orientado por eventos (emitido em cada conclusão) | Soma, SampleCount |
### Visualizando métricas no CloudWatch console
1. Abra o [console do CloudWatch ](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Metrics** (Métricas) e, em seguida, **All metrics** (Todas as métricas).
1. Escolha o namespace **AWS/AIDevOps**.
1. Escolha **Por AgentSpace** para ver as métricas dos seus espaços de agente.
**nota**
**Você pode criar CloudWatch alarmes sobre essas métricas para receber notificações quando o uso exceder um limite. Por exemplo, crie um alarme `ConsumedChatRequests` para monitorar o consumo de solicitações de bate-papo.
## Pré-requisitos
Antes de configurar a entrega de registros, verifique se você tem o seguinte:
+ Uma AWS conta ativa com acesso ao console do AWS DevOps agente
+ Um diretor do IAM com permissões para entrega de CloudWatch registros APIs
+ (Opcional) Um bucket do Amazon S3 ou um stream de entrega do Amazon Data Firehose, se você planeja usá-los como destinos de log
## Logs fornecidos
AWS DevOps O agente oferece suporte a registros vendidos que fornecem visibilidade dos eventos que seus espaços de agentes e registros de serviços processam. Os registros vendidos usam a infraestrutura Amazon CloudWatch Logs para entregar os registros ao seu destino preferido.
Para usar registros vendidos, você deve configurar um destino de entrega. Os seguintes destinos são compatíveis:
+ **Amazon CloudWatch Logs** — Um grupo de registros em sua conta
+ **Amazon S3** — Um bucket S3 em sua conta
+ **Amazon Data Firehose** — Um stream de entrega do Firehose em sua conta
### Tipos de log compatíveis
Um único tipo de log é suportado:`APPLICATION_LOGS`. Esse tipo de registro abrange todos os eventos operacionais que o serviço emite.
### Registrar tipos de eventos
A tabela a seguir resume os eventos que o AWS DevOps Agente registra.
| Event | Description | Nível de log |
| --- | --- | --- |
| Evento de entrada do agente recebido | Um agente é acionado por uma fonte integrada e recebe um evento de entrada (por exemplo, um evento de PagerDuty incidente). | INFO |
| Evento de entrada de agentes cancelado | Um evento de entrada foi descartado antes que o agente o processasse. O registro inclui o motivo (por exemplo, dados malformados). | A ser definido |
| Falha na comunicação de saída do agente | Uma comunicação externa com uma integração de terceiros falhou. O registro inclui o ID da tarefa e o identificador de destino (por exemplo, um erro de autenticação). | A ser definido |
| Criação de topologia em fila | Um trabalho de criação de topologia foi colocado na fila para processamento. | INFO |
| A criação da topologia foi iniciada | Um trabalho de criação de topologia começou a ser processado. | INFO |
| Criação da topologia concluída | Um trabalho de criação de topologia concluiu o processamento. Esse evento se aplica à criação inicial, às atualizações e às atualizações diárias. | INFO |
| Falha na descoberta de recursos | A descoberta de recursos durante a criação da topologia encontrou uma falha. | ERRO |
| Falha no registro do serviço | O registro do serviço encontra uma falha irrecuperável | ERRO |
| Falha na validação do webhook | Quando o webhook recebido pelo agente Devops não corresponde ao esquema esperado | ERRO |
| Atualizações do status de validação da associação | Quando uma associação de espaço de agente ( primary/secondary conta típica), o status de validação muda de válido para inválido e vice-versa (por exemplo, causado por uma função malformada, que não pode ser assumida pelo serviço). | ERRO/INFORMAÇÃO |
### Permissões
AWS DevOps O agente usa [registros CloudWatch vendidos (permissões V2)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) para entregar registros. Para configurar a entrega de registros, a função do IAM que configura a entrega deve ter as seguintes permissões:
+ `aidevops:AllowVendedLogDeliveryForResource`— Necessário para permitir a entrega de registros para o recurso de espaço do agente.
+ Permissões para a entrega de CloudWatch registros APIs (`logs:PutDeliverySource``logs:PutDeliveryDestination`,`logs:CreateDelivery`, e operações relacionadas).
+ Permissões específicas para o destino de entrega escolhido.
Para ver a política completa do IAM que é necessária para cada tipo de destino, consulte os seguintes tópicos no *Guia do usuário do Amazon CloudWatch Logs*:
+ [Registros enviados para CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-CloudWatchLogs.html)
+ [Logs enviados ao Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html)
+ [Registros enviados para o Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)
### Configurar a entrega de registros (console)
AWS DevOps O agente fornece dois locais no console AWS de gerenciamento para configurar a entrega de registros:
+ **Página de configurações de registro de serviço** — Configure a entrega de registros para eventos de nível de serviço. Esses registros usam o serviço ARN (`arn:aws:aidevops:::service/`) como recurso.
+ **Página Espaço do agente** — Configure a entrega de registros para eventos específicos de um espaço de agente individual. Esses registros usam o espaço do agente ARN (`arn:aws:aidevops:::agentspace/`) como recurso.
#### Para configurar a entrega de registros para um registro de serviço
1. Abra o console do AWS DevOps agente no console AWS de gerenciamento.
1. No painel de navegação, selecione **Configurações**.
1. Na guia **Capability Providers** **>** **Logs**, escolha **Configure**.
1. Em **Tipo de destino**, escolha uma das seguintes opções:
1. **CloudWatch Registros** — Selecione ou crie um grupo de registros.
1. **Amazon S3** — Insira o ARN do bucket do S3.
1. **Amazon Data Firehose** — Selecione ou crie um stream de entrega do Firehose.
1. Para **Configurações adicionais** — *opcionais*, você pode especificar as seguintes opções:
1. Em **Seleção de campos**, escolha o nome dos campos de log que você deseja entregar ao seu destino. Você pode selecionar [campos de log de acesso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) e um subconjunto de [campos de log de acesso em tempo real](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Somente para o Amazon S3) Em **Particionamento**, especifique o caminho para particionar os dados do arquivo de log.
1. (Somente para o Amazon S3) Em **Formato de arquivo compatível com o Hive**, você pode marcar a caixa de seleção para usar caminhos do S3 compatíveis com o Hive. Isso ajuda a simplificar o carregamento de novos dados em suas ferramentas compatíveis com o Hive.
1. Em **Formato de saída**, especifique o formato de sua preferência.
1. Em **Delimitador de campo**, especifique como separar os campos de log.
1. Escolha **Salvar**.
1. Verifique se o status da entrega mostra **Ativo**.
#### Para configurar a entrega de registros para um espaço de agente
1. Abra o console do AWS DevOps agente no console AWS de gerenciamento.
1. Escolha o espaço do agente que você deseja configurar.
1. Na guia **Configuração**, escolha **Configurar**.
1. Em **[Tipo de destino](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2:~:text=sts%3AAssumeRole%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D-,Logging%20that%20requires%20additional%20permissions%20%5BV2%5D,-Some%20AWS%20services)**, escolha uma das seguintes opções:
1. **CloudWatch Registros** — Selecione ou crie um grupo de registros.
1. **Amazon S3** — Insira o ARN do bucket do S3.
1. **Amazon Data Firehose** — Selecione ou crie um stream de entrega do Firehose.
1. Para **Configurações adicionais — \$1opcional\$1**, você pode especificar as seguintes opções:
1. Em **Seleção de campos**, escolha o nome dos campos de log que você deseja entregar ao seu destino. Você pode selecionar [campos de log de acesso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) e um subconjunto de [campos de log de acesso em tempo real](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Somente para o Amazon S3) Em **Particionamento**, especifique o caminho para particionar os dados do arquivo de log.
1. (Somente para o Amazon S3) Em **Formato de arquivo compatível com o Hive**, você pode marcar a caixa de seleção para usar caminhos do S3 compatíveis com o Hive. Isso ajuda a simplificar o carregamento de novos dados em suas ferramentas compatíveis com o Hive.
1. Em **Formato de saída**, especifique o formato de sua preferência.
1. Em **Delimitador de campo**, especifique como separar os campos de log.
1. Escolha **Salvar**.
1. Verifique se o status da entrega mostra **Ativo**.
### Configurar a entrega de registros (CloudWatch API)
Você também pode usar a API CloudWatch Logs para configurar a entrega de registros de forma programática. A entrega de um log de trabalho consiste em três elementos:
+ A **DeliverySource**— Representa o recurso de espaço do AWS DevOps agente que gera os registros.
+ A **DeliveryDestination**— Representa o destino em que os registros são gravados.
+ Uma **entrega** — conecta uma fonte de entrega a um destino de entrega.
#### Etapa 1: criar uma fonte de entrega
Use a [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)operação para criar uma fonte de entrega. Passe o ARN do seu recurso de espaço do AWS DevOps agente e especifique `APPLICATION_LOGS` como o tipo de registro.
O exemplo a seguir cria uma fonte de entrega para um espaço de agente:
```
{
"name": "my-agent-space-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/my-agent-space-id",
"logType": "APPLICATION_LOGS"
}
```
O exemplo a seguir cria uma fonte de entrega para o serviço:
```
{
"name": "my-service-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:service",
"logType": "APPLICATION_LOGS"
}
```
#### Etapa 2: criar um destino de entrega
Use a [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)operação para configurar onde os registros são armazenados. Você pode escolher Amazon CloudWatch Logs, Amazon S3 ou Amazon Data Firehose.
O exemplo a seguir cria um destino de CloudWatch registros:
```
{
"name": "my-cwl-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/aidevops/my-agent-space"
},
"outputFormat": "json"
}
```
O exemplo a seguir cria um destino do Amazon S3:
```
{
"name": "my-s3-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::my-aidevops-logs-bucket"
},
"outputFormat": "json"
}
```
O exemplo a seguir cria um destino do Amazon Data Firehose:
```
{
"name": "my-firehose-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-aidevops-log-stream"
},
"outputFormat": "json"
}
```
**nota**
**Se você entregar registros em várias contas, deverá usá-los [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html)na conta de destino para autorizar a entrega.
Se você quiser usar CloudFormation, você pode usar o seguinte:
+ [Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
+ [DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn` é `AgentSpaceArn`, e `LogType` deve ser `APPLICATION_LOGS` como o tipo de log compatível.
#### Etapa 3: criar uma entrega
Use a [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)operação para vincular a origem da entrega ao destino da entrega.
```
{
"deliverySourceName": "my-agent-space-delivery-source",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:my-cwl-destination"
}
```
#### AWS CloudFormation
Você também pode configurar a entrega de registros usando AWS CloudFormation os seguintes recursos:
+ [AWS: :Registros:: DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
+ [AWS: :Registros:: DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [AWS: :Logs: :Entrega](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
`ResourceArn`Defina o espaço do AWS DevOps agente ou o ARN do serviço e `LogType` defina como. `APPLICATION_LOGS`
### Registro da referência de esquemas
AWS DevOps O agente usa um esquema de log compartilhado em todos os tipos de eventos. Nem todo evento de log usa todos os campos.
A tabela a seguir descreve os campos no esquema de log.
| Campo | Tipo | Description |
| --- | --- | --- |
| event\$1timestamp | Longo | Timestamp Unix de quando o evento ocorreu |
| resource\$1arn | String | ARN do recurso que gerou o evento |
| id\$1da\$1conta opcional | String | AWS ID da conta associada ao registro. |
| nível\$1opcional | String | Nível de registro:INFO,WARN, ERROR |
| id\$1do\$1espaço\$1agente opcional | String | Identificador do espaço do agente. |
| id\$1de\$1associação opcional | String | Identificador de associação para o registro. |
| status\$1opcional | String | Status da operação de topologia. |
| id\$1webhook\$1id opcional | String | Identificador de webhook. |
| url\$1mcp\$1endpoint\$1opcional | String | URL do endpoint do servidor MCP |
| tipo\$1de\$1serviço\$1opcional | String | Tipo de serviço:DYNATRACE,DATADOG,GITHUB,SLACK,SERVICENOW. |
| url\$1de\$1endpoint\$1de\$1serviço opcional | String | URL do endpoint para integrações de terceiros. |
| id\$1de\$1serviço opcional | String | Identificador da fonte. |
| request\$1id | String | Identificador de solicitação para correlacionar com AWS CloudTrail nossos tickets de suporte. |
| operação\$1opcional | String | Nome da operação que foi executada. |
| tipo\$1de\$1tarefa\$1opcional | String | Tipo de tarefa da lista de pendências do agente: INVESTIGATION ou EVALUATION |
| id\$1da\$1tarefa\$1opcional | String | Agent Backlog Task Identificador IDAgent de tarefa de backlog. |
| referência\$1opcional | String | Referência de uma tarefa do agente (por exemplo, um ticket do Jira). |
| tipo\$1de\$1erro opcional | String | Tipo de erro |
| mensagem\$1de\$1erro opcional | String | Descrição do erro quando uma operação falha. |
| detalhes\$1opcionais | Cadeia de caracteres (JSON) | Carga útil de eventos específica do serviço que contém parâmetros e resultados da operação. |
### Gerenciar e desativar a entrega de registros
Você pode modificar ou remover a entrega de registros a qualquer momento no console do AWS DevOps agente no AWS Management Console ou usando a API de CloudWatch registros.
#### Gerenciar a entrega de registros (console)
1. Abra o console do AWS DevOps agente no console AWS de gerenciamento.
1. Navegue até a página **Configurações** (para registros de nível de serviço) ou a página específica do Espaço do **Agente (para registros no nível do Espaço** do Agente).
1. Na guia **Configuração** (para registros no nível do Agent Space) ou na guia **Capability Providers** **>** **Logs (para registros** no nível do serviço), escolha a entrega a ser modificada.
1. Atualize a configuração conforme necessário e escolha **Salvar**.
**Observação:** você não pode alterar o tipo de destino de uma entrega existente. Para alterar o tipo de destino, exclua a entrega atual e crie uma nova.
#### Desativar a entrega de registros (console)
1. Abra o console do AWS DevOps agente no console AWS de gerenciamento.
1. Navegue até a página **Configurações** (para registros de nível de serviço) ou a página específica do Espaço do **Agente (para registros no nível do Espaço** do Agente).
1. Na guia **Configuração** (para registros no nível do Agent Space) ou na guia **Capability Providers** **>** **Logs (para registros** no nível do serviço), selecione a entrega a ser removida.
1. Escolha **Excluir** e confirme.
#### Desativar a entrega de registros (API)
Para remover uma entrega de registros usando a API, exclua os recursos na seguinte ordem:
1. Exclua a entrega usando [DeleteDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDelivery.html).
1. Exclua a fonte de entrega usando [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html).
1. (Opcional) Se o destino da entrega não for mais necessário, exclua-o usando [DeleteDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliveryDestination.html).
**Importante**
**Você é responsável por remover os recursos de entrega de registros depois de excluir o recurso de espaço do agente que gera os registros (por exemplo, depois de excluir um espaço do agente). Se você não remover esses recursos, as configurações de entrega órfã poderão permanecer.
## Preços
O AWS DevOps agente não cobra pela ativação de registros vendidos. Entretanto, você pode incorrer em cobranças pela entrega, ingestão, armazenamento ou acesso, dependendo do destino de entrega de log selecionado. Para obter detalhes sobre preços, consulte **Vended Logs** na guia **Logs** em [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Para preços específicos do destino, consulte o seguinte:
+ [Preços do Amazon CloudWatch Logs](https://aws.amazon.com/cloudwatch/pricing/)
+ [Preços do Amazon S3](https://aws.amazon.com/s3/pricing/)
+ [Definição de preço do Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/pricing/)
# Conectando-se a ferramentas hospedadas de forma privada
## Visão geral das conexões privadas
AWS DevOps O agente pode ser estendido com ferramentas personalizadas do Model Context Protocol (MCP) e outras integrações que dão ao agente acesso a sistemas internos, como registros de pacotes privados, plataformas de observabilidade auto-hospedadas APIs, documentação interna e instâncias de controle de origem (consulte:). [Configurando recursos para AWS DevOps o Agent](configuring-capabilities-for-aws-devops-agent.md) Esses serviços geralmente são executados dentro de uma [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide) com acesso restrito ou nenhum acesso público à Internet, o que significa que o AWS DevOps Agente não pode acessá-los por padrão.
As conexões privadas do AWS DevOps Agent permitem que você conecte com segurança seu Espaço do Agente aos serviços em execução na sua VPC sem expô-los à Internet pública. As conexões privadas funcionam com qualquer integração que precise alcançar um endpoint privado, incluindo servidores MCP, instâncias Grafana ou Splunk auto-hospedadas e sistemas GitHub de controle de origem, como Enterprise Server e Self-Managed. GitLab
**nota**
**Se suas ferramentas hospedadas de forma privada fizerem solicitações de saída para o AWS DevOps Agente de dentro da sua VPC, esse tráfego também poderá ser protegido usando um VPC Endpoint para que ele permaneça na rede. AWS Por exemplo, isso pode ser usado com ferramentas que acionam o DevOps Agente por meio de eventos de webhook (consulte:[Invocando o DevOps Agente por meio do Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)). Para obter mais informações, consulte [VPC endpoints (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md).
### Como as conexões privadas funcionam
Uma conexão privada cria um caminho de rede seguro entre o AWS DevOps Agente e um recurso de destino em sua VPC. Nos bastidores, o AWS DevOps Agent usa o Amazon [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) para estabelecer esse caminho seguro de conectividade privada. O VPC Lattice é um serviço de rede de aplicativos que permite conectar, proteger e monitorar a comunicação entre aplicativos VPCs, contas e tipos de computação, sem gerenciar a infraestrutura de rede subjacente.
Quando você cria uma conexão privada, ocorre o seguinte:
+ Você fornece a VPC, as sub-redes e (opcionalmente) os grupos de segurança que têm conectividade de rede com seu serviço de destino.
+ AWS DevOps O agente cria um [gateway de recursos](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html) gerenciado por serviços e provisiona suas interfaces de rede elástica (ENIs) nas sub-redes que você especificou.
+ O agente usa o gateway de recursos para rotear o tráfego para o endereço IP ou nome DNS do serviço de destino pelo caminho da rede privada.
O gateway de recursos é totalmente gerenciado pelo AWS DevOps Agente e aparece como um recurso somente para leitura em sua conta (nomeado`aidevops-{your-private-connection-name}`). Você não precisa configurá-lo ou mantê-lo. Os únicos recursos criados em sua VPC estão ENIs nas sub-redes que você especifica. Eles ENIs servem como ponto de entrada para o tráfego privado e são gerenciados inteiramente pelo serviço. Eles não aceitam conexões de entrada da Internet e você mantém controle total sobre o tráfego deles por meio de seus próprios grupos de segurança.
### Segurança
As conexões privadas são projetadas com várias camadas de segurança:
+ **Sem exposição pública à Internet** — Todo o tráfego entre o AWS DevOps agente e seu serviço de destino permanece na AWS rede. Seu serviço nunca precisa de um endereço IP público ou gateway de internet.
+ Gateway **de recursos controlados por serviços — O gateway** de recursos gerenciados por serviços é somente para leitura em sua conta. Ele só pode ser usado pelo AWS DevOps Agente, e nenhum outro serviço ou principal pode rotear o tráfego por ele. Você pode verificar isso nos [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)registros, que registram todas as chamadas da API VPC Lattice.
+ **Seus grupos de segurança, suas regras** — Você controla o tráfego de entrada e saída para os grupos ENIs de segurança que você possui e gerencia. Se você não especificar grupos de segurança, o AWS DevOps Agente cria um grupo de segurança padrão com o escopo das portas que você define.
+ **Funções vinculadas ao serviço com menos privilégios** — O AWS DevOps agente usa uma [função vinculada ao serviço para criar](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) somente os recursos necessários do VPC Lattice e do Amazon EC2. Essa função tem como escopo os recursos marcados com `AWSAIDevOpsManaged` e não pode acessar nenhum outro recurso em sua conta.
**nota**
**Se sua organização tem [políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que restringem as ações da API VPC Lattice, o gateway de recursos gerenciados por serviços é criado por meio de uma função vinculada ao serviço. Certifique-se de SCPs permitir as ações necessárias para a função vinculada ao serviço.
### Arquitetura
O diagrama a seguir mostra o caminho de rede para uma conexão privada.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/7cd6182e6b8d.png)
Nesta arquitetura:
+ AWS DevOps O agente inicia uma solicitação para seu serviço de destino.
+ O Amazon VPC Lattice encaminha a solicitação por meio do gateway de recursos gerenciado por serviços em sua VPC. Para configurações avançadas usando seus próprios recursos do VPC Lattice, [consulte Configuração avançada usando os recursos existentes do VPC](#advanced-setup-using-existing-vpc-lattice-resources) Lattice.
+ Uma ENI na sua VPC recebe o tráfego e o encaminha para o endereço IP ou nome DNS do seu serviço de destino.
+ Seus grupos de segurança controlam qual tráfego é permitido por meio do ENIs.
+ Do ponto de vista do seu serviço de destino, a solicitação se origina de endereços IP privados de ENIs sua VPC.
## Crie uma conexão privada
Você pode criar uma conexão privada usando o AWS Management Console ou a AWS CLI.
**nota**
**As seguintes zonas de disponibilidade não são compatíveis com o VPC Lattice:`use1-az3`,,,`usw1-az2`,`apne1-az3`,, `apne2-az2``euc1-az2`,`euw1-az4`. `cac1-az3` `ilc1-az2`
### Pré-requisitos
Antes de criar uma conexão privada, verifique se você tem o seguinte:
+ **Um Espaço do Agente ativo** — Você precisa de um Espaço do Agente existente na sua conta. Se você não tiver uma, consulte [Começando com o AWS DevOps Agent](getting-started-with-aws-devops-agent.md).
+ **Um serviço de destino com acesso privado** — Seu servidor MCP, plataforma de observabilidade ou outro serviço deve estar acessível em um endereço IP privado conhecido ou nome DNS da VPC em que o gateway de recursos está implantado. O serviço pode ser executado na mesma VPC, em uma VPC emparelhada ou no local, desde que seja roteável a partir das sub-redes do gateway de recursos. O serviço deve fornecer tráfego HTTPS com uma versão TLS mínima de 1.2 em uma porta que você especifica ao criar a conexão.
+ **Sub-redes em sua VPC** — identifique de 1 a 20 sub-redes nas quais elas serão criadas. ENIs Recomendamos selecionar sub-redes em várias zonas de disponibilidade para alta disponibilidade. Essas sub-redes devem ter conectividade de rede com seu serviço de destino. Uma sub-rede por zona de disponibilidade pode ser usada pelo VPC Lattice.
+ **(Opcional) Grupos de segurança** — Se você quiser controlar o tráfego com regras específicas, prepare até cinco grupos de segurança IDs para anexar ao ENIs. Se você omitir grupos de segurança, o AWS DevOps Agente cria um grupo de segurança padrão.
Conexões privadas são recursos em nível de conta. Depois de criar uma conexão privada, você pode reutilizá-la em várias integrações e espaços de agentes que precisam alcançar o mesmo host.
### Crie uma conexão privada usando o console
1. Abra o console do AWS DevOps agente.
1. No painel de navegação, escolha **Provedores de capacidade** e, em seguida, escolha **Conexões privadas**.
1. Escolha **Criar uma conexão**.
1. Em **Nome**, insira um nome descritivo para a conexão, como`my-mcp-tool-connection`.
1. Para **VPC**, selecione a VPC em que o gateway ENIs de recursos será implantado.
1. Para **Sub-redes**, selecione uma ou mais sub-redes (até 20). Recomendamos escolher sub-redes em pelo menos duas zonas de disponibilidade.
1. Para **o tipo de endereço IP**, selecione o tipo de endereço IP do seu serviço de destino (`IPv4`,`IPv6`, ou`DualStack`).
1. (Opcional) Em **Número de IPv4 endereços**, se você IPv4 selecionou Dualstack para o tipo de endereço IP, você pode inserir o número de IPv4 endereços por ENI para seu gateway de recursos. O padrão é 16 IPv4 endereços por ENI.
1. (Opcional) Para **grupos** de segurança, selecione grupos de segurança existentes (até 5) para restringir qual tráfego pode alcançar seu serviço de destino. Se você não selecionar nenhum, um grupo de segurança padrão será criado.
1. (Opcional) Para **intervalos de portas**, especifique as portas TCP que seu aplicativo de destino escuta (por exemplo, `443` ou`8080-8090`). Você pode especificar até 11 intervalos de portas.
1. Em **Endereço do host**, insira o endereço IP ou o nome DNS do serviço de destino (por exemplo, `mcp.internal.example.com` ou`10.0.1.50`). O serviço deve estar acessível a partir da VPC selecionada. Se você escolher um nome DNS, ele deverá ser resolvido na VPC selecionada.
1. (Opcional) Em **Chave pública do certificado**, se o endereço do host que você especificou usar certificados TLS emitidos por uma autoridade de certificação privada, insira a chave pública codificada pelo PEM do certificado. Isso permite que o AWS DevOps Agente confie na conexão TLS com seu serviço de destino.
1. Escolha **Criar conexão**.
O status da conexão muda para **Criar em andamento**. Esse processo pode levar até 10 minutos. Quando o status muda para **Ativo**, o caminho da rede está pronto.
Se o status mudar para **Falha na criação**, verifique o seguinte:
+ As sub-redes que você especificou têm endereços IP disponíveis.
+ Sua conta não atingiu as cotas de serviço do VPC Lattice.
+ Nenhuma política restritiva do IAM está impedindo que a função vinculada ao serviço crie recursos.
**nota**
**Essas etapas também podem ser executadas selecionando `Create a new private connection` durante o registro de um provedor de recursos. Para obter mais informações, consulte [Usar uma conexão privada com um provedor de recursos](#use-a-private-connection-with-a-capability-provider).
### Crie uma conexão privada usando a AWS CLI
Execute o comando a seguir para criar uma conexão privada. Substitua os valores do espaço reservado pelos seus.
```
aws devops-agent create-private-connection \
--name my-mcp-tool-connection \
--mode '{
"serviceManaged": {
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0",
"subnetIds": [
"subnet-0123456789abcdef0",
"subnet-0123456789abcdef1"
],
"securityGroupIds": [
"sg-0123456789abcdef0"
],
"portRanges": ["443"]
}
}'
```
A resposta inclui o nome da conexão e um status de`CREATE_IN_PROGRESS`:
```
{
"name": "my-mcp-tool-connection",
"status": "CREATE_IN_PROGRESS",
"resourceGatewayId": "rgw-0123456789abcdef0",
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0"
}
```
Para verificar o status da conexão, use o `describe-private-connection` comando:
```
aws devops-agent describe-private-connection \
--name my-mcp-tool-connection
```
Quando o status for`ACTIVE`, sua conexão privada estará pronta para uso.
## Use uma conexão privada com um provedor de recursos
Para usar uma conexão privada, você pode vinculá-la durante o registro de um provedor de recursos. Os recursos compatíveis que podem ser usados com conexões privadas incluem: `GitHub` `GitLab``MCP Server`,, `Grafana` e. Você pode executar essa etapa usando o console AWS de gerenciamento ou a AWS CLI.
**nota**
**Ao registrar um provedor de recursos, o AWS DevOps Agente valida se o endpoint está acessível e está respondendo. Certifique-se de que seu serviço de destino esteja funcionando e aceitando conexões antes de concluir o registro.
### Use uma conexão privada com um provedor de recursos usando o console
No console do AWS DevOps agente, as conexões privadas podem ser vinculadas a um recurso durante o registro, selecionando a opção “Conectar-se ao endpoint usando uma conexão privada”.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/devopsagent/latest/userguide/images/a2a7ffb70ffe.png)
1. Abra o console do AWS DevOps agente e navegue até seu Espaço do agente.
1. Na seção **Provedores de recursos**, escolha **Registro**.
1. Selecione **Registrar** para o tipo de capacidade que você deseja usar com a conexão privada.
1. Na visualização de detalhes do registro, insira o URL do Endpoint ao qual você deseja se conectar usando a conexão privada (por exemplo,`https://mcp.internal.example.com`).
1. Selecione **Conectar ao endpoint usando uma conexão privada**.
1. Selecione uma conexão privada existente que corresponda ao URL do Endpoint ao qual você deseja se conectar ou selecione **Criar uma nova conexão privada** para criar uma.
1. Conclua o processo de registro do provedor de recursos.
### Use uma conexão privada com um provedor de recursos usando a AWS CLI
Você pode registrar recursos com uma conexão privada incluindo o `private-connection-name` argumento. Abaixo está um exemplo de registro de um servidor MCP com autorização de chave de API usando a conexão `my-mcp-tool-connection` privada. Substitua os valores do espaço reservado pelos seus.
```
aws devops-agent register-service \
--service mcpserver \
--private-connection-name my-mcp-tool-connection \
--service-details '{
"mcpserver": {
"name": "my-mcp-tool",
"endpoint": "https://mcp.internal.example.com",
"authorizationConfig": {
"apiKey": {
"apiKeyName": "api-key",
"apiKeyValue": "secret-value",
"apiKeyHeader": "x-api-key"
}
}
}
}' \
--region us-east-1
```
## Verificar uma conexão privada
Depois que a conexão privada atingir o estado **Ativo** e for utilizada por um provedor de recursos, verifique se o AWS DevOps Agente pode acessar seu serviço de destino:
1. Abra o console do AWS DevOps agente e navegue até seu Espaço do agente.
1. Inicie uma nova sessão de bate-papo.
1. Invoque um comando que usa a integração apoiada por sua conexão privada. Por exemplo, se sua ferramenta MCP fornece acesso a uma base de conhecimento interna, faça ao agente uma pergunta que exija essa base de conhecimento.
1. Confirme se o agente retorna os resultados do serviço privado.
Se a conexão falhar, verifique o seguinte:
+ [Limites do **VPC Lattice — Verifique se você não atingiu nenhum gateway de recursos ou outros limites** de cota do VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html)
+ **Regras do grupo de segurança** — Verifique se os grupos de segurança conectados ao ENIs permitem tráfego de saída na porta que seu serviço escuta. Verifique também se o grupo de segurança do seu serviço permite tráfego de entrada na porta de destino. O tráfego chega do plano de dados VPC Lattice dentro do intervalo IPs CIDR do VPC. Você pode usar a referência de grupos de segurança (permitindo o grupo de segurança ENI como fonte) ou permitir a entrada do CIDR da VPC.
+ **Conectividade de sub-rede** — verifique se as sub-redes selecionadas podem rotear o tráfego para seu serviço. Se o serviço for executado em uma sub-rede diferente, confirme se as tabelas de rotas permitem tráfego entre elas.
+ **Disponibilidade do serviço** — confirme se seu serviço está em execução e aceitando conexões na porta esperada.
+ **Zona de disponibilidade não suportada** - verifique se suas sub-redes estão em zonas de disponibilidade suportadas. Execute `aws ec2 describe-subnets --subnet-ids --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'` e verifique as zonas de disponibilidade não suportadas listadas acima.
## Excluir uma conexão privada
Você pode excluir conexões privadas não utilizadas usando o AWS Management Console ou a AWS CLI.
### Excluir uma conexão privada usando o console
1. Abra o console do AWS DevOps agente.
1. No painel de navegação, escolha **Provedores de capacidade** e, em seguida, escolha **Conexões privadas**.
1. Selecione o menu **Ações** da conexão privada que você deseja excluir e selecione **Remover**.
A conexão privada será exibida com o status “Removendo conexão” enquanto o AWS DevOps Agente remove o gateway de recursos gerenciados e ENIs da sua VPC. Depois que a exclusão for concluída, a conexão não aparecerá mais na sua lista de conexões privadas.
### Excluir uma conexão privada usando a AWS CLI
```
aws devops-agent delete-private-connection \
--name my-mcp-tool-connection
```
A resposta retorna um status de`DELETE_IN_PROGRESS`. AWS DevOps O agente remove o gateway de recursos gerenciados e ENIs da sua VPC. Depois que a exclusão for concluída, a conexão não aparecerá mais na sua lista de conexões privadas.
## Configuração avançada usando os recursos existentes do VPC Lattice
Se sua organização já usa o Amazon VPC Lattice e gerencia suas próprias configurações de recursos, você pode criar uma conexão privada no modo autogerenciado. Em vez de fazer com que o AWS DevOps Agente crie um gateway de recursos para você, você fornece o Amazon Resource Name (ARN) de uma configuração de recurso existente que aponta para seu serviço de destino.
Essa abordagem é útil quando você:
+ Quer controle total sobre o gateway de recursos e o ciclo de vida da configuração de recursos.
+ Precisa compartilhar configurações de recursos em várias AWS contas ou serviços.
+ Exija registros de acesso ao VPC Lattice para monitoramento detalhado do tráfego.
+ Execute uma arquitetura hub-and-spoke de rede.
Para criar uma conexão privada autogerenciada com a AWS CLI:
```
aws devops-agent create-private-connection \
--name my-advanced-connection \
--mode '{
"selfManaged": {
"resourceConfigurationId": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-0123456789abcdef0"
}
}'
```
Para obter mais detalhes sobre como configurar gateways de recursos e configurações de recursos do VPC Lattice, consulte o Guia do usuário do Amazon [VPC](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) Lattice.
## Tópicos relacionados
+ [VPC endpoints (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)
+ [Conectando servidores MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
+ [Configurando recursos para AWS DevOps o Agent](configuring-capabilities-for-aws-devops-agent.md)
+ [AWS DevOps Segurança do agente](aws-devops-agent-security.md)
+ [DevOps Permissões do Agent IAM](aws-devops-agent-security-devops-agent-iam-permissions.md)