Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Configurazione delle funzionalità per Agent AWS DevOps
AWS DevOps Le funzionalità dell'agente estendono le funzionalità dell'agente collegandolo agli strumenti e all'infrastruttura esistenti. Configura queste funzionalità per consentire un'indagine completa sugli incidenti, flussi di lavoro di risposta automatizzati e una perfetta integrazione con il tuo DevOps ecosistema.
Le seguenti funzionalità ti aiutano a massimizzare l'efficacia del tuo DevOps agente:
+ **AWS EKS Access Setup**: abilita l'introspezione dei cluster Kubernetes, dei pod log e degli eventi del cluster per ambienti EKS pubblici e privati
+ **Integrazione con Azure**: collega le sottoscrizioni di Azure e le DevOps organizzazioni di Azure per esaminare le risorse di Azure e correlare le distribuzioni di Azure agli incidenti DevOps
+ Integrazione della **pipeline CI/CD:** Connect GitHub e GitLab pipeline per correlare le implementazioni agli incidenti e tenere traccia delle modifiche al codice durante le indagini
+ **Connessioni al server MCP**: estendi le capacità di indagine collegando strumenti di osservabilità esterni e sistemi di monitoraggio personalizzati tramite Model Context Protocol
+ ** AWS Accesso multiaccount**: configura AWS account secondari per esaminare le risorse dell'intera organizzazione durante la risposta agli incidenti
+ Integrazione delle **fonti di telemetria:** collega piattaforme di monitoraggio come Datadog, Dynatrace, Grafana, New Relic e Splunk per un accesso completo ai dati di osservabilità
+ **Integrazione di ticket e chat**: Connect ServiceNow e Slack per automatizzare i flussi di lavoro di risposta agli incidenti e consentire la collaborazione in team PagerDuty
+ **Configurazione Webhook**: consenti ai sistemi esterni di attivare DevOps automaticamente le indagini degli agenti tramite richieste HTTP
+ ** EventBridge Integrazione con Amazon**: incorpora AWS DevOps Agent in applicazioni basate sugli eventi indirizzando gli eventi del ciclo di vita di indagine e mitigazione verso obiettivi Amazon EventBridge
Puoi configurare ogni funzionalità in modo indipendente in base alle esigenze specifiche del tuo team e allo stack di strumenti esistente. Inizia con le integrazioni più importanti per il flusso di lavoro di risposta agli incidenti, quindi espandi le funzionalità aggiuntive se necessario.
# Migrazione dall'anteprima pubblica alla disponibilità generale
Se hai utilizzato AWS DevOps Agent durante l'anteprima pubblica, devi aggiornare i ruoli IAM prima della versione GA. Questa guida illustra l'aggiornamento dei ruoli di monitoraggio e dei ruoli di operatore nei tuoi account.
## Cosa sta cambiando
1. [Le cronologie delle chat su richiesta durante l'anteprima non sono più accessibili](#on-demand-chat-history-from-public-preview)
1. [Le nuove politiche gestite sostituiscono le politiche disponibili durante l'anteprima](#new-managed-policies)
1. [Agent Spaces potrebbe avere un ambito di accesso alle applicazioni IAM Identity Center obsoleto](#reconnect-iam-identity-center-if-applicable)
## Cronologia delle chat su richiesta dall'anteprima pubblica
La versione GA introduce misure di sicurezza aggiuntive per rafforzare i controlli di accesso alle cronologie delle chat. A seguito di queste modifiche, le cronologie delle chat su richiesta del periodo di anteprima pubblica (prima del 30 marzo 2026) non sono più accessibili. I diari di indagine e i risultati creati durante l'anteprima pubblica non sono interessati. **Questa modifica si applica solo alle conversazioni in chat su richiesta.**
## Nuove politiche gestite
Per GA, AWS fornisce nuove politiche gestite che sostituiscono le politiche dell'era di anteprima:
| Tipo di ruolo | Rimuovi | Add (Aggiungi) |
| --- | --- | --- |
| Monitoraggio | Policy gestita di AIOpsAssistantPolicy | Policy gestita di AIDevOpsAgentAccessPolicy |
| Operatore (IAM e IDC) | Politica in linea | Policy gestita di AIDevOpsOperatorAppAccessPolicy |
Inoltre, i ruoli dell'operatore richiedono politiche di fiducia aggiornate e i ruoli dell'operatore IDC richiedono una nuova politica in linea.
### Prerequisiti
+ Accesso agli AWS account in cui sono configurati i ruoli di DevOps agente (account primari e tutti gli account secondari)
+ Autorizzazioni IAM per modificare ruoli, politiche e relazioni di fiducia
+ L'ID Agent Space, l'ID AWS dell'account e la regione (visibili nella console dell' DevOps agente)
### Fase 1: Aggiornare i ruoli di monitoraggio
Aggiorna il ruolo di monitoraggio nel tuo account principale e in ogni account secondario. Questi sono i ruoli di Primary/Secondary origine configurati nella scheda **Capacità** nello spazio degli agenti (esempio di primary/secondary ruolo:`DevOpsAgentRole-AgentSpace-3xj2396z`).
1. Nella console dell' DevOps agente, vai al tuo Agent Space e scegli la scheda **Funzionalità**.
1. Trova il ruolo di monitoraggio per le tue Primary/Secondary Fonti (ad esempio`DevOpsAgentRole-AgentSpace-3xj2396z`) e scegli **Modifica**.
1. In **Politiche di autorizzazione**, rimuovi la politica `AIOpsAssistantPolicy` AWS gestita.
1. Scegli **Aggiungi autorizzazioni**, **Allega politiche e allega** la politica `AIDevOpsAgentAccessPolicy` gestita.
1. Modifica la politica in linea e sostituisci il suo contenuto con quanto segue, sostituendo l'ID del tuo account:
```
{
"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. La politica di fiducia per il ruolo di monitoraggio non richiede modifiche. Verifica che corrisponda a quanto segue:
```
{
"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/*"
}
}
}
]
}
```
+ Ripeti i passaggi da 2 a 6 per il ruolo di monitoraggio in ogni account secondario.
### Fase 2: Aggiornare il ruolo dell'operatore (IAM)
1. Nella console dell' DevOps agente, scegli la scheda **Accesso** e trova il ruolo dell'operatore.
1. Nella console IAM, rimuovi la policy in linea esistente dal ruolo dell'operatore.
1. Scegli **Aggiungi autorizzazioni**, **Allega politiche e allega** la politica `AIDevOpsOperatorAppAccessPolicy` gestita.
1. Scegli la scheda **Relazioni di fiducia** e scegli **Modifica politica di fiducia**. Sostituisci la politica di fiducia con la seguente, sostituendo l'ID dell'account, la regione e l'ID di Agent Space:
```
{
"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/"
}
}
}
]
}
```
### Fase 3: Aggiornamento dei ruoli degli operatori (IDC)
Se utilizzi IAM Identity Center with DevOps Agent, aggiorna ogni ruolo di operatore IDC.
1. Nella console IAM, vai su **Ruoli e cerca per `WebappIDC` trovare i ruoli** di DevOps Agent IDC (ad esempio,`DevOpsAgentRole-WebappIDC-`).
1. Per ogni ruolo IDC:
a. Rimuovi la politica in linea esistente.
b. Scegli **Aggiungi autorizzazioni**, **Allega politiche e allega** la politica `AIDevOpsOperatorAppAccessPolicy` gestita.
c. Scegli la scheda **Relazioni di fiducia** e scegli **Modifica politica di fiducia**. Sostituisci la politica di fiducia con la seguente, sostituendo l'ID dell'account, la regione e l'ID di Agent Space:
```
{
"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. Crea una nuova politica in linea con le seguenti autorizzazioni, sostituendo l'ID del tuo account:
```
{
"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/*"
]
}
]
}
```
## Ricollega IAM Identity Center (se applicabile)
Gli Agent Spaces creati durante l'anteprima pubblica possono avere un'applicazione IAM Identity Center configurata con un ambito di accesso obsoleto. Per GA, l'ambito corretto è **`aidevops:read_write`**. Se la tua applicazione IAM Identity Center ha l'ambito precedente (**`awsaidevops:read_write`**), devi disconnettere e ricollegare IAM Identity Center.
### Come verificare l'ambito dell'applicazione IAM Identity Center
Esegui il seguente comando AWS CLI per controllare l'ambito sulla tua applicazione IAM Identity Center. **Puoi trovare l'ARN dell'applicazione nella console IAM Identity Center alla voce Applicazioni.**
```
aws sso-admin list-application-access-scopes \
--application-arn arn:aws:sso:::application//
```
L'output dovrebbe mostrare l'ambito **`aidevops:read_write`**corretto:
```
{
"Scopes": [
{
"Scope": "aidevops:read_write"
}
]
}
```
Se l'ambito viene visualizzato **`awsaidevops:read_write`**, è obsoleto. Segui i passaggi seguenti per aggiornarlo.
### Come riconnettere IAM Identity Center
L'ambito di accesso su un'applicazione IAM Identity Center AWS gestita non può essere aggiornato direttamente. È necessario disconnettersi e riconnettersi:
1. Nella console dell' AWS DevOps agente, vai al tuo Agent Space e scegli la scheda **Accesso**.
1. Scegli **Disconnect** accanto alla configurazione di IAM Identity Center.
1. Conferma la disconnessione.
1. Scegli **Connect** per configurare nuovamente IAM Identity Center. Il servizio crea una nuova applicazione IAM Identity Center con l'ambito corretto.
1. Riassegna utenti e gruppi alla nuova applicazione nella console IAM Identity Center.
**Importante**
La disconnessione rimuove la chat dei singoli utenti e la cronologia degli artefatti associati agli account utente IAM Identity Center. Gli utenti dovranno effettuare nuovamente l'accesso dopo la riconnessione.
## Verifica
Dopo aver completato tutti i passaggi:
1. Tornate alla console dell' DevOps agente e verificate che non compaiano errori di autorizzazione nella scheda Agent Space **Access**.
1. Testa l'app web dell'operatore per confermare che si carichi e funzioni correttamente.
1. Se utilizzi IDC, verifica che gli utenti possano autenticarsi e accedere all'esperienza dell'operatore.
## Risoluzione dei problemi
**Errori di autorizzazione negata dopo la migrazione**
+ Verifica che sia `AIOpsAssistantPolicy` stato rimosso e `AIDevOpsAgentAccessPolicy` sia associato ai ruoli di monitoraggio.
+ Verifica che le vecchie politiche in linea siano state rimosse e che `AIDevOpsOperatorAppAccessPolicy` siano associate ai ruoli dell'operatore.
+ Verifica che le politiche di fiducia degli operatori includano`sts:TagSession`.
+ Conferma di aver sostituito tutti i valori segnaposto (``,``,``) con valori effettivi.
**Gli account secondari non funzionano**
+ Il ruolo di monitoraggio di ogni account secondario deve essere aggiornato in modo indipendente. Accedi a ciascun account e ripeti il passaggio 1.
**Errori di autenticazione IDC**
+ Verifica che la policy di fiducia di IDC includa sia l'`sts:TagSession`istruzione`sts:AssumeRole`/che l'istruzione. `TrustedIdentityPropagation`
+ Conferma la politica in linea con `sso:ListInstances``sso:DescribeInstance`, ed `identitystore:DescribeUser` è stata creata.
**Manca la cronologia delle chat su richiesta dopo la migrazione**
+ Le cronologie delle chat su richiesta del periodo di anteprima pubblica non sono accessibili dopo il rilascio della versione GA. Questo è un comportamento previsto dovuto alle misure di sicurezza avanzate introdotte in GA. Le riviste investigative e i risultati dell'anteprima pubblica non sono interessati.
# AWS Configurazione dell'accesso EKS
Puoi consentire ad AWS DevOps Agent di esaminare i problemi nei tuoi cluster Amazon EKS eseguendo `kubectl` comandi di sola lettura su cluster pubblici e privati. Puoi connettere un numero qualsiasi di cluster EKS allo stesso Agent Space.
Una volta connesso, l'agente può aiutare a diagnosticare i problemi operativi nei cluster, descrivendo le risorse, recuperando i log dei pod, ispezionando gli eventi del cluster, controllando lo stato dei nodi e altro ancora. L'agente non può creare, modificare o eliminare alcuna risorsa nel cluster.
## Prerequisiti
Prima di configurare l'accesso EKS, assicuratevi che la modalità di autenticazione del cluster EKS includa l'API EKS. Puoi verificarlo nella scheda **Accesso** nella [console Amazon EKS](https://console.aws.amazon.com/eks). Se la modalità non include l'API EKS, seleziona una modalità che lo includa prima di procedere.
## Configurazione
Questi passaggi devono essere completati dalla [console Amazon EKS](https://console.aws.amazon.com/eks) per ogni cluster per cui desideri creare una voce di accesso. Puoi trovare l'ARN del tuo ruolo IAM nel tuo Agent Space (vedi[Creazione di uno spazio per agenti](getting-started-with-aws-devops-agent-creating-an-agent-space.md)) in **Capabilities > Cloud > Primary Source > Modifica**.
1. Vai alla scheda **Accesso**. Se la modalità di autenticazione dice già EKS API, puoi aggiungere voci di accesso. Altrimenti, seleziona una modalità che includa l'API EKS.
1. Dalla scheda Accesso, crea una nuova voce di accesso IAM. Copia l'ARN del ruolo IAM di origine cloud principale e inseriscilo come principale IAM per la voce di accesso. Fare clic su **Avanti**.
1. Seleziona la policy di AIOps AssistantPolicy accesso AWS Managed **Amazon** e seleziona **Cluster** per l'ambito di accesso. (In alternativa, se desideri che l'agente acceda solo a determinati namespace, seleziona i namespace **Kubernetes** desiderati). ****Fai clic su Aggiungi politica, quindi su Avanti.****
1. Rivedi le modifiche e conferma che sono stati scelti la politica di accesso e il ruolo IAM corretti, quindi crea la voce di accesso facendo clic su **«Crea»**.
Per verificare che l'accesso EKS sia stato configurato correttamente, accedi all'app Operator e avvia una nuova indagine, ponendo all'agente una domanda sul tuo cluster, ad esempio «elenca tutti i pod nel namespace predefinito» o «mostrami gli eventi recenti nel mio cluster».
## Risoluzione dei problemi
Se l'agente non riesce a raggiungere il tuo cluster, verifica che l'accesso utilizzi l'ARN del ruolo IAM corretto mostrato nella finestra di dialogo di configurazione e che la policy di AIOps AssistantPolicy accesso **Amazon** sia allegata.
# Connessione ad Azure
L'integrazione con Azure consente all' AWS DevOps agente di esaminare le risorse nell'ambiente Azure e di correlare le distribuzioni della DevOps pipeline di Azure con gli incidenti operativi. Connettendo Azure, l'agente ottiene visibilità sull'infrastruttura di Azure e può eseguire l'analisi della causa principale su entrambe le risorse di Azure. AWS
L'integrazione con Azure è costituita da due funzionalità indipendenti:
+ **Risorse di Azure**: consente all'agente di scoprire e analizzare le risorse cloud di Azure come macchine virtuali, cluster Azure Kubernetes Service (AKS), database e componenti di rete. L'agente usa Azure Resource Graph per interrogare le tue risorse durante le indagini sugli incidenti.
+ **Azure DevOps**: consente all'agente di accedere agli DevOps archivi di Azure e alla cronologia di esecuzione della pipeline. L'agente può correlare le modifiche e le distribuzioni del codice agli incidenti per aiutare a identificare le potenziali cause principali.
Ogni funzionalità è registrata a livello di AWS account e può quindi essere associata a singoli Agent Spaces.
## Metodi di registrazione
AWS DevOps L'agente supporta due metodi per la connessione ad Azure:
+ **Consenso dell'amministratore**: un flusso semplificato basato sul consenso in cui autorizzi l'applicazione AWS DevOps Agent Entra nel tuo tenant di Azure. **Nella console, viene visualizzata come opzione di consenso dell'amministratore.** Questo metodo richiede l'accesso con un account che dispone dell'autorizzazione per eseguire il consenso dell'amministratore in Microsoft Entra ID.
+ **Registrazione delle app**: un approccio autogestito in cui è possibile creare un'applicazione Entra personalizzata con credenziali di identità federate utilizzando Outbound Identity Federation. **Nella console, questa opzione appare come opzione di registrazione dell'app.** Questo metodo è adatto quando è necessario un maggiore controllo sulla configurazione dell'applicazione o quando le autorizzazioni di consenso dell'amministratore non sono disponibili.
Entrambi i metodi offrono le stesse funzionalità. È possibile utilizzare uno o entrambi i metodi all'interno dello stesso AWS account.
## Limiti noti
+ **Consenso dell'amministratore: un AWS account per tenant di Azure: ogni tenant** di Azure può avere la propria app AWS DevOps Agent Entra associata a un solo AWS account alla volta. Per associare lo stesso tenant a un AWS account diverso, devi prima annullare la registrazione esistente.
+ **Registrazione dell'app: applicazione unica per registrazione** — Ogni registrazione all'app deve utilizzare un'applicazione diversa (ID cliente). Non è possibile registrare più configurazioni con lo stesso ID client.
+ **Azure DevOps: accesso al codice sorgente:** l' DevOps integrazione con Azure fornisce l'accesso alla cronologia di esecuzione della pipeline indipendentemente da dove è ospitato il codice sorgente. Tuttavia, per accedere al codice sorgente effettivo, il repository deve essere connesso separatamente tramite un provider di sorgenti supportato (ad esempio,). [Connessione GitHub](connecting-to-cicd-pipelines-connecting-github.md) Il codice sorgente ospitato in Bitbucket non è accessibile direttamente tramite l'integrazione con Azure. DevOps
## Argomenti
+ [Connessione delle risorse di Azure](connecting-azure-connecting-azure-resources.md)
+ [Connessione ad Azure DevOps](connecting-azure-connecting-azure-devops.md)
# Connessione delle risorse di Azure
L'integrazione con Azure Resources consente all' AWS DevOps agente di scoprire e analizzare le risorse nelle sottoscrizioni di Azure durante le indagini sugli incidenti. L'agente usa Azure Resource Graph per l'individuazione delle risorse e può accedere a metriche, log e dati di configurazione nell'ambiente Azure.
Questa integrazione segue un processo in due fasi: registrare Azure a livello di AWS account, quindi associare sottoscrizioni Azure specifiche a singoli Agent Spaces.
## Prerequisiti
Prima di connettere Azure Resources, assicurati di avere:
+ Accesso alla console dell' AWS DevOps agente
+ Un account Azure con accesso alla sottoscrizione di destinazione
+ Per il metodo di consenso dell'amministratore: un account con l'autorizzazione a eseguire il consenso dell'amministratore in Microsoft Entra ID
+ Per il metodo di registrazione delle app: un'applicazione Entra con autorizzazioni per configurare credenziali di identità federate e [Outbound Identity Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) abilitata nell'account AWS
**Nota:** è possibile avviare la registrazione anche dall'interno di un Agent Space. Passa a **Fonti secondarie**, fai clic su **Aggiungi** e seleziona **Azure.** Se Azure Cloud non è ancora registrato, la console ti guida prima nella registrazione.
## Registrazione delle risorse di Azure tramite il consenso dell'amministratore
Il metodo Admin Consent utilizza un flusso basato sul consenso con l'applicazione gestita dall' AWS DevOps agente.
### Fase 1: Avviare la registrazione
1. Accedi alla console di AWS gestione e vai alla console dell' AWS DevOps agente
1. Vai alla pagina **Capability Provider**
1. **Individua la sezione **Azure Cloud** e fai clic su Registra**
1. Seleziona il metodo di registrazione **Admin Consent**
### Fase 2: Completa il consenso dell'amministratore
1. Verifica le autorizzazioni richieste
1. Fai clic per procedere: verrai reindirizzato alla pagina di consenso dell'amministratore di Microsoft Entra
1. Accedi con un account utente principale che dispone dell'autorizzazione a fornire il consenso dell'amministratore
1. Rivedi e concedi il consenso per l'applicazione AWS DevOps Agent
### Fase 3: Autorizzazione utente completa
1. Dopo il consenso dell'amministratore, ti viene richiesta l'autorizzazione dell'utente per verificare la tua identità come membro del tenant autorizzato
1. Accedi con un account appartenente allo stesso tenant di Azure
1. Dopo l'autorizzazione, verrai reindirizzato nuovamente alla console dell' AWS DevOps agente con lo stato di successo
### Fase 4: Assegnazione dei ruoli
Vedi [Assegnazione dei ruoli di Azure](#assigning-azure-roles) di seguito. Cerca **AWS DevOps Agent** quando selezioni i membri.
## Registrazione delle risorse di Azure tramite la registrazione dell'app
Il metodo di registrazione dell'app utilizza la tua applicazione Entra con credenziali di identità federate.
### Fase 1: Avviare la registrazione
1. Nella console dell' AWS DevOps agente, vai alla pagina **Capability Provider**
1. **Individua la sezione **Azure Cloud** e fai clic su Registra**
1. Seleziona il metodo di **registrazione dell'app**
### Fase 2: Creare e configurare l'applicazione Entra
Segui le istruzioni visualizzate nella console per:
1. Abilita Outbound Identity Federation nel tuo AWS account (nella console IAM, vai a **Impostazioni account** → **Outbound Identity** Federation)
1. Crea un'applicazione Entra nel tuo ID Microsoft Entra o usane una esistente
1. Configura le credenziali di identità federate sull'applicazione
### Fase 3: Fornire i dettagli di registrazione
Compila il modulo di registrazione con:
+ **ID tenant**: il tuo identificatore del tenant di Azure
+ Nome **tenant: un nome visualizzato** per il tenant
+ **ID client**: l'ID dell'applicazione (client) dell'applicazione Entra che hai creato
+ **Pubblico**: l'identificatore del pubblico per la credenziale federata
### Fase 4: Creare il ruolo IAM
Un ruolo IAM verrà creato automaticamente quando invii la registrazione tramite la console. Consente all' AWS DevOps agente di assumere le credenziali e di richiamare. `sts:GetWebIdentityToken`
### Fase 5: Assegnazione dei ruoli
Vedi [Assegnazione dei ruoli di Azure](#assigning-azure-roles) di seguito. Cerca l'applicazione Entra che hai creato durante la selezione dei membri.
### Fase 6: Completare la registrazione
1. Conferma la configurazione nella console AWS DevOps dell'agente
1. Fate clic su **Invia** per completare la registrazione
## Assegnazione dei ruoli di Azure
Dopo la registrazione, concedi all'applicazione l'accesso in lettura alla tua sottoscrizione di Azure. Questo passaggio è lo stesso per i metodi di consenso dell'amministratore e di registrazione dell'app.
1. Nel portale di Azure, accedi alla sottoscrizione di Target
1. Vai a **Access Control (IAM)**
1. Fai clic su **Aggiungi** > **Aggiungi assegnazione di ruolo**
1. **Seleziona il ruolo **Reader** e fai clic su Avanti**
1. Fai clic su **Seleziona membri**, cerca l'applicazione (**AWS DevOps Agent** for Admin Consent o la tua applicazione Entra per la registrazione delle app)
1. Selezionate l'applicazione e fate clic su **Review \$1 assign**
1. (Facoltativo) Per consentire all'agente di accedere ai cluster di Azure Kubernetes Service (AKS), completa la seguente configurazione di accesso AKS.
**Requisito di sicurezza:** al responsabile del servizio deve essere assegnato solo il ruolo **Reader** (e facoltativamente i ruoli di sola lettura AKS elencati di seguito). Il ruolo Reader funge da limite di sicurezza che limita l'agente alle operazioni di sola lettura e limita l'impatto degli attacchi indiretti di prompt injection. L'assegnazione di ruoli con autorizzazioni di scrittura o azione aumenta in modo significativo il raggio di risposta del prompt injection e può comportare una compromissione delle risorse di Azure. AWS DevOps L'agente esegue solo operazioni di lettura. L'agente non modifica, crea o elimina risorse di Azure.
### Configurazione dell'accesso AKS (opzionale)
#### Fase 1: accesso a livello di Azure Resource Manager (ARM)
Assegna il ruolo utente del **cluster di servizio Azure Kubernetes** all'applicazione.
Nel portale di Azure, vai a **Sottoscrizioni** → seleziona abbonamento → **Controllo di accesso (IAM)** → **Aggiungi assegnazione di ruolo → seleziona Ruolo utente del cluster di servizio Azure Kubernetes → assegna** **all'applicazione (**AWS DevOps Agent** for Admin** Consent o la tua applicazione Entra per la registrazione delle app).
Questo copre tutti i cluster AKS inclusi nell'abbonamento. Per limitarti a cluster specifici, assegnali invece a livello di gruppo di risorse o di singolo cluster.
#### Fase 2: accesso all'API Kubernetes
Scegli un'opzione in base alla configurazione di autenticazione del cluster:
**Opzione A: Azure Role-Based Access Control (RBAC) per Kubernetes (consigliato)**
1. ********Abilita Azure RBAC sul cluster se non è già abilitato: Azure Portal → AKS cluster → Impostazioni → Configurazione di sicurezza → Autenticazione e autorizzazione → seleziona Azure RBAC********
1. **Assegna un ruolo di sola lettura: Azure Portal → **Subscriptions** → seleziona abbonamento → **Access Control (IAM)** → **Aggiungi l'assegnazione del ruolo → seleziona Azure Kubernetes Service RBAC Reader → assegna** all'applicazione**
Questo copre tutti i cluster AKS nell'abbonamento.
**Opzione B: Azure Active Directory (Azure AD) \$1Kubernetes RBAC**
Usala se il tuo cluster usa già la configurazione di autenticazione predefinita di Azure AD e preferisci non abilitare Azure RBAC. Ciò richiede una configurazione per cluster. `kubectl`
1. Salva il seguente manifesto come: `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. Sostituiscilo `` con l'Object ID del responsabile del servizio. Per trovarlo: Azure Portal → Entra ID → Enterprise Applications → cerca il nome dell'applicazione (**AWS DevOps Agent** for Admin Consent o la tua applicazione Entra per la registrazione delle app).
1. Applica a ciascun cluster:
```
az aks get-credentials --resource-group --name
kubectl apply -f devops-agent-reader.yaml
```
**Nota:** i cluster che utilizzano solo account locali (senza Azure AD) non sono supportati. Ti consigliamo di abilitare l'integrazione di Azure AD nel tuo cluster per usare questa funzionalità.
### Ruolo personalizzato con privilegi minimi (opzionale)
Per un controllo più rigoroso degli accessi, puoi creare un ruolo di Azure personalizzato riservato solo ai provider di risorse utilizzati da AWS DevOps Agent, anziché il ruolo generale 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}"
]
}
```
## Associazione di una sottoscrizione a un Agent Space
Dopo aver registrato Azure a livello di account, associa sottoscrizioni specifiche ai tuoi Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. Nella sezione **Fonti secondarie**, fai clic su **Aggiungi**
1. Seleziona **Azure**
1. Fornisci l'**ID di sottoscrizione** per la sottoscrizione di Azure che desideri associare
1. Fai clic su **Aggiungi** per completare l'associazione
Puoi associare più sottoscrizioni allo stesso Agent Space per offrire all'agente visibilità nel tuo ambiente Azure.
## Gestione delle connessioni di Azure Resources
+ **Visualizzazione delle sottoscrizioni connesse**: nella scheda **Funzionalità**, la sezione **Fonti secondarie** elenca tutte le sottoscrizioni di Azure connesse.
+ **Rimozione di un abbonamento****: per disconnettere un abbonamento da un Agent Space, selezionalo nell'elenco delle **fonti secondarie** e fai clic su Rimuovi.** Ciò non influisce sulla registrazione a livello di account.
+ **Rimozione della registrazione**: per rimuovere completamente la registrazione sul cloud di Azure, vai alla pagina **Provider di capacità** ed elimina la registrazione. Tutte le associazioni di Agent Space devono prima essere rimosse.
# Connessione ad Azure DevOps
DevOps L'integrazione con Azure consente all' AWS DevOps agente di accedere agli archivi e alla cronologia di esecuzione della pipeline nella tua organizzazione Azure. DevOps L'agente può correlare le modifiche e le distribuzioni del codice con gli incidenti operativi per aiutare a identificare le potenziali cause principali.
**Nota:** le DevOps pipeline di Azure possono usare il codice sorgente di Azure Repos o Bitbucket. GitHub L' DevOps integrazione con Azure fornisce l'accesso alla cronologia di esecuzione della pipeline indipendentemente dal provider di origine. Tuttavia, per accedere al codice sorgente effettivo durante le indagini, il repository deve essere connesso separatamente tramite un'integrazione supportata come. [Connessione GitHub](connecting-to-cicd-pipelines-connecting-github.md) Il codice sorgente in Bitbucket non è direttamente accessibile tramite questa integrazione.
Questa integrazione segue un processo in due fasi: registrare Azure DevOps a livello di AWS account, quindi associare progetti specifici a singoli Agent Spaces.
## Prerequisiti
Prima di connettere Azure DevOps, assicurati di avere:
+ Accesso alla console dell' AWS DevOps agente
+ Un' DevOps organizzazione Azure con almeno un progetto contenente un repository e una cronologia della pipeline
+ Autorizzazioni per aggiungere utenti alla tua organizzazione Azure DevOps
+ Per il metodo di consenso dell'amministratore: un account con l'autorizzazione a eseguire il consenso dell'amministratore in Microsoft Entra ID
+ Per il metodo di registrazione delle app: un'applicazione Entra con autorizzazioni per configurare credenziali di identità federate e [Outbound Identity Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) abilitata nell'account AWS
**Nota:** è possibile avviare la registrazione anche dall'interno di un Agent Space. Vai alla sezione **Pipelines**, fai clic su **Aggiungi** e seleziona **Azure DevOps**. Se Azure non DevOps è ancora registrato, la console ti guida prima nella registrazione.
## Registrazione di Azure DevOps tramite il consenso dell'amministratore
Il metodo Admin Consent utilizza un flusso basato sul consenso con l'applicazione gestita dall' AWS DevOps agente.
### Fase 1: Avviare la registrazione
1. Accedi alla console di AWS gestione e vai alla console dell' AWS DevOps agente
1. Vai alla pagina **Capability Provider**
1. **Individua la DevOps sezione **Azure** e fai clic su Registra**
1. Inserisci il **nome della tua DevOps organizzazione Azure quando richiesto**
### Passaggio 2: Completa il consenso dell'amministratore
1. Fai clic per procedere: verrai reindirizzato alla pagina di consenso dell'amministratore di Microsoft Entra
1. Accedi con un account utente principale che dispone dell'autorizzazione a fornire il consenso dell'amministratore
1. Rivedi e concedi il consenso per l'applicazione AWS DevOps Agent
### Fase 3: Autorizzazione utente completa
1. Dopo il consenso dell'amministratore, ti viene richiesta l'autorizzazione dell'utente per verificare la tua identità come membro del tenant autorizzato
1. Accedi con un account appartenente allo stesso tenant di Azure
1. Dopo l'autorizzazione, verrai reindirizzato nuovamente alla console dell' AWS DevOps agente con lo stato di successo
### Passaggio 4: concedere l'accesso in Azure DevOps
Vedi [Concessione dell'accesso in Azure DevOps di seguito](#granting-access-in-azure-devops). Cerca **AWS DevOps Agent** quando aggiungi utenti.
## Registrazione di Azure DevOps tramite la registrazione dell'app
La registrazione dell'app è condivisa tra Azure Resources e Azure. DevOps [Se hai già completato la registrazione dell'app per Azure Resources, puoi passare alla sezione Concessione dell'accesso in Azure. DevOps](#granting-access-in-azure-devops)
### Passaggio 1: avviare la registrazione dell'app ADO
1. Nella console dell' AWS DevOps agente, vai alla pagina **Capability Provider**
1. **Individua la sezione **Azure Cloud** e fai clic su Registra**
1. Seleziona il metodo di **registrazione dell'app**
### Fase 2: Creare e configurare l'applicazione Entra
Segui le istruzioni visualizzate nella console per:
1. Abilita Outbound Identity Federation nel tuo AWS account (nella console IAM, vai a **Impostazioni account** → **Outbound Identity** Federation)
1. Crea un'applicazione Entra nel tuo ID Microsoft Entra o usane una esistente
1. Configura le credenziali di identità federate sull'applicazione
### Fase 3: Fornire i dettagli di registrazione
Compila il modulo di registrazione con:
+ **ID tenant**: il tuo identificatore del tenant di Azure
+ Nome **tenant: un nome visualizzato** per il tenant
+ **ID client**: l'ID dell'applicazione (client) dell'applicazione Entra
+ **Pubblico**: l'identificatore del pubblico per la credenziale federata
### Fase 4: Creare il ruolo IAM
Un ruolo IAM verrà creato automaticamente quando invii la registrazione tramite la console. Consente all' AWS DevOps agente di assumere le credenziali e di richiamare. `sts:GetWebIdentityToken`
### Fase 5: Completare la registrazione
1. Conferma la configurazione nella console AWS DevOps dell'agente
1. Fate clic su **Invia** per completare la registrazione
### Passaggio 6: concedere l'accesso in Azure DevOps
Vedi [Concessione dell'accesso in Azure DevOps di seguito](#granting-access-in-azure-devops). Cerca l'applicazione Entra che hai creato durante la registrazione dell'app quando aggiungi utenti.
## Concessione dell'accesso in Azure DevOps
Dopo la registrazione, concedi all'applicazione l'accesso alla tua organizzazione Azure DevOps . Questo passaggio è lo stesso per i metodi di consenso dell'amministratore e di registrazione dell'app.
1. In Azure DevOps, vai a **Impostazioni dell'organizzazione** > **Utenti** > **Aggiungi** utenti
1. Cerca l'applicazione (**AWS DevOps Agent** for Admin Consent o la tua applicazione Entra per la registrazione delle app)
1. Imposta il livello di accesso su **Basic**
1. In **Aggiungi ai progetti**, seleziona i progetti a cui desideri che l'agente acceda
1. In ** DevOps Gruppi di Azure**, seleziona **Project Readers**
1. Fai clic su **Aggiungi** per completare
**Requisito di sicurezza:** assegna solo il gruppo **Project Readers**. L'accesso in sola lettura funge da limite di sicurezza che limita l'agente alle operazioni di sola lettura e limita l'impatto degli attacchi indiretti di prompt injection. L'assegnazione ai gruppi di autorizzazioni di scrittura o azione aumenta in modo significativo il raggio di risposta del prompt injection e può comportare una compromissione delle risorse di Azure. DevOps
## Associazione di un progetto a un Agent Space
Dopo aver registrato Azure DevOps a livello di account, associa progetti specifici ai tuoi Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Pipeline**, fai clic su Aggiungi**
1. Seleziona **Azure DevOps** dall'elenco dei provider disponibili
1. Seleziona il progetto dal menu a discesa dei progetti disponibili
1. Fai clic su **Aggiungi** per completare l'associazione
## Gestione delle connessioni Azure DevOps
+ **Visualizzazione dei progetti connessi**: nella scheda **Capacità**, la sezione **Pipelines** elenca tutti i progetti DevOps Azure connessi.
+ **Rimozione di un progetto****: per disconnettere un progetto da un Agent Space, selezionalo nella sezione **Pipelines** e fai clic su Rimuovi.**
+ **Rimozione della registrazione**: per rimuovere completamente la DevOps registrazione di Azure, vai alla pagina **Capability Provider** ed elimina la registrazione. Tutte le associazioni di Agent Space devono prima essere rimosse.
# Connessione alle CI/CD tubazioni
L'integrazione della pipeline CI/CD consente ad AWS DevOps Agent di monitorare le implementazioni e correlare le modifiche al codice con gli incidenti operativi durante le indagini. Collegando i CI/CD provider, l'agente può tenere traccia degli eventi di implementazione e associarli a AWS risorse per aiutare a identificare le potenziali cause alla radice durante la risposta agli incidenti.
AWS DevOps Agent supporta l'integrazione con CI/CD le piattaforme più diffuse attraverso un processo in due fasi:
1. **Registrazione a livello di account**: registra il tuo CI/CD provider una volta a livello di account AWS
1. **Connessione Agent Space**: collega progetti o repository specifici a singoli Agent Spaces in base alle esigenze organizzative
Questo approccio consente di condividere le registrazioni dei CI/CD provider su più Agent Spaces mantenendo al contempo un controllo granulare su quali progetti vengono monitorati da ogni spazio.
## Fornitori supportati CI/CD
AWS DevOps Agent supporta le seguenti CI/CD piattaforme:
+ **GitHub**— Connect i repository [GitHubda.com](http://GitHub.com) utilizzando l' GitHub app AWS DevOps Agent.
+ **GitLab**— Connect progetti da [GitLab.com,](http://gitlab.com) GitLab istanze gestite o implementazioni self-hosted GitLab accessibili pubblicamente.
**Argomenti**
+ [Connessione GitHub](connecting-to-cicd-pipelines-connecting-github.md)
+ [Connessione GitLab](connecting-to-cicd-pipelines-connecting-gitlab.md)
# Connessione GitHub
GitHub l'integrazione consente all' AWS DevOps agente di accedere agli archivi di codice e ricevere eventi di implementazione durante le indagini sugli incidenti. Questa integrazione segue un processo in due fasi: registrazione a livello di account GitHub, seguita dal collegamento di repository specifici a singoli Agent Spaces.
AWS DevOps Agent supporta istanze GitHub .com (SaaS) ed GitHub Enterprise Server (ospitate autonomamente).
## Prerequisiti
Prima di connetterti GitHub, assicurati di avere:
+ Accesso alla console di amministrazione AWS DevOps dell'agente
+ Un account GitHub utente o un'organizzazione con autorizzazioni di amministratore
+ Autorizzazione a installare GitHub app nel tuo account o nella tua organizzazione
Per GitHub Enterprise Server, sono inoltre necessari:
+ Un'istanza di GitHub Enterprise Server (versione 3.x o successiva) accessibile tramite HTTPS
+ L'URL HTTPS dell'istanza di GitHub Enterprise Server (ad esempio,`https://github.example.com`)
+ (Facoltativo) Una connessione privata, se l'istanza di GitHub Enterprise Server non è accessibile pubblicamente
## Registrazione GitHub (a livello di account)
GitHub è registrato a livello di AWS account e condiviso tra tutti gli Agent Space di quell'account. È sufficiente registrarsi GitHub una sola volta per AWS account.
### Passaggio 1: accedi ai fornitori di pipeline
1. Accedi alla console di AWS gestione
1. Vai alla console dell' AWS DevOps agente
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Pipeline**, fai clic su Aggiungi**
1. Seleziona **GitHub**dall'elenco dei fornitori disponibili
Se GitHub non è ancora stato registrato, ti verrà prima richiesto di registrarlo.
### Passaggio 2: Scegli il tipo di connessione
Nella schermata «Registra GitHub account /organizzazione», seleziona se ti stai connettendo come utente o organizzazione:
+ **Utente**: il tuo GitHub account personale con nome utente e profilo
+ **Organizzazione**: un GitHub account condiviso in cui più persone possono collaborare su più progetti contemporaneamente
Se ti connetti a un'istanza di GitHub Enterprise Server, seleziona la casella di controllo **Usa GitHub Enterprise Server** e inserisci l'URL HTTPS dell'istanza (ad esempio,`https://github.example.com`).
Se l'istanza di GitHub Enterprise Server non è accessibile pubblicamente, è possibile configurare facoltativamente una connessione privata per consentire ad AWS DevOps Agent di raggiungere l'istanza in modo sicuro. Per ulteriori informazioni, consulta [Connessione a strumenti ospitati privatamente](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
**Nota**
**Non includete `/api/v3` alcun percorso finale nell'URL: immettete solo l'URL di base.
### Passaggio 3: configura l'app GitHub
Fai clic su **Invia** per iniziare il processo di configurazione dell'app. I passaggi successivi variano a seconda che ci si stia connettendo GitHub a.com o GitHub Enterprise Server.
#### Per GitHub .com
1. Verrai reindirizzato GitHub a installare l' GitHub app AWS DevOps Agent.
1. Seleziona l'account o l'organizzazione in cui installare l'app.
1. L'app consente all' AWS DevOps agente di ricevere eventi dagli archivi connessi, inclusi gli eventi di distribuzione.
#### Per GitHub Enterprise Server
GitHub Enterprise Server utilizza un flusso GitHub App Manifest, che configura automaticamente una nuova GitHub app sull'istanza. Ciò comporta due reindirizzamenti all'istanza di GitHub Enterprise Server.
1. Il browser verrà reindirizzato alla pagina «Crea GitHub app» dell'istanza GitHub Enterprise Server.
1. Verrà visualizzato il nome dell'app precompilato. Sentiti libero di cambiare il nome se necessario. Fai clic su **Crea GitHub app**.
1. Verrai reindirizzato nuovamente ad AWS DevOps Agent, che scambia il codice manifesto con le credenziali dell'app.
### Passaggio 4: Seleziona i repository e completa l'installazione
1. Verrà visualizzata la pagina di **installazione e autorizzazione** dell' GitHub app.
1. Seleziona a quali repository consentire l'accesso all'app:
+ **Tutti gli archivi**: concedi l'accesso a tutti gli archivi attuali e futuri
+ **Seleziona solo i repository: scegli repository** specifici dal tuo account o dalla tua organizzazione
1. Fai clic su **Installa e autorizza**.
1. Verrai reindirizzato nuovamente alla console dell' AWS DevOps agente, dove GitHub apparirà come registrato a livello di account.
## Connessione dei repository a un Agent Space
Dopo la registrazione GitHub a livello di account, puoi connettere repository specifici a singoli Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Pipeline**, fai clic su Aggiungi**
1. Seleziona **GitHub**dall'elenco dei fornitori disponibili
1. Seleziona il sottoinsieme di repository pertinenti a questo Agent Space
1. Fate clic su **Aggiungi** per completare la connessione
È possibile collegare diversi set di repository a diversi Agent Spaces in base alle esigenze organizzative.
## Comprendere l'app GitHub
L' GitHub app AWS DevOps Agent:
+ Richiede l'accesso in sola lettura ai tuoi repository
+ Riceve eventi di distribuzione e altri eventi del repository
+ Consente all' AWS DevOps agente di correlare le modifiche al codice con gli incidenti operativi
+ Può essere disinstallato in qualsiasi momento tramite le impostazioni GitHub
Per GitHub Enterprise Server, l' GitHub app viene creata automaticamente sull'istanza durante la registrazione. È possibile gestire l'accesso all'archivio dell'app o disinstallarla tramite **Impostazioni > Applicazioni > GitHub App installate**. Per eliminare completamente la definizione dell'app, vai a **Impostazioni > Impostazioni sviluppatore > GitHub App**.
## Gestione delle GitHub connessioni
+ **Aggiornamento dell'accesso all'archivio**: per modificare i repository a cui l' GitHub app può accedere, accedi alle impostazioni dell' GitHub account o dell'organizzazione (o alle impostazioni dell'istanza GitHub Enterprise Server), accedi alle GitHub app installate e modifica la configurazione dell'app AWS DevOps Agent.
+ **Visualizzazione degli archivi collegati**: nella console dell' AWS DevOps agente, seleziona Agent Space e vai alla scheda Funzionalità per visualizzare gli archivi collegati nella sezione Pipeline.
+ **Rimozione della GitHub connessione****: per disconnetterti GitHub da un Agent Space, seleziona la connessione nella sezione Pipeline e fai clic su Rimuovi.** Per disinstallare completamente l' GitHub app, disinstallala dalle impostazioni dell' GitHub account o dell'organizzazione. Per GitHub Enterprise Server, poiché l' GitHub app viene creata direttamente sull'istanza durante la registrazione, è possibile opzionalmente ripulire completamente l'app eseguendo entrambe le seguenti operazioni:
+ **Disinstalla l'app**: vai su **Impostazioni > Applicazioni > GitHub App installate**, fai clic su **Configura** sull'app, quindi disinstallala.
+ **Elimina l'app**: vai su **Impostazioni > Impostazioni sviluppatore > GitHub App**, seleziona l'app, vai alla scheda **Avanzate** e scegli **Elimina GitHub app**. **Avviso:** l'eliminazione dell' GitHub app è permanente e non può essere annullata. Se la elimini, dovrai registrare nuovamente GitHub Enterprise Server dall'inizio nella console di AWS DevOps Agent per creare una nuova app.
# Connessione GitLab
GitLab l'integrazione consente all' AWS DevOps agente di monitorare le implementazioni da GitLab Pipelines per fornire informazioni sulle indagini causali durante la risposta agli incidenti. Questa integrazione segue un processo in due fasi: registrazione a livello di account GitLab, seguita dal collegamento di progetti specifici a singoli Agent Spaces.
## Registrazione GitLab (a livello di account)
GitLab è registrato a livello di AWS account e condiviso tra tutti gli Agent Space di quell'account. I singoli Agent Spaces possono quindi scegliere quali progetti specifici applicare al proprio Agent Space.
### Passaggio 1: accedi ai fornitori di pipeline
1. Accedi alla console di AWS gestione
1. Vai alla console dell' AWS DevOps agente
1. Vai alla pagina **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. **Cerca **GitLab**nella sezione Provider **disponibili** sotto **Pipeline** e fai clic su Registra**
### Fase 2: Configurare GitLab la connessione
Nella pagina GitLab di registrazione, configura quanto segue:
**Tipo di connessione**: seleziona se ti stai connettendo come persona o come gruppo:
+ **Personale** (impostazione predefinita): il tuo account GitLab utente individuale con nome utente e profilo
+ **Gruppo**: in GitLab, utilizzi i gruppi per gestire uno o più progetti correlati contemporaneamente
**GitLab tipo di istanza**: scegli a quale tipo di GitLab istanza ti stai connettendo:
+ **GitLab.com** (impostazione predefinita) — Il GitLab servizio pubblico
+ **Accessibile pubblicamente, ospitato autonomamente GitLab**: seleziona la casella **Usa endpoint con hosting GitLab autonomo** e fornisci l'URL alla tua istanza GitLab
**Nota**
**Attualmente sono supportate solo le GitLab istanze accessibili al pubblico.
**Token di accesso**: fornisci un token di accesso GitLab personale:
1. In una scheda separata del browser, accedi al tuo GitLab account
1. Vai alle impostazioni utente e seleziona **Access Tokens**
1. Crea un nuovo token di accesso personale con le seguenti autorizzazioni:
+ `read_repository`— Necessario per accedere ai contenuti del repository
+ `read_virtual_registry`— Necessario per accedere alle informazioni del registro virtuale
+ `read_registry`— Necessario per accedere alle informazioni del registro
+ `api`— Richiesto per l'accesso alle API di lettura e scrittura
+ `self_rotate`- Necessario per la rotazione dei token. Questa funzionalità non è attualmente supportata da AWS DevOps Agent, ma lo sarà in un secondo momento. L'aggiunta di ora evita la necessità di creare un nuovo token in futuro.
1. Imposta la scadenza del token su un massimo di 365 giorni dalla data corrente
1. Copia il token generato
1. Torna alla console dell' AWS DevOps agente
1. Incolla il token nel campo «Token di accesso»
### Fase 3: Completa la registrazione
**(Facoltativo) Tag**: aggiungi AWS tag alla GitLab registrazione per scopi organizzativi.
Fai clic su **Avanti** per rivedere la configurazione, quindi fai clic su **Invia** per completare il processo di GitLab registrazione. Il sistema convaliderà il token di accesso e stabilirà la connessione.
## Collegamento dei progetti a un Agent Space
Dopo la registrazione GitLab a livello di account, puoi collegare progetti specifici a singoli Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Pipeline**, fai clic su Aggiungi**
1. Seleziona **GitLab**dall'elenco dei fornitori disponibili
1. Seleziona i GitLab progetti pertinenti al tuo Agent Space
1. Fai clic su **Salva**
AWS DevOps L'agente monitorerà questi progetti per individuare eventuali implementazioni da parte di GitLab Pipelines al fine di fornire informazioni sulle indagini causali.
## Gestione delle connessioni GitLab
+ **Aggiornamento del token** di accesso: se il token di accesso scade o deve essere aggiornato, puoi aggiornarlo nella console dell' AWS DevOps agente modificando la GitLab registrazione a livello di account.
+ **Visualizzazione dei progetti collegati**: nella console dell' AWS DevOps agente, seleziona Agent Space e vai alla scheda Funzionalità per visualizzare i progetti collegati nella sezione Pipeline.
+ **Rimozione della GitLab connessione****: per disconnettere GitLab i progetti da un Agent Space, seleziona la connessione nella sezione Pipeline e fai clic su Rimuovi.** Per rimuovere completamente la GitLab registrazione, rimuovila prima da tutti gli Agent Spaces, quindi elimina la registrazione a livello di account.
# Connessione dei server MCP
I server Model Context Protocol (MCP) estendono le capacità di indagine di AWS DevOps Agent fornendo l'accesso ai dati provenienti da strumenti di osservabilità esterni, sistemi di monitoraggio personalizzati e fonti di dati operative. Questa guida spiega come connettere un server MCP all'agente. AWS DevOps
## Requisiti
Prima di connettere un server MCP, assicuratevi che il server soddisfi questi requisiti:
+ Protocollo di **trasporto HTTP Streamable: sono supportati solo i server MCP che implementano il protocollo** di trasporto HTTP Streamable.
+ **Supporto per l'autenticazione**: il server MCP deve supportare i flussi di autenticazione OAuth 2.0 o l'autenticazione basata su chiavi API/token.
## Considerazioni relative alla sicurezza
Quando connetti i server MCP ad AWS DevOps Agent, considera questi aspetti di sicurezza:
+ **Elenco degli strumenti consentiti:** è consigliabile inserire nell'elenco consentito solo gli strumenti specifici necessari ad Agent Space, anziché esporre tutti gli strumenti del server MCP. Vedi [Configurazione degli strumenti MCP in un Agent Space per sapere come consentire gli strumenti di elenco per Agent Space](#configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers).
Si noti che la lunghezza massima dell'utensile MCP è 64.
+ **Rischi di iniezione rapida: i** server MCP personalizzati possono comportare un ulteriore rischio di attacchi di iniezione rapida. Per ulteriori informazioni, vedere [Prompt injection protection: AWS DevOps Agent Security](aws-devops-agent-security.md).
+ **Strumenti e accesso di sola lettura: consente solo gli strumenti** MCP di sola lettura e garantisce che alle credenziali di autenticazione sia consentito solo l'accesso in sola lettura.
[AWS DevOps Sicurezza degli agenti](aws-devops-agent-security.md)Per ulteriori informazioni sulla pronta iniezione e sul modello di responsabilità condivisa, vedere.
**Nota**
Se il server MCP si trova su una rete privata, vedere [Connessione a strumenti ospitati privatamente](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)
## Registrazione di un server MCP (a livello di account)
I server MCP sono registrati a livello di AWS account e condivisi tra tutti gli Agent Spaces di quell'account. I singoli Agent Spaces possono quindi scegliere gli strumenti specifici di cui hanno bisogno da ciascun server MCP.
### Fase 1: Dettagli del server MCP
1. Accedere alla console di AWS gestione
1. Passa alla console AWS DevOps dell'agente
1. Vai alla pagina **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. **Trova **MCP Server** nella sezione Provider **disponibili** e fai clic su Registra**
1. Nella pagina dei **dettagli del server MCP**, inserite le seguenti informazioni:
+ **Nome**: immettete un nome descrittivo per il server MCP
+ **URL dell'endpoint**: immettete l'URL HTTPS completo dell'endpoint del server MCP
+ **Descrizione** (opzionale): aggiungi una descrizione per aiutare a identificare lo scopo del server
+ **Abilita la registrazione dinamica del client**: selezionare questa casella di controllo se si desidera consentire all' AWS DevOps agente di registrarsi automaticamente sul server di autorizzazione del server MCP
1. **Fai clic su Avanti**
**Nota**
**L'URL dell'endpoint del server MCP verrà visualizzato nei AWS CloudTrail log del tuo account.
### Fase 2: Flusso di autorizzazione
Seleziona il metodo di autenticazione per il tuo server MCP:
**OAuth Credenziali client**: se il server MCP utilizza il flusso OAuth Client Credentials:
1. **Seleziona le credenziali del cliente OAuth **
1. **Fai clic su Avanti**
**OAuth 3LO (Three-Legged OAuth)**: se il server MCP utilizza OAuth 3LO per l'autenticazione:
1. **Seleziona 3LO OAuth **
1. **Fai clic su Avanti**
**Chiave API**: se il server MCP utilizza l'autenticazione tramite chiave API:
1. Seleziona la chiave **API**
1. Fai clic su **Avanti**
### Fase 3: Configurazione dell'autorizzazione
Configura parametri di autorizzazione aggiuntivi in base al metodo di autenticazione selezionato:
**Per le credenziali OAuth del client:**
1. **ID cliente**: immettere l'ID client del OAuth client
1. **Segreto** del cliente: immettere il segreto del OAuth client
1. **URL di scambio**: immettere l'URL dell'endpoint di scambio di OAuth token
1. **Parametri di Exchange**: OAuth immettete i parametri di scambio di token per l'autenticazione con il servizio
1. **Aggiungi ambito**: aggiunge OAuth ambiti per l'autenticazione
1. **Fai clic su Avanti**
**Per OAuth 3LO:**
1. **ID client**: immettere l'ID client del OAuth client
1. **Segreto** del cliente: inserisci il segreto del OAuth cliente, se richiesto dal OAuth cliente
1. **URL di Exchange**: inserisci l'URL dell'endpoint di scambio di OAuth token
1. **URL di autorizzazione**: inserisci l'URL dell'endpoint di OAuth autorizzazione
1. **Code Challenge Support**: seleziona questa casella di controllo se il tuo OAuth client supporta Code Challenge
1. **Aggiungi ambito**: aggiungi OAuth ambiti per l'autenticazione
1. **Fai clic su Avanti**
**Per API Key:**
1. Inserisci il nome di una chiave API
1. Inserisci il nome dell'intestazione che conterrà la chiave API nella richiesta
1. Inserisci il valore della tua chiave API
1. Fai clic su **Avanti**
### Fase 4: Rivedi e invia
1. Rivedi tutti i dettagli di configurazione del server MCP
1. Fate clic su **Invia** per completare la registrazione
1. AWS DevOps L'agente convaliderà la connessione al server MCP
1. Una volta completata la convalida, il server MCP verrà registrato a livello di account
## Configurazione degli strumenti MCP in un Agent Space
Dopo aver registrato un server MCP a livello di account, è possibile configurare quali strumenti di quel server sono disponibili per specifici Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Server MCP**, fai clic su Aggiungi**
1. Seleziona il server MCP registrato che desideri connettere a questo Agent Space
1. Configura quali strumenti di questo server MCP devono essere disponibili per Agent Space:
+ **Consenti tutti gli strumenti**: rende disponibili tutti gli strumenti del server MCP
+ **Seleziona strumenti specifici**: consente di scegliere quali strumenti consentire nell'elenco
1. Fate clic su **Aggiungi** per connettere il server MCP a Agent Space
AWS DevOps L'agente sarà ora in grado di utilizzare gli strumenti consentiti dal server MCP durante le indagini in questo Agent Space.
## Gestione delle connessioni al server MCP
**Aggiornamento delle credenziali** di autenticazione: se è necessario aggiornare le credenziali di autenticazione, sarà necessario registrare nuovamente il server MCP. **Passate alla pagina **Capability Provider** nella console dell' AWS DevOps agente, individuate il server MCP, rimuovete eventuali associazioni attive e fate clic su Annulla registrazione.** Successivamente, **registrate** il server MCP con le nuove credenziali di autenticazione e ricreate le associazioni necessarie con Agent Space.
**Visualizzazione dei server MCP connessi****: per vedere tutti i server MCP collegati a Agent Space, seleziona Agent Space, vai alla scheda **Funzionalità** e controlla la sezione Server MCP.** Puoi anche aggiornare gli strumenti selezionati qui.
**Rimozione delle connessioni al server MCP****: per disconnettere un server MCP da un Agent Space, selezionate il server nella sezione Server **MCP e fate clic su** Rimuovi.** Per eliminare completamente una registrazione del server MCP, rimuovila prima da tutti gli Agent Spaces, quindi elimina la registrazione a livello di account.
## Argomenti correlati
+ Sicurezza in Agent AWS DevOps
+ Configurazione di uno spazio per agenti
+ Protezione da iniezione tempestiva
# Connessione di più AWS account
AWS Gli account secondari consentono all' AWS DevOps agente di esaminare le risorse di più AWS account dell'organizzazione. Quando le applicazioni si estendono su più account, l'aggiunta di account secondari garantisce all'agente la visibilità di tutte le risorse pertinenti durante le indagini sugli incidenti. Un maggiore accesso agli account e alle risorse che compongono un'applicazione garantisce una maggiore precisione delle indagini.
## Prerequisiti
Prima di aggiungere un AWS account secondario, assicurati di avere:
+ Accesso alla console AWS DevOps dell'agente nell'account principale
+ Accesso amministrativo all' AWS account secondario
+ Autorizzazioni IAM per creare ruoli nell'account secondario
## Aggiungere un account secondario AWS
Oltre ai passaggi seguenti, puoi utilizzare il [AWS DevOps Guida all'onboarding CLI per agenti](getting-started-with-aws-devops-agent-cli-onboarding-guide.md) per aggiungere account secondari a livello di codice.
### Passaggio 1: avviare la configurazione dell'account secondario
1. Accedi alla console di AWS gestione e vai alla console dell' AWS DevOps agente
1. Seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. Nella sezione **Cloud**, individua la sottosezione **Fonti secondarie**
1. **Fai clic su Aggiungi**
### Fase 2: Specificare il nome del ruolo
1. Nel campo Dai un **nome al tuo ruolo**, inserisci un nome per il ruolo che creerai nell'account secondario
1. Nota questo nome: lo utilizzerai nuovamente quando creerai il ruolo nell'account secondario
1. Copia la policy di attendibilità fornita nella console e salvala in uno spazio virtuale
### Fase 3: Creare il ruolo nell'account secondario
1. Apri una nuova scheda del browser e accedi alla console IAM nell' AWS account secondario
1. Vai a **IAM >** **Ruoli** > **Crea ruolo**
1. Seleziona **Politica di fiducia personalizzata**
1. Incolla la politica di fiducia che hai copiato dal passaggio 2
1. **Fai clic su Avanti**
### Fase 4: Allega la policy AWS gestita
1. Nella sezione **Politiche di autorizzazione**, cerca **AIOpsAssistantPolicy**
1. Seleziona la casella di controllo accanto alla politica gestita **AIOpsAssistantPolicy**
1. **Fai clic su Avanti**
### Fase 5: Assegna un nome e crea il ruolo
1. Nel campo **Nome ruolo**, inserisci lo stesso nome di ruolo fornito nel passaggio 2
1. (Facoltativo) Aggiungi una descrizione per identificare lo scopo del ruolo
1. Rivedi la politica di attendibilità e le autorizzazioni allegate
1. Fai clic su **Crea ruolo**
### Passaggio 6: allega la politica in linea
1. Nella console IAM, individua e seleziona il ruolo che hai appena creato
1. Vai alla scheda **Autorizzazioni**
1. Fai clic su **Aggiungi autorizzazioni** > **Crea** politica in linea
1. **Passa alla scheda JSON**
1. Incolla la politica che hai salvato nel passaggio 2
1. Incolla la policy nell'editor JSON nella console IAM
1. **Fai clic su Avanti**
1. Fornisci un nome per la politica in linea (ad esempio, "DevOpsAgentInlinePolicy«)
1. Fai clic su **Crea politica**
### Fase 7: Completare la configurazione
1. Torna alla console AWS DevOps dell'agente nell'account principale
1. Fai clic su **Avanti** per completare la configurazione dell'account secondario
1. Verifica che lo stato della connessione sia impostato su **Attivo**
## Comprensione delle politiche richieste
AWS DevOps L'agente richiede tre componenti di policy per accedere alle risorse in un account secondario:
+ **Politica di fiducia**: consente all' AWS DevOps agente dell'account principale di assumere il ruolo nell'account secondario. Ciò stabilisce la relazione di fiducia tra gli account.
+ **AIOpsAssistantPolicy (policy AWS gestita)**: fornisce le autorizzazioni di base di sola lettura necessarie all' AWS DevOps agente per esaminare le risorse nell'account secondario. Questa politica viene gestita AWS e aggiornata man mano che vengono aggiunte nuove funzionalità.
+ **Policy in linea**: fornisce autorizzazioni aggiuntive specifiche per la configurazione di Agent Space. Questa policy viene generata in base alle impostazioni di Agent Space e può includere autorizzazioni per integrazioni o funzionalità specifiche.
Nell'account primario, il ruolo AWS DevOps Agent IAM deve essere in grado di assumere il ruolo creato nell'account secondario.
## Gestione degli account secondari
+ **Visualizzazione degli account connessi**: nella scheda **Funzionalità**, la sottosezione **Fonti secondarie** elenca tutti gli account secondari collegati con il relativo stato di connessione.
+ **Aggiornamento del ruolo IAM**: se devi modificare le autorizzazioni, aggiorna la policy in linea allegata al ruolo nell'account secondario. Le modifiche diventano effettive immediatamente.
+ **Rimuovere un account secondario****: per disconnettere un account secondario, selezionalo nell'elenco **Fonti secondarie** e fai clic su Rimuovi.** Ciò non elimina il ruolo IAM nell'account secondario.
# Connessione delle fonti di telemetria
AWS DevOps Agent offre tre modi per connettersi alle fonti di telemetria.
## Integrazione bidirezionale integrata
Attualmente, AWS DevOps Agent supporta gli utenti Dynatrace con un'integrazione bidirezionale integrata che consente quanto segue:
+ **Mappatura delle risorse topologiche: AWS DevOps Agent amplierà la topologia** DevOps Agent Space con entità e relazioni disponibili tramite un server MCP Dynatrace ospitato da un agente. AWS DevOps
+ **Attivazione automatica delle indagini: i flussi di lavoro di Dynatrace possono essere configurati per attivare le** indagini sulla risoluzione degli incidenti di Dynatrace Problems.
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di Dynatrace mentre indaga su un problema tramite il server MCP Dynatrace ospitato dall'agente. AWS DevOps
+ **Aggiornamenti sullo stato**: l' AWS DevOps agente pubblicherà i risultati delle indagini chiave, le analisi delle cause principali e i piani di mitigazione generati sull'interfaccia utente di Dynatrace.
Per ulteriori informazioni sulle integrazioni bidirezionali, consulta
+ [Connessione di Dynatrace](connecting-telemetry-sources-connecting-dynatrace.md)
## Integrazione unidirezionale integrata
Attualmente, AWS DevOps Agent supporta utenti Datadog AWS CloudWatch, Grafana, New Relic e Splunk con integrazioni unidirezionali integrate.
**Best practice di sicurezza:** quando si configurano le credenziali per le integrazioni unidirezionali integrate, consigliamo di utilizzare chiavi e token API per l'accesso in sola lettura. AWS DevOps L'agente utilizza queste credenziali solo per l'introspezione telemetrica e non richiede l'accesso in scrittura al provider di telemetria.
L'integrazione AWS CloudWatch unidirezionale integrata non richiede alcuna configurazione aggiuntiva e consente quanto segue:
+ **Mappatura delle risorse topologiche**: AWS DevOps Agent amplierà la topologia di DevOps Agent Space con entità e relazioni disponibili tramite gli account cloud primari e secondari configurati. AWS
+ Introspezione **telemetrica: l' AWS DevOps agente può eseguire l'introspezione** della AWS CloudWatch telemetria mentre indaga su un problema tramite i ruoli IAM forniti durante la configurazione dell'account cloud primario e secondario. AWS
Le integrazioni unidirezionali integrate Datadog, Grafana, New Relic e Splunk richiedono la configurazione e l'abilitazione di quanto segue:
+ **Attivazione automatica delle indagini**: gli eventi Datadog, Grafana, New Relic e Splunk possono essere configurati per attivare le indagini sulla risoluzione degli incidenti degli agenti tramite i webhook degli AWS DevOps agenti. AWS DevOps
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di Datadog, Grafana, New Relic e Splunk mentre indaga su un problema tramite il server MCP remoto di ciascun provider.
Per ulteriori informazioni sulle integrazioni unidirezionali, consulta quanto segue:
+ [Connessione DataDog](connecting-telemetry-sources-connecting-datadog.md)
+ [Collegamento a Grafana](connecting-telemetry-sources-connecting-grafana.md)
+ [Collegamento di New Relic](connecting-telemetry-sources-connecting-new-relic.md)
+ [Connessione a Splunk](connecting-telemetry-sources-connecting-splunk.md)
## Bring-your-own fonti di telemetria
Per qualsiasi altra fonte di telemetria, incluse le metriche di Prometheus, puoi sfruttare AWS DevOps il supporto di Agent per l'integrazione di webhook e server MCP.
bring-your-ownPer ulteriori informazioni sulle integrazioni, consulta quanto segue
+ [Richiamo DevOps dell'agente tramite Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
+ [Connessione dei server MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
# Connessione di Dynatrace
## Integrazione bidirezionale integrata
Attualmente, AWS DevOps Agent supporta gli utenti Dynatrace con un'integrazione bidirezionale integrata che consente quanto segue:
+ **Mappatura delle risorse topologiche**: AWS DevOps Agent amplierà la topologia DevOps Agent Space con entità e relazioni disponibili dall'ambiente Dynatrace.
+ **Attivazione automatica delle indagini: i flussi di lavoro di** Dynatrace possono essere configurati per attivare le indagini sulla risoluzione degli incidenti di Dynatrace Problems.
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di Dynatrace mentre indaga su un problema tramite il server MCP Dynatrace ospitato dall'agente. AWS DevOps
+ **Aggiornamenti sullo stato**: l' AWS DevOps agente pubblicherà i risultati delle indagini chiave, le analisi delle cause principali e i piani di mitigazione generati sull'interfaccia utente di Dynatrace.
## Onboarding
### Processo di onboarding
L'onboarding del sistema di osservabilità Dynatrace prevede tre fasi:
1. **Connect** - Stabilisci la connessione a Dynatrace configurando le credenziali di accesso all'account, con tutti gli ambienti di cui potresti aver bisogno
1. **Abilita**: attiva Dynatrace in spazi Agent specifici con ambienti Dynatrace specifici
1. **Configura il tuo ambiente Dynatrace**: scarica i flussi di lavoro e la dashboard e importali in Dynatrace, prendendo nota dei dettagli del webhook per avviare le indagini negli appositi spazi Agent
### Fase 1: Connect
Stabilisci la connessione al tuo ambiente Dynatrace
#### Configurazione
1. Vai alla pagina dei **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. **Trova **Dynatrace** nella sezione Provider **disponibili** sotto **Telemetria** e fai clic su Registra**
1. **Crea OAuth client in Dynatrace, con le autorizzazioni dettagliate.**
1. [Vedi la documentazione di Dynatrace](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)
1. Quando sei pronto, premi Avanti
1. Puoi connettere più ambienti Dynatrace e, successivamente, definire quelli specifici per ogni DevOps Agent Space di cui disponi.
1. Inserisci i tuoi dati Dynatrace dalla configurazione del client: OAuth
+ **Nome del cliente**
+ **ID cliente**
+ **Segreto del cliente**
+ **URN dell'account**
1. Fai clic su Avanti
1. Rivedi e aggiungi
### Fase 2: Abilita
Attiva Dynatrace in uno spazio agente specifico e configura l'ambito appropriato
#### Configurazione
1. Dalla pagina degli spazi per gli agenti, seleziona uno spazio agente e premi Visualizza dettagli
1. Seleziona la scheda Funzionalità
1. Individua la sezione Telemetria, premi Aggiungi
1. Noterai che Dynatrace ha lo stato «Registrato». Fai clic su Aggiungi per aggiungerlo al tuo spazio agente
1. ID ambiente Dynatrace: fornisci l'ID dell'ambiente Dynatrace che desideri associare a questo spazio agente. DevOps
1. Inserisci una o più entità Dynatrace IDs : queste aiutano l' DevOps agente a scoprire le tue risorse più importanti, ad esempio servizi o applicazioni. **Se non sei sicuro puoi premere rimuovi.**
1. Rivedi e premi Salva
1. Copia l'URL del Webhook e il Webhook Secret. Consulta la [documentazione di Dynatrace per aggiungere queste credenziali](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent) a Dynatrace.
### Fase 3: Configura il tuo ambiente Dynatrace
Per completare la configurazione di Dynatrace è necessario eseguire alcuni passaggi di configurazione nell'ambiente Dynatrace. [Segui le istruzioni nella documentazione di Dynatrace.](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)
#### Schemi di eventi supportati
AWS DevOps L'agente supporta due tipi di eventi di Dynatrace tramite webhook. Gli schemi di eventi supportati sono documentati di seguito:
##### Evento incidente
Gli eventi imprevisti vengono utilizzati per avviare un'indagine. Lo schema degli eventi è:
```
{
"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 di mitigazione
Gli eventi di mitigazione vengono utilizzati per attivare la generazione di un rapporto di mitigazione per l'indagine sulle fasi successive. Lo schema degli eventi è:
```
{
"task_id": string;
"task_version": number;
"event.type": "mitigation_request";
}
```
## Rimozione
La fonte di telemetria è connessa a due livelli a livello di spazio dell'agente e a livello di account. Per rimuoverla completamente, è necessario prima rimuoverla da tutti gli spazi dell'agente in cui viene utilizzata, dopodiché può essere annullata la registrazione.
### Fase 1: Rimuovi dallo spazio dell'agente
1. Dalla pagina degli spazi per gli agenti, seleziona uno spazio agente e premi Visualizza dettagli
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Seleziona Dynatrace
1. Premi rimuovi
### Fase 2: Annullare la registrazione dall'account
1. Vai alla pagina dei **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. Scorri fino alla sezione **Attualmente registrato**.
1. Verifica che il numero di spazi per gli agenti sia pari a zero (in caso contrario, ripeti il passaggio 1 precedente negli altri spazi riservati agli agenti)
1. Premi Annulla registrazione accanto a Dynatrace
# Connessione DataDog
## Integrazione unidirezionale integrata
Attualmente, AWS DevOps Agent supporta gli utenti Datadog con un'integrazione unidirezionale integrata, che consente quanto segue:
+ **Attivazione automatica delle indagini**: gli eventi Datadog possono essere configurati per attivare le indagini sulla risoluzione degli incidenti degli agenti tramite i AWS DevOps webhook degli agenti. AWS DevOps
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di Datadog mentre analizza un problema tramite il server MCP remoto di ciascun provider.
## Onboarding
### Fase 1: Connect
Stabilisci la connessione all'endpoint MCP remoto Datadog con le credenziali di accesso all'account
#### Configurazione
1. Vai alla pagina **Capability Provider** (accessibile dalla navigazione laterale)
1. **Trova **Datadog** nella sezione Provider **disponibili** in **Telemetria** e fai clic su Registra**
1. Inserisci i dettagli del tuo server Datadog MCP:
+ **Nome del server**: identificatore univoco (ad es.) my-datadog-server
+ **URL dell'endpoint: l'**endpoint del server Datadog MCP. L'URL dell'endpoint varia a seconda del sito Datadog. Consulta la tabella degli endpoint del sito Datadog di seguito.
+ **Descrizione: descrizione opzionale del** server
1. Fai clic su Avanti
1. Verifica e invia
#### Endpoint del sito Datadog
L'URL dell'endpoint MCP varia a seconda del sito Datadog. [Per identificare il tuo sito, controlla l'URL nel tuo browser quando accedi a Datadog, oppure consulta Accedi al sito Datadog.](https://docs.datadoghq.com/getting_started/site/#access-the-datadog-site)
| Sito Datadog | Dominio del sito | URL dell'endpoint MCP |
| --- | --- | --- |
| US1 (impostazione predefinita) | 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 |
#### Autorizzazione
OAuth Autorizzazione completa tramite:
+ Autorizzazione come utente sulla pagina Datadog OAuth
+ Se non hai effettuato l'accesso, fai clic su Consenti, accedi, quindi autorizza
Una volta configurato, Datadog diventa disponibile in tutti gli spazi dell'agente.
### Fase 2: Abilita
DataDog Effettua l'attivazione in uno spazio specifico dell'agente e configura l'ambito appropriato
#### Configurazione
1. Dalla pagina degli spazi per agenti, seleziona uno spazio agente e premi Visualizza dettagli (se non hai ancora creato uno spazio agente, consulta[Creazione di uno spazio per agenti](getting-started-with-aws-devops-agent-creating-an-agent-space.md))
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Premi Aggiungi
1. Seleziona Datadog
1. Next
1. Rivedi e premi Salva
1. Copia l'URL del Webhook e la chiave API
### Fase 3: Configurare i webhook
Utilizzando l'URL e la chiave API del Webhook, puoi configurare Datadog per inviare eventi per avviare un'indagine, ad esempio da un allarme.
Per garantire che gli eventi inviati possano essere utilizzati dall' DevOps agente, assicurati che i dati trasmessi al webhook corrispondano allo schema di dati specificato di seguito. Gli eventi che non corrispondono a questo schema possono essere ignorati dall' DevOps agente.
Imposta il metodo e le intestazioni
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Invia il corpo come stringa 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;
}
```
Invia webhook con Datadog [https://docs.datadoghq.com/integrations/webhooks/](https://docs.datadoghq.com/integrations/webhooks/) (nota: seleziona nessuna autorizzazione e utilizza invece l'opzione di intestazione personalizzata).
Per saperne di [più: Datadog Remote MCP](https://www.datadoghq.com/blog/datadog-remote-mcp-server/) Server
## Rimozione
La fonte di telemetria è connessa a due livelli a livello di spazio dell'agente e a livello di account. Per rimuoverla completamente, è necessario prima rimuoverla da tutti gli spazi dell'agente in cui viene utilizzata, dopodiché può essere annullata la registrazione.
### Fase 1: Rimuovi dallo spazio dell'agente
1. Dalla pagina degli spazi per gli agenti, seleziona uno spazio agente e premi Visualizza dettagli
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Seleziona Datadog
1. Premi rimuovi
### Fase 2: Annullare la registrazione dall'account
1. Vai alla pagina dei **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. Scorri fino alla sezione **Attualmente registrato**.
1. Verifica che il numero di spazi per gli agenti sia pari a zero (in caso contrario, ripeti il passaggio 1 precedente negli altri spazi riservati agli agenti)
1. Premi Annulla registrazione accanto a Datadog
# Collegamento a Grafana
L'integrazione con Grafana consente all' AWS DevOps agente di interrogare metriche, dashboard e dati di avviso dall'istanza Grafana durante le indagini sugli incidenti. Questa integrazione segue un processo in due fasi: registrazione a livello di account di Grafana, seguita dal collegamento a singoli Agent Spaces.
Per migliorare la sicurezza, l'integrazione Grafana abilita solo strumenti di sola lettura. Gli strumenti di scrittura sono disabilitati e non possono essere abilitati. Ciò significa che l'agente può interrogare e leggere i dati dall'istanza Grafana ma non può creare, modificare o eliminare alcuna risorsa Grafana come dashboard, avvisi o annotazioni. [Per ulteriori informazioni, consulta Security in Agent. AWS DevOps ](https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html)
## Requisiti Grafana
Prima di collegare Grafana, assicurati di avere:
+ Grafana versione 9.0 o successiva. Alcune funzionalità, in particolare le operazioni relative alle origini dati, potrebbero non funzionare correttamente con le versioni precedenti a causa della mancanza degli endpoint API.
+ Un'istanza Grafana accessibile tramite HTTPS. Sono supportati sia gli endpoint di rete pubblici che quelli privati. Con la connettività di rete privata, l'istanza Grafana può essere ospitata all'interno di un VPC senza accesso pubblico a Internet. Per informazioni dettagliate, vedi [Connessione a strumenti ospitati privatamente](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
+ Un account di servizio Grafana con un token di accesso con autorizzazioni di lettura appropriate
## Registrazione di Grafana (a livello di account)
Grafana è registrata a livello di AWS account e condivisa tra tutti gli Agent Spaces di quell'account.
### Fase 1: Configurare Grafana
1. Accedi alla console di AWS gestione
1. Passa alla console AWS DevOps dell'agente
1. Vai alla pagina **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. **Trova **Grafana** nella sezione Provider **disponibili** in **Telemetria** e fai clic su Registra**
1. Nella pagina **Configura Grafana**, inserisci le seguenti informazioni:
+ **Nome servizio** (obbligatorio): inserisci un nome descrittivo per il tuo server Grafana utilizzando solo caratteri alfanumerici, trattini e caratteri di sottolineatura. Ad esempio, `my-grafana-server`.
+ **URL Grafana** (obbligatorio): inserisci l'URL HTTPS completo dell'istanza Grafana. Ad esempio, `https://myinstance.grafana.net`.
+ **Token di accesso all'account di servizio** (obbligatorio): immettere un token di accesso all'account di servizio Grafana. I token in genere iniziano con. `glsa_` Per creare un token di account di servizio, accedi alla tua istanza Grafana, vai su **Amministrazione > Account di servizio, crea un account** di servizio con il ruolo Viewer e genera un token.
+ **Descrizione** (opzionale): aggiungi una descrizione per identificare lo scopo del server. Ad esempio, `Production Grafana server for monitoring`.
1. (Facoltativo) Aggiungi AWS tag alla registrazione per scopi organizzativi.
1. Fai clic su **Avanti**
### Fase 2: Rivedi e invia la registrazione Grafana
1. Rivedi tutti i dettagli della configurazione Grafana
1. Fai clic su **Invia** per completare la registrazione
1. Una volta completata la registrazione, Grafana appare nella sezione **Attualmente registrato** della pagina Provider di capacità
## Aggiungere Grafana a uno spazio per agenti
Dopo aver registrato Grafana a livello di account, puoi collegarlo a singoli Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Telemetria**, fai clic su Aggiungi**
1. Seleziona **Grafana** dall'elenco dei fornitori disponibili
1. **Fai clic su Salva**
## Configurazione dei webhook di avvisi Grafana
È possibile configurare Grafana per attivare automaticamente le indagini degli AWS DevOps agenti quando vengono attivati gli avvisi inviando webhook tramite i punti di contatto Grafana. Per i dettagli sui metodi di autenticazione dei webhook e sulla gestione delle credenziali, consulta. [Richiamo DevOps dell'agente tramite Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
### Fase 1: Creare un modello di notifica personalizzato
Nella tua istanza Grafana, vai su **Avvisi > Punti di contatto > Modelli di notifica** e crea un nuovo modello con il seguente contenuto:
```
{{ 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 }}
```
Questo modello formatta gli avvisi Grafana nella struttura di payload del webhook prevista dall'agente. AWS DevOps Mappa le etichette degli avvisi, le annotazioni e lo stato nei campi appropriati e include tutte le etichette di avviso come metadati.
**Nota:** questo modello elabora solo il primo avviso di un gruppo. Grafana raggruppa più avvisi di attivazione in un'unica notifica per impostazione predefinita. Per garantire che ogni avviso venga inviato singolarmente, configura le politiche di notifica in modo che vengano raggruppate per. `alertname` Inoltre, questo modello non sfugge ai caratteri JSON speciali nei valori delle etichette o nelle annotazioni. Assicurati che le etichette degli avvisi e l'`summary`annotazione non contengano caratteri come virgolette o nuove righe, che produrrebbero un codice JSON non valido.
### Fase 2: Creare un punto di contatto webhook
1. **In Grafana, vai su **Avvisi > Punti di contatto** e fai clic su Aggiungi punto di contatto**
1. Seleziona **Webhook come tipo** di integrazione
1. Imposta l'**URL sull'**endpoint AWS DevOps webhook dell'agente
1. In **Impostazioni opzionali del Webhook**, configura le intestazioni di autenticazione in base al tipo di webhook. Per i dettagli, consulta [Metodi di autenticazione Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md).
1. Imposta il campo **Messaggio** per utilizzare il tuo modello personalizzato: `{{ template "devops-agent-payload" . }}`
1. Fai clic su **Salva punto di contatto**
### Passaggio 3: assegna il punto di contatto a una politica di notifica
1. Passa a **Avvisi > Politiche di notifica**
1. Modifica una politica esistente o creane una nuova
1. Imposta il punto di contatto sul punto di contatto webhook che hai creato
1. Fai clic su **Salva politica**
Quando viene attivato un avviso corrispondente, Grafana invierà il payload formattato AWS DevOps all'agente, che avvierà automaticamente un'indagine.
## Limitazioni
+ ClickHouse strumenti per l'**origine dei dati: gli strumenti per** l'origine ClickHouse dei dati non sono attualmente supportati.
+ **Prevenzione proattiva degli incidenti**: attualmente [Prevenzione proattiva degli incidenti](working-with-devops-agent-proactive-incident-prevention.md) non utilizza gli strumenti Grafana. Il supporto è previsto per le future release.
### Considerazioni su Amazon Managed Grafana
Se utilizzi [Amazon Managed Grafana](https://aws.amazon.com/grafana/) (AMG), tieni presente le seguenti limitazioni:
+ **I punti di contatto Webhook non sono supportati**: attualmente AMG non supporta i punti di contatto webhook nella sua configurazione di avviso. Non è possibile utilizzare AMG per inviare webhook di avviso direttamente all'agente. AWS DevOps Per i dettagli, consulta [Avvisare i punti di contatto in Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/v9-alerting-explore-contacts.html).
+ **Scadenza del token dell'account di servizio**: i token dell'account di servizio AMG hanno una scadenza massima di 30 giorni. Dovrai ruotare i token e aggiornare la tua registrazione Grafana in AWS DevOps Agent prima che scadano. Vedi [Gestione delle connessioni Grafana](#managing-grafana-connections) per sapere come aggiornare le credenziali. Per dettagli sui limiti dei token AMG, consulta [Account di servizio in Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/service-accounts.html).
## Gestione delle connessioni Grafana
+ **Aggiornamento delle credenziali**: se il token del tuo account di servizio scade o deve essere aggiornato, annulla la registrazione di Grafana dalla pagina Capability Provider e registrati nuovamente con il nuovo token.
+ **Visualizzazione delle istanze connesse**: nella console dell' AWS DevOps agente, seleziona Agent Space e vai alla scheda Funzionalità per visualizzare le fonti di telemetria connesse.
+ **Rimuovere Grafana** **— Per disconnettere Grafana da un Agent Space, selezionalo nella sezione Telemetria e fai clic su Rimuovi.** Per rimuovere completamente la registrazione, rimuovila prima da tutti gli Agent Spaces, quindi annulla la registrazione dalla pagina Capability Providers.
# Collegamento di New Relic
## Integrazione unidirezionale integrata
Attualmente, AWS DevOps Agent supporta gli utenti di New Relic con un'integrazione unidirezionale integrata, che consente quanto segue:
+ **Attivazione automatica delle indagini**: gli eventi New Relic possono essere configurati per attivare le indagini sulla risoluzione degli incidenti degli AWS DevOps agenti tramite i webhook degli agenti. AWS DevOps
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di New Relic mentre analizza un problema tramite il server MCP remoto di ciascun provider.
## Onboarding
### Fase 1: Connect
Stabilisci la connessione all'endpoint MCP remoto New Relic con le credenziali di accesso all'account
Utilizza un utente completo della piattaforma (non Basic/Core) in New relic per abilitare gli strumenti MCP di New Relic.
#### Configurazione
1. Vai alla pagina **Capability Provider** (accessibile dalla navigazione laterale)
1. **Trovate **New Relic** nella sezione Provider **disponibili** in **Telemetria** e fate clic su Registra**
1. Segui le istruzioni per ottenere la tua chiave API New Relic
1. Inserisci i dettagli della chiave API del server MCP New Relic:
+ **ID account:** inserisci l'ID del tuo account New Relic ottenuto sopra
+ **Chiave API:** inserisci la chiave API ottenuta sopra
+ **Seleziona la regione degli Stati Uniti o dell'UE** in base a dove si trova il tuo account New Relic.
1. Fai clic su Aggiungi
### Fase 2: Abilita
Attiva New Relic in uno spazio agente specifico e configura l'ambito appropriato
#### Configurazione
1. Dalla pagina Agent Space, selezionate uno spazio agente e premete Visualizza dettagli (se non avete ancora creato uno spazio agente, consultate) [Creazione di uno spazio per agenti](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Premi Aggiungi
1. Seleziona New Relic
1. Next
1. Rivedi e premi Salva
1. Copia l'URL del Webhook e la chiave API
### Fase 3: Configurare i webhook
Utilizzando l'URL e la chiave API del Webhook, puoi configurare New Relic in modo che invii eventi per avviare un'indagine, ad esempio a seguito di un allarme. [Per maggiori dettagli sulla configurazione dei webhook, consulta Change tracking webhook.](https://docs.newrelic.com/docs/change-tracking/change-tracking-webhooks/)
Per garantire che gli eventi inviati possano essere utilizzati dall' DevOps agente, assicurati che i dati trasmessi al webhook corrispondano allo schema di dati specificato di seguito. Gli eventi che non corrispondono a questo schema possono essere ignorati dall' DevOps agente.
Imposta il metodo e le intestazioni
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Invia il corpo come stringa 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;
}
```
[Invia webhook con le notifiche dei webhook di New Relic. https://newrelic.com/instant-observability/](https://newrelic.com/instant-observability/webhook-notifications) Puoi selezionare il token Bearer per il tipo di autorizzazione oppure selezionare nessuna autorizzazione e aggiungerlo invece come intestazione personalizzata. `Authorization: Bearer `
Per saperne di più: [https://docs.newrelic.com/docs/agentic-/ai/mcp/overview](https://docs.newrelic.com/docs/agentic-ai/mcp/overview/)
## Rimozione
La fonte di telemetria è connessa a due livelli a livello di spazio dell'agente e a livello di account. Per rimuoverla completamente, è necessario prima rimuoverla da tutti gli spazi dell'agente in cui viene utilizzata, dopodiché può essere annullata la registrazione.
### Fase 1: Rimuovi dallo spazio dell'agente
1. Dalla pagina degli spazi per gli agenti, seleziona uno spazio agente e premi Visualizza dettagli
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Seleziona New Relic
1. Premi rimuovi
### Fase 2: Annullare la registrazione dall'account
1. Vai alla pagina dei **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. Scorri fino alla sezione **Attualmente registrato**.
1. Verifica che il numero di spazi per gli agenti sia pari a zero (in caso contrario, ripeti il passaggio 1 precedente negli altri spazi riservati agli agenti)
1. Premi Annulla registrazione accanto a New Relic
# Connessione a Splunk
## Integrazione unidirezionale integrata
Attualmente, AWS DevOps Agent supporta gli utenti Splunk con un'integrazione unidirezionale integrata, che consente quanto segue:
+ **Attivazione automatica delle indagini**: gli eventi Splunk possono essere configurati per attivare le indagini sulla risoluzione degli incidenti degli AWS DevOps agenti tramite i webhook degli agenti. AWS DevOps
+ **Introspezione telemetrica: l' AWS DevOps agente può analizzare la telemetria** di Splunk mentre analizza un problema tramite il server MCP remoto di ciascun provider.
## Prerequisiti
### Ottenere un token API Splunk
Avrai bisogno di un URL e di un token MCP per connettere Splunk.
### Procedura dell'amministratore di Splunk
L'amministratore Splunk deve eseguire le seguenti operazioni:
+ abilitare l'accesso all'[API REST](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ [abilita l'autenticazione tramite 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) sulla distribuzione.
+ crea un nuovo ruolo 'mcp\$1user', il nuovo ruolo non deve avere alcuna funzionalità.
+ assegna il ruolo 'mcp\$1user' a tutti gli utenti della distribuzione autorizzati a utilizzare il server MCP.
+ crea il token per gli utenti autorizzati con audience come 'mcp' e imposta la scadenza appropriata, se l'utente non ha l'autorizzazione per creare i token da solo.
### Procedure per utenti Splunk
Un utente Splunk deve eseguire i seguenti passaggi:
+ Ottieni un token appropriato dall'amministratore Splunk o creane uno lui stesso, se ne ha l'autorizzazione. Il pubblico del token deve essere 'mcp'.
## Onboarding
### Fase 1: Connect
Stabilisci la connessione all'endpoint MCP remoto Splunk con le credenziali di accesso all'account
#### Configurazione
1. Vai alla pagina **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. **Trova **Splunk** nella sezione Provider **disponibili** sotto **Telemetria** e clicca su Registra**
1. Inserisci i dettagli del tuo server MCP Splunk:
+ **Nome del server**: identificatore univoco (ad es.) my-splunk-server
+ **URL dell'endpoint - L'**endpoint del server Splunk MCP:
`https://.api.scs.splunk.com//mcp/v1/`
+ **Descrizione: descrizione opzionale del server**
+ **Nome token**: il nome del token portatore per l'autenticazione: `my-splunk-token`
+ Valore del **token Il valore** del token portatore per l'autenticazione
### Fase 2: Abilita
Attiva Splunk in uno spazio specifico dell'agente e configura l'ambito appropriato
#### Configurazione
1. Dalla pagina Agent Space, seleziona uno spazio agente e premi Visualizza dettagli (se non hai ancora creato uno spazio agente, consulta) [Creazione di uno spazio per agenti](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Premi Aggiungi
1. Seleziona Splunk
1. Next
1. Rivedi e premi Salva
1. Copia l'URL del Webhook e la chiave API
### Fase 3: Configurare i webhook
Utilizzando l'URL e la chiave API del Webhook, puoi configurare Splunk per inviare eventi per avviare un'indagine, ad esempio a partire da un allarme.
Per garantire che gli eventi inviati possano essere utilizzati dall' DevOps agente, assicurati che i dati trasmessi al webhook corrispondano allo schema di dati specificato di seguito. Gli eventi che non corrispondono a questo schema possono essere ignorati dall' DevOps agente.
Imposta il metodo e le intestazioni
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Invia il corpo come stringa 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;
}
```
Invia webhook con 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) (nota: seleziona nessuna autorizzazione e usa invece l'opzione di intestazione personalizzata)
### Ulteriori informazioni:
+ [Documentazione del server MCP di Splunk:/-platform/ -splunk-platform https://help.splunk.com/en/ splunk-cloud-platform mcp-server-for-splunk about-mcp-server-for](https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform)
+ Requisiti e limitazioni di accesso per l'API REST di Splunk Cloud Platform: [https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ [Gestisci i token di autenticazione nella piattaforma Splunk Cloud:/- 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 ](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)
+ Crea e gestisci ruoli con Splunk Web: [https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles](https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles)
## Rimozione
La fonte di telemetria è connessa a due livelli a livello di spazio dell'agente e a livello di account. Per rimuoverla completamente, è necessario prima rimuoverla da tutti gli spazi dell'agente in cui viene utilizzata, dopodiché può essere annullata la registrazione.
### Fase 1: Rimuovi dallo spazio dell'agente
1. Dalla pagina degli spazi per gli agenti, seleziona uno spazio agente e premi Visualizza dettagli
1. Seleziona la scheda Funzionalità
1. Scorri verso il basso fino alla sezione Telemetria
1. Seleziona Splunk
1. Premi rimuovi
### Fase 2: Annullare la registrazione dall'account
1. Vai alla pagina dei **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. Scorri fino alla sezione **Attualmente registrato**.
1. Verifica che il numero di spazi per gli agenti sia pari a zero (in caso contrario, ripeti il passaggio 1 precedente negli altri spazi riservati agli agenti)
1. Premi Annulla registrazione accanto a Splunk
# Connessione alla biglietteria e alla chat
AWS DevOps L'agente è progettato per agire come membro del team partecipando ai canali di comunicazione esistenti del team. Puoi collegare DevOps Agent ai tuoi sistemi di ticketing e allarme, ad esempio, per avviare automaticamente le indagini dai ticket relativi agli incidenti PagerDuty, accelerando la risposta agli incidenti all'interno dei flussi di lavoro esistenti ServiceNow e riducendo il tempo medio di ripristino (MTTR). Puoi anche collegare il tuo DevOps agente ai sistemi di collaborazione del team come Slack per ricevere riepiloghi delle attività dal tuo agente in un canale di chat. DevOps
Per ulteriori informazioni su come collegare le integrazioni di ticketing e chat, consulta quanto segue:
+ [Connessione PagerDuty](connecting-to-ticketing-and-chat-connecting-pagerduty.md)
+ [Connessione ServiceNow](connecting-to-ticketing-and-chat-connecting-servicenow.md)
+ [Connessione a Slack](connecting-to-ticketing-and-chat-connecting-slack.md)
# Connessione PagerDuty
PagerDuty l'integrazione consente all' AWS DevOps agente di accedere e aggiornare i dati sugli incidenti, gli orari delle chiamate e le informazioni di servizio dal tuo PagerDuty account durante le indagini sugli incidenti e la risposta automatica. Questa integrazione utilizza la OAuth versione 2.0 per l'autenticazione sicura.
**Importante**
** AWS DevOps L'agente supporta solo la versione PagerDuty OAuth 2.0 più recente (Scoped OAuth). La versione legacy PagerDuty OAuth con URI di reindirizzamento non è supportata.
## PagerDuty requisiti
Prima di connetterti PagerDuty, assicurati di avere:
+ Un PagerDuty account con il tuo ID OAuth cliente e il segreto del cliente
+ Il sottodominio PagerDuty del tuo account (ad esempio, se il tuo PagerDuty URL è`https://your-company.pagerduty.com`, il sottodominio è) `your-company`
## Registrazione PagerDuty
PagerDuty è registrato a livello di AWS account e condiviso tra tutti gli Agent Spaces di quell'account.
### Fase 1: Configurare l'accesso in PagerDuty
1. Accedi alla console AWS di gestione
1. Passa alla console AWS DevOps dell'agente
1. Vai alla pagina **Capability Provider** (accessibile dalla barra di navigazione laterale)
1. Cerca **PagerDuty**nella sezione Provider **disponibili** nella sezione **Comunicazione** e fai clic su **Registra**
1. Segui la configurazione guidata **nella PagerDuty pagina Configura l'accesso in**:
**Controlla la regione e il sottodominio del servizio:**
+ **Ambito dell'account**: seleziona la tua PagerDuty regione (**Stati Uniti** o **UE**) e inserisci il PagerDuty sottodominio. Ad esempio, se il tuo PagerDuty URL è`https://your-company.pagerduty.com`, inserisci`your-company`.
**Crea una nuova app in PagerDuty:**
+ In una scheda separata del browser, accedi PagerDuty e vai a **Integrazioni > Registrazione app**
+ Crea una nuova app utilizzando **OAuth 2.0** Scoped OAuth
+ In **Autorizzazioni**, concedi i seguenti ambiti minimi richiesti:`incidents.read`,, e `incidents.write` `services.read`
+ Abilita **l'integrazione degli eventi** per consentire la comunicazione bidirezionale tra Agente e AWS DevOps PagerDuty
**Configura le credenziali: OAuth **
+ **Ambito di autorizzazione**: gli ambiti minimi richiesti sono:`incidents.read`,, `incidents.write` `services.read`
+ **Nome cliente**: inserisci un nome descrittivo per il tuo cliente OAuth
+ **ID cliente**: inserisci l'ID OAuth cliente riportato nella registrazione PagerDuty dell'app
+ **Segreto del cliente**: inserisci il segreto OAuth del cliente ottenuto durante la registrazione PagerDuty dell'app
### Fase 2: Rivedi e invia PagerDuty la registrazione
1. Rivedi tutti i dettagli PagerDuty di configurazione
1. Fai clic su **Invia** per completare la registrazione
1. Una volta completata la registrazione, PagerDuty viene visualizzato nella sezione **Attualmente registrato** della pagina Provider di capacità
## Aggiunta PagerDuty a uno spazio per agenti
Dopo la registrazione PagerDuty a livello di account, puoi collegarlo a singoli Agent Spaces:
1. Nella console dell' AWS DevOps agente, seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. Nella sezione **Comunicazioni**, fai clic su **Aggiungi**
1. Seleziona **PagerDuty**dall'elenco dei provider disponibili
1. Fai clic su **Salva**
## Gestione delle PagerDuty connessioni
+ **Aggiornamento delle credenziali**: se è necessario aggiornare OAuth le credenziali, annulla la registrazione PagerDuty dalla pagina Capability Providers e registrati nuovamente con le nuove credenziali.
+ **Visualizzazione delle connessioni**: nella console dell' AWS DevOps agente, seleziona Agent Space e vai alla scheda Funzionalità per visualizzare le integrazioni delle comunicazioni connesse.
+ **Rimozione PagerDuty****: per disconnetterti PagerDuty da un Agent Space, selezionalo nella sezione Comunicazioni e fai clic su Rimuovi.** Per rimuovere completamente la registrazione, rimuovila prima da tutti gli Agent Spaces, quindi annulla la registrazione dalla pagina Capability Provider.
## Supporto Webhook
AWS DevOps L'agente supporta solo i webhook PagerDuty V3. Le versioni precedenti dei webhook non sono supportate.
Per ulteriori informazioni sugli abbonamenti ai webhook PagerDuty V3, consulta Panoramica dei [webhook](https://developer.pagerduty.com/docs/webhooks-overview#webhook-subscriptions) nella documentazione per gli sviluppatori. PagerDuty
# Connessione ServiceNow
Questo tutorial illustra come collegare un' ServiceNow istanza ad AWS DevOps Agent per consentirgli di avviare automaticamente le indagini sulla risposta agli incidenti quando viene creato un ticket e di pubblicarne i risultati principali nel ticket di origine. Contiene anche esempi su come configurare l' ServiceNow istanza per inviare solo ticket specifici a un DevOps Agent Space e su come orchestrare il routing dei ticket su più Agent Spaces. DevOps
## Configurazione iniziale
Il primo passaggio consiste nella creazione di ServiceNow un' OAuth applicazione client da AWS DevOps utilizzare per accedere all' ServiceNow istanza.
### Crea un client ServiceNow OAuth applicativo
1. Abilita la proprietà del sistema di credenziali del client dell'istanza
1. Cerca `sys_properties.list` nella casella di ricerca del filtro e poi premi invio (non mostrerà l'opzione ma premere invio funziona)
1. Scegli Nuovo
1. Aggiungi il nome as `glide.oauth.inbound.client.credential.grant_type.enabled` e il valore a true con type as true \$1 false
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/09ed6d5ff911.png)
1. Vai a Sistema OAuth > Registro delle applicazioni dalla casella di ricerca del filtro
1. Scegli «Nuova» > «Nuova esperienza di integrazione in entrata» > «Nuova integrazione» > «OAuth - Concessione delle credenziali del cliente»
1. Scegli un nome e imposta l'utente dell' OAuth applicazione su «Problem Administrator», fai clic su «Salva»
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/aeff4c127f7c.png)
### Connect il ServiceNow OAuth client all' AWS DevOps agente
1. Puoi iniziare questo processo in due punti. Innanzitutto, accedendo alla pagina **Capability Provider** e trovandola nella **ServiceNow**sezione **Comunicazione**, quindi facendo clic su **Registra**. In alternativa, puoi selezionare qualsiasi DevOps Agent Space che potresti aver creato e accedere a Capacità → Comunicazioni → Aggiungi → ServiceNow e fare clic su Registra.
1. Successivamente, autorizza l' DevOps agente ad accedere alla tua ServiceNow istanza utilizzando il client OAuth applicativo che hai appena creato.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/3db5a9aafc5f.png)
+ Segui i passaggi successivi e salva le informazioni risultanti sul webhook
**Importante**
Queste informazioni non verranno più visualizzate
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/80d0a319f87e.png)
### Configura la tua regola ServiceNow aziendale
Una volta stabilita la connettività, dovrai configurare una regola aziendale per ServiceNow inviare i ticket al/i tuo/i DevOps Agent Space.
1. Vai su Activity Subscriptions → Administration → Business Rules e fai clic su Nuovo.
1. Imposta il campo «Tabella» su «Incidente [incidente]», seleziona la casella «Avanzate» e imposta la regola in modo che venga eseguita dopo l'inserimento, l'aggiornamento e l'eliminazione.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/6f2a7370e2c0.png)
1. Vai alla scheda «Avanzate» e aggiungi il seguente script webhook, inserendo il segreto e l'URL del webhook dove indicato, e fai clic su Invia.
```
(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 hai scelto di registrare la ServiceNow connessione dalla pagina **Provider di funzionalità**, ora devi accedere all' DevOps Agent Space in cui desideri esaminare i ticket relativi agli ServiceNow incidenti, selezionare Capacità → Comunicazioni e quindi registrare l' ServiceNow istanza registrata nella pagina Provider di capacità. Ora, tutto dovrebbe essere configurato e tutti gli incidenti in cui il chiamante è impostato su «Problem Administrator» (per simulare le autorizzazioni che hai dato al AWS DevOps OAuth client) avvieranno un'indagine sulla risposta agli incidenti nell'Agent Space configurato. DevOps Puoi verificarlo creando un nuovo incidente in ServiceNow e impostando il campo Caller dell'incidente come «Problem Administrator».
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/4c7d24a85f88.png)
### ServiceNow aggiornamenti dei ticket
Durante tutte le indagini relative alla risposta agli incidenti innescati, il tuo DevOps agente fornirà aggiornamenti sui risultati principali, sulle analisi delle cause principali e sui piani di mitigazione nel ticket di origine. I risultati dell'agente vengono pubblicati nei commenti relativi a un incidente e al momento pubblicheremo solo i dati relativi al tipo`finding`, `cause` `investigation_summary``mitigation_summary`, e agli aggiornamenti sullo stato delle indagini (ad esempio). `AWS DevOps Agent started/finished its investigation`
## Esempi di routing e orchestrazione dei ticket
### Scenario: filtraggio degli incidenti inviati a un Agent Space DevOps
Questo è uno scenario semplice ma richiede una configurazione ServiceNow per creare un campo per ServiceNow tracciare l'origine dell'incidente. Ai fini di questo esempio, crea un nuovo campo Source (u\$1source) utilizzando il generatore di moduli SNOW. Ciò consentirà di tracciare l'origine dell'incidente e di utilizzarla per indirizzare le richieste da una particolare fonte a un DevOps Agent Space. Il routing viene eseguito creando una regola aziendale di Service Now e nella scheda Quando eseguire impostando i trigger «When» e «Filter Conditions». In questo esempio le condizioni di filtro sono impostate come segue:
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/fac7a186beee.png)
### Scenario: instradamento degli incidenti su più DevOps spazi di agenti
Questo esempio mostra come attivare un'indagine in DevOps Agent Space B quando l'urgenza è`1`, la categoria è `Software` o il servizio è `AWS` e avviare un'indagine in DevOps Agent Space A quando il servizio è e l'origine `AWS` sì. `Dynatrace`
Questo scenario può essere realizzato in due modi. Lo script webhook stesso può essere aggiornato per includere questa logica aziendale. In questo scenario mostreremo come realizzarlo con una ServiceNow Business Rule, per la trasparenza e la semplificazione del debug. Il routing viene eseguito creando due regole aziendali di Service Now.
+ Crea una regola aziendale in ServiceNow DevOps Agent Space A e crea una condizione utilizzando il generatore di condizioni per inviare solo gli eventi in base alla nostra condizione specificata.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/bca2f3928bf0.png)
+ Quindi, crea un'altra regola aziendale in AgentSpace B ServiceNow per la quale la regola aziendale verrà attivata solo quando Service è AWS e l'origine è Dynatrace.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/bc29e4db1a76.png)
Ora, quando crei un nuovo Incidente che corrisponde alla condizione specificata, verrà avviata un'indagine su DevOps Agent Space A o DevOps Agent Space B, fornendoti un controllo granulare sul routing degli incidenti.
# Connessione a Slack
Puoi configurare AWS DevOps Agent in modo che aggiorni un canale Slack selezionato con indagini sulla risposta agli incidenti, risultati chiave, analisi delle cause principali e piani di mitigazione generati.
## Prima di iniziare
Slack deve essere registrato con DevOps Agent prima di poter essere aggiunto a un Agent Space. Per integrare AWS DevOps Agent con Slack devi soddisfare questi requisiti:
+ Accedi a uno spazio di lavoro Slack con la possibilità di installare e autorizzare applicazioni di terze parti
+ Hai identificato i canali Slack a cui desideri che Agent invii notifiche AWS DevOps
## Registra l'integrazione di Slack con Agent AWS DevOps
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/4034f56fad96.png)
1. **Dalla pagina **Capability Provider** della console dell' AWS DevOps agente, trova **Slack** nella sezione Provider **disponibili** in **Comunicazione** e fai clic su Registra.**
1. Scegli il pulsante **Registra**.
1. Verrai reindirizzato a Slack per autorizzare l'applicazione AWS DevOps Agent per il tuo spazio di lavoro.
1. Nella pagina di autorizzazione di Slack, esegui l'installazione direttamente nelle aree di lavoro, non a livello di organizzazione.
1. Scegli uno spazio di lavoro dal menu a discesa. Non selezionate un'Enterprise Grid.
1. Eseguite l'installazione per area di lavoro in base alle esigenze dell'organizzazione.
1. Controlla gli ambiti richiesti e fai clic su **Consenti** per autorizzare l'integrazione.
1. Dopo l'autorizzazione, tornerai alla console dell' AWS DevOps agente.
## Associa Slack ai tuoi spazi DevOps Agent
Dopo aver registrato Slack nel tuo DevOps Agent Space, puoi associarlo ai tuoi spazi DevOps Agent:
1. **Dalla scheda **Funzionalità** all'interno della configurazione AgentSpace, accedi a **Comunicazioni** > Slack.**
1. Seleziona **Aggiungi** Slack
1. Inserisci l'ID del canale
1. Scegli **Crea** per completare la configurazione di Slack.
**Nota**
**L'utente bot dell'agente deve essere aggiunto ai canali privati prima di poter pubblicare messaggi.
**Importante**
**La disinstallazione dell'app Slack potrebbe impedire la reinstallazione dell'app Slack. Evita di disinstallare l'app Slack.
# Richiamo DevOps dell'agente tramite Webhook
I webhook consentono ai sistemi esterni di avviare automaticamente le indagini degli agenti. AWS DevOps Ciò consente l'integrazione con sistemi di ticketing, strumenti di monitoraggio e altre piattaforme in grado di inviare richieste HTTP in caso di incidenti.
## Prerequisiti
Prima di configurare l'accesso ai webhook, assicurati di avere:
+ Un Agent Space configurato in Agent AWS DevOps
+ Accesso alla console dell' AWS DevOps agente
+ Il sistema esterno che invierà le richieste di webhook
## Tipi di webhook
AWS DevOps Agent supporta i seguenti tipi di webhook:
+ **Webhook specifici per l'integrazione**: generati automaticamente quando configuri integrazioni di terze parti come Dynatrace, Splunk, Datadog, New Relic o Slack. ServiceNow Questi webhook sono associati all'integrazione specifica e utilizzano metodi di autenticazione determinati dal tipo di integrazione
+ **Webhook generici**: possono essere creati manualmente per avviare indagini da qualsiasi fonte non coperta da un'integrazione specifica. I webhook generici attualmente utilizzano l'autenticazione **HMAC** (il token bearer non è attualmente disponibile).
+ **Webhook di avviso Grafana**: Grafana può inviare notifiche di avviso direttamente AWS DevOps all'agente tramite i punti di contatto webhook. Per istruzioni di configurazione che includono un modello di notifica personalizzato, vedi [Connecting Grafana](connecting-telemetry-sources-connecting-grafana.md).
## Metodi di autenticazione Webhook
Il metodo di autenticazione per il webhook dipende dall'integrazione a cui è associato:
**Autenticazione HMAC**: utilizzata da:
+ Webhook di integrazione con Dynatrace
+ Webhook generici (non collegati a una specifica integrazione di terze parti)
**Autenticazione con token Bearer**: utilizzata da:
+ Webhook di integrazione Splunk
+ Webhook di integrazione Datadog
+ Nuovi webhook di integrazione con Relic
+ ServiceNow webhook di integrazione
+ webhook di integrazione con Slack
## Configurazione dell'accesso ai webhook
### Fase 1: Accedere alla configurazione del webhook
1. Accedi alla console di AWS gestione e vai alla console dell' AWS DevOps agente
1. Seleziona il tuo Agent Space
1. Vai alla scheda **Funzionalità**
1. **Nella sezione **Webhook**, fai clic su Configura**
### Fase 2: Generazione delle credenziali del webhook
**Per webhook specifici per l'integrazione:**
I webhook vengono generati automaticamente quando si completa la configurazione di un'integrazione di terze parti. L'URL e le credenziali dell'endpoint webhook vengono forniti al termine del processo di configurazione dell'integrazione.
**Per i webhook generici:**
1. **Fai clic su Genera webhook**
1. Il sistema genererà una coppia di key pair HMAC
1. Archivia in modo sicuro la chiave e il segreto generati: non potrai più recuperarli
1. Copia l'URL dell'endpoint del webhook fornito
### Fase 3: Configurazione del sistema esterno
Utilizza l'URL e le credenziali dell'endpoint webhook per configurare il tuo sistema esterno per l'invio di richieste all'agente. AWS DevOps I passaggi di configurazione specifici dipendono dal sistema esterno.
## Gestione delle credenziali del webhook
**Rimozione delle credenziali****: per eliminare le credenziali del webhook, vai alla sezione di configurazione del webhook e fai clic su Rimuovi.** Dopo aver rimosso le credenziali, l'endpoint webhook non accetterà più richieste finché non ne genererai di nuove.
**Rigenerazione delle credenziali**: per generare nuove credenziali, rimuovi prima le credenziali esistenti, quindi genera una nuova coppia di chiavi o token.
## Utilizzo del webhook
### Formato di richiesta Webhook
Per avviare un'indagine, il sistema esterno deve inviare una richiesta POST HTTP all'URL dell'endpoint del webhook.
**Per la versione 1 (autenticazione HMAC):**
Intestazioni:
+ `Content-Type: application/json`
+ `x-amzn-event-signature: `
+ `x-amzn-event-timestamp: <+%Y-%m-%dT%H:%M:%S.000Z>`
La firma HMAC viene generata firmando il corpo della richiesta con la chiave segreta utilizzando SHA-256.
**Per la versione 2 (autenticazione con token Bearer):**
Intestazioni:
+ `Content-Type: application/json`
+ `Authorization: Bearer `
**Corpo della richiesta:**
Il corpo della richiesta deve includere informazioni sull'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"
}
}
}
```
### Codice di esempio
**Versione 1 (autenticazione 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);
});
```
**Versione 1 (autenticazione 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 non ricevi un 200
Un 200 e un messaggio simile a un webhook ricevuto indicano che l'autenticazione è stata superata e il messaggio è stato messo in coda per essere verificato ed elaborato dal sistema. Se non ottieni un 200 ma un 4xx, molto probabilmente c'è qualcosa che non va nell'autenticazione o nelle intestazioni. Prova a inviare manualmente utilizzando le opzioni curl per aiutare a eseguire il debug dell'autenticazione.
### Se ricevi un 200 ma non viene avviata un'indagine
La causa probabile è un payload non formattato.
1. Verifica che sia il timestamp che l'ID dell'incidente siano aggiornati e unici. I messaggi duplicati vengono deduplicati.
1. Verifica che il messaggio sia JSON valido
1. Verifica che il formato sia corretto
### Se ricevi 200 dollari e l'indagine viene immediatamente annullata
Molto probabilmente hai raggiunto il limite mensile. Rivolgiti al tuo AWS contatto per chiedere una modifica del limite di tariffa, se del caso.
## Argomenti correlati
+ [Creazione di uno spazio per agenti](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
+ [Cos'è un'app Web per DevOps agenti?](about-aws-devops-agent-what-is-a-devops-agent-web-app.md)
+ [DevOps Autorizzazioni Agent IAM](aws-devops-agent-security-devops-agent-iam-permissions.md)
# Integrazione dell' AWS DevOps agente con Amazon EventBridge
Puoi integrare AWS DevOps Agent con le tue applicazioni basate sugli eventi utilizzando gli eventi che si verificano durante i cicli di vita di indagine e mitigazione. AWS DevOps L'agente invia eventi ad Amazon EventBridge quando lo stato di un'indagine o di mitigazione cambia. Puoi quindi creare EventBridge regole che agiscano in base a questi eventi.
Ad esempio, è possibile creare regole che eseguono le seguenti azioni:
+ Richiama una funzione AWS Lambda per elaborare i risultati dell'indagine al termine di un'indagine.
+ Invia una notifica Amazon SNS quando un'indagine fallisce o scade.
+ Aggiorna un sistema di ticketing quando viene creata una nuova indagine.
+ Avvia un flusso di lavoro AWS Step Functions al termine di un'azione di mitigazione.
## Come EventBridge indirizza AWS DevOps gli eventi dell'agente
AWS DevOps L'agente invia gli eventi al bus degli eventi EventBridge predefinito. EventBridge quindi valuta gli eventi in base alle regole create dall'utente. Quando un evento corrisponde al modello di evento di una regola, EventBridge invia l'evento ai target specificati.
Il diagramma seguente mostra come EventBridge indirizza gli eventi AWS DevOps dell'agente.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/eventbridge-integration-how-it-works.png)
1. AWS DevOps L'agente invia un evento al bus degli eventi EventBridge predefinito quando lo stato del ciclo di vita di un'indagine o di mitigazione cambia.
1. EventBridge valuta l'evento in base alle regole che hai creato.
1. Se l'evento corrisponde allo schema di eventi di una regola, EventBridge invia l'evento ai target specificati nella regola.
## AWS DevOps Eventi dell'agente
AWS DevOps L'agente invia i seguenti eventi a EventBridge. Tutti gli eventi utilizzano la fonte`aws.aidevops`.
### Eventi investigativi supportati
| detail-type (tipo di dettaglio) | Description |
| --- | --- |
| Investigation Created | È stata creata un'indagine nello spazio dedicato agli agenti. |
| Investigation Priority Updated | La priorità di un'indagine è stata modificata. |
| Investigation In Progress | Un'indagine ha avviato un'analisi attiva. |
| Investigation Completed | Un'indagine si è conclusa con successo con i risultati. |
| Investigation Failed | Un'indagine ha rilevato un errore e non è stata completata. |
| Investigation Timed Out | Un'indagine ha superato la durata massima consentita. |
| Investigation Cancelled | Un'indagine è stata annullata prima del completamento. |
| Investigation Pending Triage | Un'indagine è in attesa di valutazione prima che inizi l'analisi attiva. |
| Investigation Linked | Un'indagine era collegata a un incidente o a un ticket correlato. |
### Eventi di mitigazione supportati
| detail-type (tipo di dettaglio) | Description |
| --- | --- |
| Mitigation In Progress | È iniziata un'azione di mitigazione. |
| Mitigation Completed | Un'azione di mitigazione è stata completata con successo. |
| Mitigation Failed | Un'azione di mitigazione ha rilevato un errore e non è stata completata. |
| Mitigation Timed Out | Un'azione di mitigazione ha superato la durata massima consentita. |
| Mitigation Cancelled | Un'azione di mitigazione è stata annullata prima del completamento. |
Per descrizioni dettagliate dei campi ed eventi di esempio, vedere. [AWS DevOps Riferimento dettagliato sugli eventi degli agenti](integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-devops-agent-events-detail-reference.md)
## Creazione di modelli di eventi che corrispondono agli eventi AWS DevOps dell'agente
EventBridge le regole utilizzano modelli di eventi per selezionare gli eventi e indirizzarli verso gli obiettivi. Un modello di eventi corrisponde alla struttura degli eventi che gestisce. Si creano modelli di eventi per filtrare gli eventi AWS DevOps dell'agente in base ai campi degli eventi.
Gli esempi seguenti mostrano modelli di eventi per casi d'uso comuni.
**Abbina tutti gli eventi AWS DevOps dell'agente**
Il seguente schema di eventi corrisponde a tutti gli eventi di AWS DevOps Agent.
```
{
"source": ["aws.aidevops"]
}
```
**Abbina solo gli eventi investigativi**
Il seguente modello di eventi utilizza un prefisso match per selezionare solo gli eventi del ciclo di vita dell'indagine.
```
{
"source": ["aws.aidevops"],
"detail-type": [{"prefix": "Investigation"}]
}
```
**Abbina solo gli eventi di completamento e di fallimento**
Il seguente schema di eventi corrisponde agli eventi relativi a indagini e mitigazioni completate o non riuscite.
```
{
"source": ["aws.aidevops"],
"detail-type": [
"Investigation Completed",
"Investigation Failed",
"Mitigation Completed",
"Mitigation Failed"
]
}
```
**Abbina gli eventi per uno spazio agente specifico**
Il seguente schema di eventi corrisponde agli eventi di uno spazio agente specifico.
```
{
"source": ["aws.aidevops"],
"detail": {
"metadata": {
"agent_space_id": ["your-agent-space-id"]
}
}
}
```
Per ulteriori informazioni sui pattern di eventi, consulta la pagina [Amazon EventBridge Event Patterns](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) nella *Amazon EventBridge User Guide*.
## EventBridge Autorizzazioni Amazon
AWS DevOps L'agente non richiede autorizzazioni aggiuntive per fornire eventi. EventBridge Gli eventi vengono inviati automaticamente al bus eventi predefinito.
A seconda delle destinazioni configurate per le EventBridge regole, potrebbe essere necessario aggiungere autorizzazioni specifiche. *Per ulteriori informazioni sulle autorizzazioni richieste per gli obiettivi, consulta [Using resource-based policies for Amazon nella Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) User EventBridge Guide. EventBridge *
## Risorse aggiuntive EventBridge
Per ulteriori informazioni su EventBridge concetti e configurazione, consulta i seguenti argomenti nella *Amazon EventBridge User Guide*:
+ [EventBridge autobus per eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)
+ [EventBridge eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)
+ [EventBridge modelli di eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [EventBridge regole](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)
+ [EventBridge obiettivi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)
# AWS DevOps Riferimento dettagliato sugli eventi degli agenti
Gli eventi dei AWS servizi hanno campi di metadati comuni, tra cui `source``detail-type`,, `account``region`, e`time`. Questi eventi contengono anche un `detail` campo con dati specifici del servizio. Per gli eventi dell' AWS DevOps agente, `source` è sempre `aws.aidevops` e `detail-type` identifica l'evento specifico.
## Eventi investigativi
I seguenti `detail-type` valori identificano gli eventi investigativi:
+ `Investigation Created`
+ `Investigation Priority Updated`
+ `Investigation In Progress`
+ `Investigation Completed`
+ `Investigation Failed`
+ `Investigation Timed Out`
+ `Investigation Cancelled`
+ `Investigation Pending Triage`
+ `Investigation Linked`
I `detail-type` campi `source` e sono inclusi di seguito perché contengono valori specifici per gli eventi AWS DevOps dell'agente. Per le definizioni degli altri campi di metadati inclusi in tutti gli eventi, consulta la [struttura degli eventi in Amazon EventBridge Events](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) *Reference*.
Di seguito è riportata la struttura JSON per gli eventi investigativi.
```
{
. . .,
"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 il tipo di evento. Per gli eventi di indagine, questo è uno dei nomi degli eventi elencati in precedenza.
**`source`**Identifica il servizio che ha generato l'evento. Per gli eventi AWS DevOps dell'agente, questo valore è`aws.aidevops`.
**`detail`**Un oggetto JSON che contiene dati specifici dell'evento. L'`detail`oggetto include i seguenti campi:
+ `version`(stringa) — La versione dello schema dei dettagli dell'evento. Attualmente`1.0.0`.
+ `metadata.agent_space_id`(stringa) — L'identificatore univoco dello spazio agente in cui ha avuto origine l'evento.
+ `metadata.task_id`(stringa) — L'identificatore univoco dell'attività.
+ `metadata.execution_id`(stringa) — L'identificatore univoco dell'esecuzione. Presente quando un'esecuzione è stata assegnata all'indagine.
+ `data.task_type`(stringa) — Il tipo di attività. Valore:`INVESTIGATION`.
+ `data.priority`(stringa) — Il livello di priorità. Valori:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(stringa) — Lo stato corrente. Valori:`PENDING_START`,`IN_PROGRESS`,`COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`,`PENDING_TRIAGE`,`LINKED`.
+ `data.created_at`(stringa) — Timestamp ISO 8601 al momento della creazione dell'attività.
+ `data.updated_at`(stringa) — Data e ora ISO 8601 dell'ultimo aggiornamento dell'attività.
+ `data.summary_record_id`(stringa) — L'identificatore della registrazione riassuntiva contenente i risultati dell'indagine. Incluso quando viene generato un riepilogo per l'indagine completata. È possibile recuperare il contenuto del riepilogo tramite l'API dell' AWS DevOps agente utilizzando questo identificatore per cercare il record del diario con un tipo di record di. `investigation_summary_md`
**Esempio: evento Indagine completata**
```
{
"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"
}
}
}
```
**Esempio: Evento di indagine fallito**
```
{
"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"
}
}
}
```
## Eventi di mitigazione
I seguenti `detail-type` valori identificano gli eventi di mitigazione:
+ `Mitigation In Progress`
+ `Mitigation Completed`
+ `Mitigation Failed`
+ `Mitigation Timed Out`
+ `Mitigation Cancelled`
I `detail-type` campi `source` e sono inclusi di seguito perché contengono valori specifici per gli eventi AWS DevOps dell'agente. Per le definizioni degli altri campi di metadati inclusi in tutti gli eventi, consulta la [struttura degli eventi in Amazon EventBridge Events](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) *Reference*.
Di seguito è riportata la struttura JSON per gli eventi di mitigazione.
```
{
. . .,
"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 il tipo di evento. Per gli eventi di mitigazione, questo è uno dei nomi degli eventi elencati in precedenza.
**`source`**Identifica il servizio che ha generato l'evento. Per gli eventi AWS DevOps dell'agente, questo valore è`aws.aidevops`.
**`detail`**Un oggetto JSON che contiene dati specifici dell'evento. L'`detail`oggetto include i seguenti campi:
+ `version`(stringa) — La versione dello schema dei dettagli dell'evento. Attualmente`1.0.0`.
+ `metadata.agent_space_id`(stringa) — L'identificatore univoco dello spazio agente in cui ha avuto origine l'evento.
+ `metadata.task_id`(stringa) — L'identificatore univoco dell'attività.
+ `metadata.execution_id`(stringa) — L'identificatore univoco dell'esecuzione. Presente quando un'esecuzione è stata assegnata alla mitigazione.
+ `data.task_type`(stringa) — Il tipo di attività. Valore:`INVESTIGATION`.
+ `data.priority`(stringa) — Il livello di priorità. Valori:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(stringa) — Lo stato corrente. Valori:`IN_PROGRESS`,`COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`.
+ `data.created_at`(stringa) — Timestamp ISO 8601 al momento della creazione dell'attività.
+ `data.updated_at`(stringa) — Data e ora ISO 8601 dell'ultimo aggiornamento dell'attività.
+ `data.summary_record_id`(stringa) — L'identificatore del record di riepilogo contenente i risultati della mitigazione. Incluso quando viene generato un riepilogo per la mitigazione completata. È possibile recuperare il contenuto del riepilogo tramite l' AWS DevOps Agent API utilizzando questo identificatore per cercare il record del journal con un tipo di record di. `mitigation_summary_md`
**Esempio: evento Mitigation Completed**
```
{
"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"
}
}
}
```
**Esempio: evento di mitigazione non riuscito**
```
{
"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"
}
}
}
```
# Registri e metriche venduti
Puoi monitorare gli spazi degli agenti e le operazioni di servizio utilizzando i CloudWatch parametri e i log di Amazon forniti. Questo argomento descrive le CloudWatch metriche che l' AWS DevOps agente pubblica automaticamente sul tuo account e i log forniti che puoi configurare per la consegna alle tue destinazioni preferite.
## Metriche vendute CloudWatch
AWS DevOps L'agente pubblica automaticamente le metriche su Amazon CloudWatch nel tuo account. Queste metriche sono disponibili senza alcuna configurazione. È possibile utilizzarle per monitorare l'utilizzo, tenere traccia dell'attività operativa e creare allarmi.
### Ruolo collegato ai servizi
Per far sì che i CloudWatch parametri Amazon vengano pubblicati nel tuo account per questo servizio, AWS DevOps Agent creerà automaticamente il [ruolo collegato al servizio **AWSServiceRoleForAIDevOps** Service-Linked](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) Role per te. Se il ruolo IAM che richiama l'API non dispone dell'autorizzazione appropriata, la creazione della risorsa avrà esito negativo con un. InvalidParameterException
**Importante**
I clienti che hanno creato il proprio ruolo AgentSpace prima del 13 marzo 2026 dovranno creare manualmente il ruolo collegato al servizio **AWSServiceRoleForAIDevOps** per pubblicare le CloudWatch metriche relative all' AWS DevOps agente nel proprio account.
### Crea manualmente un ruolo collegato al servizio (per i clienti esistenti)
Esegui una delle seguenti operazioni:
+ Nella console IAM, crea il ruolo **AWSServiceRoleForAIDevOps** nel servizio **AWS DevOps Agent.**
+ Dalla AWS CLI, esegui il seguente comando:
```
aws iam create-service-linked-role --aws-service-name aidevops.amazonaws.com
```
### Namespace
Tutte le metriche sono pubblicate nel namespace. `AWS/AIDevOps`
### Dimensioni
Tutte le metriche includono la seguente dimensione.
| Dimensione | Description |
| --- | --- |
| AgentSpaceUUID | L'identificatore univoco dello spazio degli agenti. Per aggregare le metriche relative a tutti gli spazi degli agenti del tuo account, utilizza espressioni CloudWatch matematiche o ometti il filtro dimensionale. |
### Riferimento per le metriche
| Nome parametro | Description | Unità | Frequenza di pubblicazione | Statistiche utili |
| --- | --- | --- | --- | --- |
| ConsumedChatRequests | Il numero di richieste di chat consumate dallo spazio di un agente. Per ottenere il conteggio totale del tuo account, utilizza la SUM statistica per tutte le AgentSpaceUUID dimensioni. | Conteggio | Ogni 5 minuti | Somma, media |
| ConsumedInvestigationTime | Il tempo impiegato a condurre indagini in uno spazio riservato agli agenti. | Secondi | Ogni 5 minuti | Somma, media, massimo |
| ConsumedEvaluationTime | Il tempo impiegato per eseguire le valutazioni in uno spazio dedicato agli agenti. | Secondi | Ogni 5 minuti | Somma, media, massimo |
| TopologyCompletionCount | Il numero di completamenti dell'elaborazione della topologia. AWS DevOps L'agente emette questa metrica al termine dell'elaborazione di una topologia, che si tratti della creazione iniziale durante l'onboarding, di un aggiornamento manuale o di un aggiornamento giornaliero pianificato. | Conteggio | Basato sugli eventi (emesso a ogni completamento) | Somma, SampleCount |
### Visualizzazione delle metriche nella console CloudWatch
1. Apri la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Parametri** quindi scegli **Tutti i parametri**.
1. Scegli lo spazio dei nomi **AWS/AIDevOps**.
1. Scegli **By AgentSpace** per visualizzare le metriche relative agli spazi riservati agli agenti.
**Nota**
**Puoi creare CloudWatch allarmi in base a queste metriche per ricevere notifiche quando l'utilizzo supera una soglia. Ad esempio, crea un allarme per monitorare il consumo delle `ConsumedChatRequests` richieste di chat.
## Prerequisiti
Prima di configurare la consegna dei log, assicurati di disporre di quanto segue:
+ Un AWS account attivo con accesso alla console dell' AWS DevOps agente
+ Un preside IAM con autorizzazioni per la consegna dei CloudWatch log APIs
+ (Facoltativo) Un bucket Amazon S3 o un flusso di distribuzione Amazon Data Firehose, se prevedi di utilizzarli come destinazioni di log
## Registri venduti
AWS DevOps L'agente supporta i log forniti che forniscono visibilità sugli eventi elaborati dagli spazi degli agenti e dalle registrazioni dei servizi. I registri venduti utilizzano l'infrastruttura Amazon CloudWatch Logs per consegnare i log alla destinazione preferita.
Per utilizzare i registri venduti, devi configurare una destinazione di consegna. Sono supportate le seguenti destinazioni:
+ **Amazon CloudWatch Logs**: un gruppo di log nel tuo account
+ **Amazon S3**: un bucket S3 nel tuo account
+ **Amazon Data Firehose**: un flusso di distribuzione di Firehose nel tuo account
### Tipi di log supportati
È supportato un solo tipo di registro:. `APPLICATION_LOGS` Questo tipo di registro copre tutti gli eventi operativi emessi dal servizio.
### Registra i tipi di eventi
La tabella seguente riepiloga gli eventi registrati dall' AWS DevOps agente.
| Event | Description | Livello di log |
| --- | --- | --- |
| Evento in entrata dell'agente ricevuto | Un agente viene attivato da una fonte integrata e riceve un evento in entrata (ad esempio, un evento PagerDuty incidente). | INFO |
| L'evento in entrata dell'agente è stato interrotto | Un evento in entrata è stato eliminato prima che l'agente lo elaborasse. Il registro include il motivo (ad esempio, dati non validi). | TBD |
| Errore di comunicazione in uscita dell'agente | Una comunicazione in uscita con un'integrazione di terze parti non è riuscita. Il registro include l'ID dell'attività e l'identificatore di destinazione (ad esempio, un errore di autenticazione). | TBD |
| Creazione della topologia in coda | Un processo di creazione della topologia era in coda per l'elaborazione. | INFO |
| La creazione della topologia è iniziata | È iniziata l'elaborazione di un processo di creazione della topologia. | INFO |
| Creazione della topologia terminata | Elaborazione completata di un processo di creazione della topologia. Questo evento si applica alla creazione iniziale, agli aggiornamenti e agli aggiornamenti giornalieri. | INFO |
| Individuazione delle risorse non riuscita | Si è verificato un errore nell'individuazione delle risorse durante la creazione della topologia. | ERRORE |
| Registrazione del servizio non riuscita | La registrazione del servizio rileva un errore irreversibile | ERRORE |
| La convalida del webhook fallisce | Quando il webhook ricevuto dall'agente Devops non corrisponde allo schema previsto | ERRORE |
| Aggiornamenti dello stato di convalida dell'associazione | Quando si verifica un'associazione nello spazio di un agente ( primary/secondary account tipico), lo stato di convalida passa da valido a non valido e viceversa (ad esempio, a causa di un ruolo non valido, che non è ipotizzabile dal servizio). | ERRORE/INFORMAZIONI |
### Permissions
AWS DevOps L'agente utilizza i [registri CloudWatch venduti (autorizzazioni V2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)) per fornire i log. Per configurare la consegna dei log, il ruolo IAM che configura la consegna deve disporre delle seguenti autorizzazioni:
+ `aidevops:AllowVendedLogDeliveryForResource`— Necessario per consentire la consegna dei log per la risorsa dello spazio dell'agente.
+ Autorizzazioni per la consegna CloudWatch dei log APIs (`logs:PutDeliverySource`, `logs:PutDeliveryDestination``logs:CreateDelivery`, e operazioni correlate).
+ Autorizzazioni specifiche per la destinazione di consegna scelta.
Per la policy IAM completa richiesta per ogni tipo di destinazione, consulta i seguenti argomenti nella *Amazon CloudWatch Logs User Guide*:
+ [Log inviati a Logs CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-CloudWatchLogs.html)
+ [Registri inviati ad Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html)
+ [Log inviati a Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)
### Configura la consegna dei log (console)
AWS DevOps L'agente fornisce due posizioni nella console di AWS gestione per configurare la consegna dei log:
+ **Pagina delle impostazioni di registrazione del servizio**: configura la consegna dei log per gli eventi a livello di servizio. Questi log utilizzano il servizio ARN `arn:aws:aidevops:::service/` () come risorsa.
+ **Pagina Agent Space**: configura la consegna dei log per gli eventi specifici di un singolo spazio agente. Questi log utilizzano lo spazio agente ARN `arn:aws:aidevops:::agentspace/` () come risorsa.
#### Per configurare la consegna dei log per la registrazione di un servizio
1. Aprire la console AWS DevOps dell'agente nella console AWS di gestione.
1. Nel pannello di navigazione scegli **Impostazioni**.
1. Nella scheda **Provider di capacità** **>** **Registri**, scegli **Configura**.
1. Per **Tipo di destinazione**, scegliete una delle seguenti opzioni:
1. **CloudWatch Registri**: seleziona o crea un gruppo di registri.
1. **Amazon S3**: inserisci l'ARN del bucket S3.
1. **Amazon Data Firehose**: seleziona o crea un flusso di distribuzione Firehose.
1. Per **le impostazioni aggiuntive**, *facoltativo*, puoi specificare le seguenti opzioni:
1. Per **Selezione del campo**, seleziona i nomi dei campi di log che desideri consegnare alla destinazione. È possibile selezionare [i campi del registro degli accessi](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) e un sottoinsieme di campi del [registro degli accessi in tempo reale](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Solo Amazon S3) Per **Partizionamento**, specifica il percorso per partizionare i dati del file di log.
1. (Solo Amazon S3) Per **Formato file compatibile con Hive**, puoi selezionare la casella di controllo per utilizzare percorsi S3 compatibili con Hive. Questo consente di semplificare il caricamento di nuovi dati negli strumenti compatibili con Hive.
1. Per **Formato di output**, specifica il formato preferito.
1. Per **Delimitatore di campo**, specifica come separare i campi di log.
1. Scegli **Save** (Salva).
1. Verifica che lo stato della spedizione sia **Attivo**.
#### Per configurare la consegna dei log per uno spazio agente
1. Aprire la console AWS DevOps dell'agente nella console AWS di gestione.
1. Scegli lo spazio dell'agente che desideri configurare.
1. Nella scheda **Configurazione**, scegli **Configura**.
1. Per **[Tipo di destinazione](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)**, scegli una delle seguenti opzioni:
1. **CloudWatch Registri**: seleziona o crea un gruppo di registri.
1. **Amazon S3**: inserisci l'ARN del bucket S3.
1. **Amazon Data Firehose**: seleziona o crea un flusso di distribuzione Firehose.
1. Per **le impostazioni aggiuntive, \$1opzionale\$1**, puoi specificare le seguenti opzioni:
1. Per **Selezione del campo**, seleziona i nomi dei campi di log che desideri consegnare alla destinazione. È possibile selezionare i campi del [registro degli accessi e un sottoinsieme di campi](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) del [registro degli accessi in tempo reale](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Solo Amazon S3) Per **Partizionamento**, specifica il percorso per partizionare i dati del file di log.
1. (Solo Amazon S3) Per **Formato file compatibile con Hive**, puoi selezionare la casella di controllo per utilizzare percorsi S3 compatibili con Hive. Questo consente di semplificare il caricamento di nuovi dati negli strumenti compatibili con Hive.
1. Per **Formato di output**, specifica il formato preferito.
1. Per **Delimitatore di campo**, specifica come separare i campi di log.
1. Scegli **Save** (Salva).
1. Verifica che lo stato della spedizione sia **Attivo**.
### Configura la consegna dei log (CloudWatch API)
Puoi anche utilizzare l'API CloudWatch Logs per configurare la consegna dei log a livello di codice. Una consegna di log funzionante è composta da tre elementi:
+ A **DeliverySource**— Rappresenta la risorsa spaziale AWS DevOps dell'agente che genera i log.
+ A **DeliveryDestination**— Rappresenta la destinazione in cui vengono scritti i log.
+ Una **consegna**: collega un'origine di consegna a una destinazione di consegna.
#### Fase 1: Creare una fonte di consegna
Usa l'[PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)operazione per creare una fonte di consegna. Passa l'ARN della tua risorsa di spazio AWS DevOps Agent e specifica `APPLICATION_LOGS` come tipo di registro.
L'esempio seguente crea una fonte di consegna per uno spazio agente:
```
{
"name": "my-agent-space-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/my-agent-space-id",
"logType": "APPLICATION_LOGS"
}
```
L'esempio seguente crea una fonte di consegna per il servizio:
```
{
"name": "my-service-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:service",
"logType": "APPLICATION_LOGS"
}
```
#### Fase 2: Creare una destinazione di consegna
Usa l'[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)operazione per configurare dove vengono archiviati i log. Puoi scegliere Amazon CloudWatch Logs, Amazon S3 o Amazon Data Firehose.
L'esempio seguente crea una CloudWatch destinazione Logs:
```
{
"name": "my-cwl-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/aidevops/my-agent-space"
},
"outputFormat": "json"
}
```
L'esempio seguente crea una destinazione Amazon S3:
```
{
"name": "my-s3-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::my-aidevops-logs-bucket"
},
"outputFormat": "json"
}
```
L'esempio seguente crea una destinazione 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 spedisci i log su più account, devi utilizzarli [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html)nell'account di destinazione per autorizzare la consegna.
Se desideri utilizzare CloudFormation, puoi utilizzare quanto segue:
+ [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 essere `APPLICATION_LOGS` come tipo di log supportato.
#### Fase 3: Creare una consegna
Utilizza l'[CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)operazione per collegare l'origine di consegna alla destinazione di consegna.
```
{
"deliverySourceName": "my-agent-space-delivery-source",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:my-cwl-destination"
}
```
#### AWS CloudFormation
È inoltre possibile configurare la consegna dei log utilizzando AWS CloudFormation le seguenti risorse:
+ [AWS: :Registri:: DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
+ [AWS: :Registri:: DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [AWS: :Logs: :Consegna](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
`ResourceArn`Impostato sullo spazio AWS DevOps agente o sull'ARN del servizio e impostato su`LogType`. `APPLICATION_LOGS`
### Riferimento allo schema di log
AWS DevOps L'agente utilizza uno schema di registro condiviso per tutti i tipi di eventi. Non tutti gli eventi di registro utilizzano tutti i campi.
La tabella seguente descrive i campi dello schema di registro.
| Campo | Tipo | Description |
| --- | --- | --- |
| event\$1timestamp | Long | Timestamp Unix di quando si è verificato l'evento |
| resource\$1arn | Stringa | ARN della risorsa che ha generato l'evento |
| optional\$1account\$1id | Stringa | AWS ID dell'account associato al registro. |
| livello\$1opzionale | Stringa | Livello di registro:, INFO WARN ERROR |
| opzionale\$1agent\$1space\$1id | Stringa | Identificatore dello spazio dell'agente. |
| id\$1associazione\$1opzionale | Stringa | Identificatore di associazione per il registro. |
| opzionale\$1status | Stringa | Stato dell'operazione di topologia. |
| opzionale\$1webhook\$1id | Stringa | Identificatore Webhook. |
| opzionale\$1mcp\$1endpoint\$1url | Stringa | URL dell'endpoint del server MCP |
| tipo\$1di\$1servizio opzionale | Stringa | Tipo di servizio:,,,,. DYNATRACE DATADOG GITHUB SLACK SERVICENOW |
| opzionale\$1service\$1endpoint\$1url | Stringa | URL dell'endpoint per integrazioni di terze parti. |
| id\$1servizio\$1opzionale | Stringa | Identificatore della fonte. |
| request\$1id | Stringa | Richiedi l'identificatore per la correlazione AWS CloudTrail o i ticket di assistenza. |
| operazione\$1opzionale | Stringa | Nome dell'operazione che è stata eseguita. |
| optional\$1task\$1type | Stringa | Tipo di attività Agent Backlog: o INVESTIGATION EVALUATION |
| optional\$1task\$1id | Stringa | Identificatore dell'attività di backlog di Agent Backlog Task. IDAgent |
| referenza\$1opzionale | Stringa | Riferimento tratto da un'attività di agente (ad esempio, un ticket Jira). |
| tipo\$1errore\$1opzionale | Stringa | Tipi di errore |
| messaggio\$1errore\$1opzionale | Stringa | Descrizione dell'errore quando un'operazione fallisce. |
| optional\$1details | Stringa (JSON) | Payload di eventi specifico del servizio che contiene i parametri e i risultati delle operazioni. |
### Gestisci e disabilita la consegna dei log
È possibile modificare o rimuovere la consegna dei log in qualsiasi momento dalla console dell' AWS DevOps agente nella console di AWS gestione o utilizzando l'API CloudWatch Logs.
#### Gestisci la consegna dei log (console)
1. Apri la console AWS DevOps dell'agente nella console AWS di gestione.
1. Passare alla pagina **Impostazioni** (per i registri a livello di servizio) o alla pagina specifica di **Agent Space (per i registri a livello di Agent Space**).
1. Nella scheda **Configurazione** (per i log a livello di Agent Space) o nella scheda **Capability Provider** **>** **Logs** (per i log a livello di servizio), scegli la consegna da modificare.
1. **Aggiorna la configurazione secondo necessità e scegli Salva.**
**Nota:** non puoi modificare il tipo di destinazione di una consegna esistente. Per modificare il tipo di destinazione, elimina la consegna corrente e creane una nuova.
#### Disabilita la consegna dei log (console)
1. Apri la console AWS DevOps dell'agente nella console AWS di gestione.
1. Passare alla pagina **Impostazioni** (per i registri a livello di servizio) o alla pagina specifica di **Agent Space (per i registri a livello di Agent Space**).
1. Nella scheda **Configurazione** (per i log a livello di Agent Space) o nella scheda **Capability Provider** **>** **Logs** (per i log a livello di servizio), seleziona la consegna da rimuovere.
1. **Scegli Elimina e conferma.**
#### Disabilita la consegna dei log (API)
Per rimuovere una consegna di log utilizzando l'API, elimina le risorse nel seguente ordine:
1. Eliminare la consegna utilizzando [DeleteDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDelivery.html).
1. Elimina la fonte di consegna utilizzando [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html).
1. (Facoltativo) Se la destinazione di consegna non è più necessaria, eliminala utilizzando [DeleteDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliveryDestination.html).
**Importante**
**L'utente è responsabile della rimozione delle risorse di consegna dei log dopo aver eliminato la risorsa dello spazio agente che genera i log (ad esempio, dopo aver eliminato uno spazio agente). Se non rimuovi queste risorse, le configurazioni di consegna potrebbero rimanere orfane.
## Prezzi
L' AWS DevOps agente non addebita alcun costo per l'abilitazione dei registri venduti. Tuttavia, potrebbero essere addebitati costi per la consegna, l’acquisizione, l’archiviazione o l’accesso, a seconda della destinazione di consegna dei log selezionata. [Per i dettagli sui prezzi, **consulta Vented Logs** nella scheda **Logs** di Amazon Pricing. CloudWatch ](https://aws.amazon.com/cloudwatch/pricing/)
Per i prezzi specifici della destinazione, consulta quanto segue:
+ [Prezzi di Amazon CloudWatch Logs](https://aws.amazon.com/cloudwatch/pricing/)
+ [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/)
+ [Prezzi di Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/pricing/)
# Connessione a strumenti ospitati privatamente
## Panoramica delle connessioni private
AWS DevOps L'agente può essere esteso con strumenti personalizzati Model Context Protocol (MCP) e altre integrazioni che consentono all'agente di accedere a sistemi interni come registri di pacchetti privati, piattaforme di osservabilità ospitate autonomamente APIs, documentazione interna e istanze di controllo del codice sorgente (vedi:). [Configurazione delle funzionalità per Agent AWS DevOps](configuring-capabilities-for-aws-devops-agent.md) Questi servizi vengono spesso eseguiti all'interno di un [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide) con accesso pubblico a Internet limitato o nullo, il che significa che l' AWS DevOps agente non può raggiungerli per impostazione predefinita.
Le connessioni private per AWS DevOps Agent ti consentono di connettere in modo sicuro il tuo Agent Space ai servizi in esecuzione nel tuo VPC senza esporli alla rete Internet pubblica. Le connessioni private funzionano con qualsiasi integrazione che necessiti di raggiungere un endpoint privato, inclusi server MCP, istanze Grafana o Splunk con hosting autonomo e sistemi di controllo del codice sorgente come Enterprise Server e Self-Managed. GitHub GitLab
**Nota**
**Se i tuoi strumenti ospitati privatamente inviano richieste in uscita all' AWS DevOps agente dall'interno del tuo VPC, questo traffico può essere protetto anche utilizzando un endpoint VPC in modo che rimanga all'interno della rete. AWS Ad esempio, può essere utilizzato con strumenti che attivano l' DevOps agente tramite eventi webhook (vedi:). [Richiamo DevOps dell'agente tramite Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) Per ulteriori informazioni, consulta [Endpoint VPC (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md).
### Come funzionano le connessioni private
Una connessione privata crea un percorso di rete sicuro tra AWS DevOps l'agente e una risorsa di destinazione nel tuo VPC. Sotto il cofano, AWS DevOps Agent utilizza Amazon [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) per stabilire questo percorso di connettività privata sicuro. VPC Lattice è un servizio di rete di applicazioni che consente di connettere, proteggere e monitorare la comunicazione tra applicazioni VPCs, account e tipi di elaborazione, senza gestire l'infrastruttura di rete sottostante.
Quando si crea una connessione privata, si verifica quanto segue:
+ Fornisci il VPC, le sottoreti e (facoltativamente) i gruppi di sicurezza che dispongono di connettività di rete al servizio di destinazione.
+ AWS DevOps L'agente crea un [gateway di risorse](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html) gestito dai servizi e fornisce le relative interfacce di rete elastiche () ENIs nelle sottoreti specificate.
+ L'agente utilizza il Resource Gateway per indirizzare il traffico verso l'indirizzo IP o il nome DNS del servizio di destinazione tramite il percorso di rete privato.
Il gateway di risorse è completamente gestito dall' AWS DevOps agente e viene visualizzato come risorsa di sola lettura nell'account (denominato). `aidevops-{your-private-connection-name}` Non è necessario configurarlo o gestirlo. Le uniche risorse create nel tuo VPC si trovano ENIs nelle sottoreti specificate. Queste ENIs fungono da punto di ingresso per il traffico privato e sono gestite interamente dal servizio. Non accettano connessioni in entrata da Internet e tu mantieni il pieno controllo sul loro traffico attraverso i tuoi gruppi di sicurezza.
### Sicurezza
Le connessioni private sono progettate con più livelli di sicurezza:
+ **Nessuna esposizione pubblica a Internet**: tutto il traffico tra AWS DevOps Agent e il servizio di destinazione rimane sulla AWS rete. Il tuo servizio non ha mai bisogno di un indirizzo IP pubblico o di un gateway Internet.
+ Gateway **di risorse controllato dal servizio: il gateway** di risorse gestito dai servizi è di sola lettura nell'account dell'utente. Può essere utilizzato solo dall' AWS DevOps agente e nessun altro servizio o principale può instradare il traffico attraverso di esso. Puoi verificarlo nei [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)log, che registrano tutte le chiamate API VPC Lattice.
+ I **tuoi gruppi di sicurezza, le tue regole**: sei tu a controllare il traffico in entrata e in uscita verso i gruppi di sicurezza che ENIs possiedi e gestisci. Se non specifichi gruppi di sicurezza, AWS DevOps Agent crea un gruppo di sicurezza predefinito con ambito alle porte che definisci.
+ **Ruoli collegati ai servizi con privilegi minimi**: AWS DevOps l'agente utilizza un [ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) per creare solo le risorse VPC Lattice e Amazon EC2 necessarie. Questo ruolo è limitato alle risorse contrassegnate `AWSAIDevOpsManaged` e non può accedere ad altre risorse del tuo account.
**Nota**
**Se l'organizzazione dispone [di policy di controllo del servizio (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) che limitano le azioni dell'API VPC Lattice, il gateway di risorse gestito dai servizi viene creato tramite un ruolo collegato al servizio. Assicurati di SCPs autorizzare le azioni necessarie per il ruolo collegato al servizio.
### Architecture
Il diagramma seguente mostra il percorso di rete per una connessione privata.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/7cd6182e6b8d.png)
In questa architettura:
+ AWS DevOps L'agente invia una richiesta al servizio di destinazione.
+ Amazon VPC Lattice indirizza la richiesta attraverso il gateway di risorse gestite dai servizi nel tuo VPC. Per configurazioni avanzate che utilizzano le tue risorse VPC Lattice, [consulta Configurazione avanzata utilizzando le risorse VPC Lattice esistenti](#advanced-setup-using-existing-vpc-lattice-resources).
+ Un ENI nel tuo VPC riceve il traffico e lo inoltra all'indirizzo IP o al nome DNS del servizio di destinazione.
+ I tuoi gruppi di sicurezza regolano il traffico consentito attraverso. ENIs
+ Dal punto di vista del servizio di destinazione, la richiesta proviene da indirizzi IP privati ENIs all'interno del VPC.
## Crea una connessione privata
È possibile creare una connessione privata utilizzando la console di AWS gestione o la AWS CLI.
**Nota**
**Le seguenti zone di disponibilità non sono supportate da VPC Lattice:`use1-az3`,,,`usw1-az2`,`apne1-az3`,, `apne2-az2``euc1-az2`,`euw1-az4`. `cac1-az3` `ilc1-az2`
### Prerequisiti
Prima di creare una connessione privata, verifica di disporre di quanto segue:
+ **Uno spazio agente attivo**: è necessario disporre di uno spazio agente esistente nel proprio account. Se non lo hai, consultare [Guida introduttiva a AWS DevOps Agent](getting-started-with-aws-devops-agent.md).
+ **Un servizio di destinazione raggiungibile privatamente**: il server MCP, la piattaforma di osservabilità o un altro servizio devono essere raggiungibili con un indirizzo IP privato o un nome DNS noto dal VPC in cui è distribuito il gateway di risorse. Il servizio può essere eseguito nello stesso VPC, in un VPC peer o in locale, purché sia instradabile dalle sottoreti del Resource Gateway. Il servizio deve servire il traffico HTTPS con una versione TLS minima di 1.2 su una porta specificata al momento della creazione della connessione.
+ **Sottoreti nel tuo VPC**: identifica da 1 a 20 sottoreti in cui verranno create. ENIs Ti consigliamo di selezionare sottoreti in più zone di disponibilità per un'elevata disponibilità. Queste sottoreti devono disporre di connettività di rete al servizio di destinazione. Una sottorete per zona di disponibilità può essere utilizzata da VPC Lattice.
+ **(Facoltativo) Gruppi di sicurezza**: se desideri controllare il traffico con regole specifiche, prepara fino a cinque gruppi di sicurezza IDs da collegare a. ENIs Se ometti i gruppi di sicurezza, AWS DevOps Agent crea un gruppo di sicurezza predefinito.
Le connessioni private sono risorse a livello di account. Dopo aver creato una connessione privata, puoi riutilizzarla su più integrazioni e Agent Spaces che devono raggiungere lo stesso host.
### Crea una connessione privata utilizzando la console
1. Apri la console AWS DevOps dell'agente.
1. Nel riquadro di navigazione, scegli **Provider di capacità**, quindi scegli **Connessioni private**.
1. Scegli **Crea una nuova connessione**.
1. In **Nome**, inserisci un nome descrittivo per la connessione, ad esempio`my-mcp-tool-connection`.
1. Per **VPC**, seleziona il VPC in cui verrà distribuito il gateway ENIs di risorse.
1. Per **Subnet, seleziona una o più sottoreti** (fino a 20). Consigliamo di scegliere sottoreti in almeno due zone di disponibilità.
1. Per il **tipo di indirizzo IP**, seleziona il tipo di indirizzo IP del servizio di destinazione (`IPv4`,`IPv6`, o`DualStack`).
1. (Facoltativo) Per **Numero di IPv4 indirizzi**, se hai selezionato IPv4 Dualstack per il tipo di indirizzo IP, puoi inserire il numero di IPv4 indirizzi per ENI per il tuo gateway di risorse. L'impostazione predefinita è 16 IPv4 indirizzi per ENI.
1. (Facoltativo) Per **i gruppi** di sicurezza, seleziona i gruppi di sicurezza esistenti (fino a 5) per limitare il traffico consentito per raggiungere il servizio di destinazione. Se non ne selezioni nessuno, viene creato un gruppo di sicurezza predefinito.
1. (Facoltativo) Per gli **intervalli di porte**, specificate le porte TCP su cui l'applicazione di destinazione ascolta (ad esempio `443` o`8080-8090`). È possibile specificare fino a 11 intervalli di porte.
1. Per **Indirizzo host**, inserisci l'indirizzo IP o il nome DNS del servizio di destinazione (ad esempio, `mcp.internal.example.com` o`10.0.1.50`). Il servizio deve essere raggiungibile dal VPC selezionato. Se scegli un nome DNS, deve essere risolvibile dal VPC selezionato.
1. (Facoltativo) Per la **chiave pubblica del certificato**, se l'indirizzo host specificato utilizza certificati TLS emessi da un'autorità di certificazione privata, inserisci la chiave pubblica con codifica PEM del certificato. Ciò consente all' AWS DevOps agente di affidare la connessione TLS al servizio di destinazione.
1. Scegli **Crea connessione**.
Lo stato della connessione cambia in **Creazione in corso**. Questo processo può richiedere fino a 10 minuti. Quando lo stato diventa **Attivo**, il percorso di rete è pronto.
Se la modifica dello stato in **Create non è riuscita**, verifica quanto segue:
+ Le sottoreti specificate hanno indirizzi IP disponibili.
+ Il tuo account non ha raggiunto le quote del servizio VPC Lattice.
+ Nessuna policy IAM restrittiva impedisce al ruolo collegato ai servizi di creare risorse.
**Nota**
**Questi passaggi possono essere eseguiti anche selezionando `Create a new private connection` durante la registrazione di un provider di capacità. Per ulteriori informazioni, consulta [Utilizzare una connessione privata con un provider di funzionalità](#use-a-private-connection-with-a-capability-provider).
### Creare una connessione privata utilizzando la AWS CLI
Esegui il comando seguente per creare una connessione privata. Sostituisci i valori segnaposto con i tuoi.
```
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"]
}
}'
```
La risposta include il nome della connessione e lo stato di: `CREATE_IN_PROGRESS`
```
{
"name": "my-mcp-tool-connection",
"status": "CREATE_IN_PROGRESS",
"resourceGatewayId": "rgw-0123456789abcdef0",
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0"
}
```
Per verificare lo stato della connessione, utilizzare il `describe-private-connection` comando:
```
aws devops-agent describe-private-connection \
--name my-mcp-tool-connection
```
Quando lo stato è`ACTIVE`, la tua connessione privata è pronta per l'uso.
## Utilizza una connessione privata con un provider di funzionalità
Per utilizzare una connessione privata, è possibile collegarsi ad essa durante la registrazione di un provider di funzionalità. Le funzionalità supportate che possono essere utilizzate con connessioni private includono: `GitHub``GitLab`,`MCP Server`, e`Grafana`. È possibile eseguire questo passaggio utilizzando la console di AWS gestione o la AWS CLI.
**Nota**
**Al momento della registrazione di un provider di funzionalità, AWS DevOps Agent verifica che l'endpoint sia raggiungibile e risponda. Assicurati che il servizio di destinazione sia in esecuzione e accetti le connessioni prima di completare la registrazione.
### Utilizza una connessione privata con un provider di funzionalità tramite la console
Nella console dell' AWS DevOps agente, le connessioni private possono essere collegate a una funzionalità durante la registrazione selezionando l'opzione «Connetti all'endpoint utilizzando una connessione privata».
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/devopsagent/latest/userguide/images/a2a7ffb70ffe.png)
1. Apri la console dell' AWS DevOps agente e accedi al tuo Agent Space.
1. Nella sezione **Provider di capacità**, scegli **Registrazione**.
1. Seleziona **Registra** per il tipo di funzionalità che desideri utilizzare con la connessione privata.
1. Nella visualizzazione dei dettagli della registrazione, inserisci l'URL dell'endpoint a cui desideri connetterti utilizzando la connessione privata (ad esempio,`https://mcp.internal.example.com`).
1. Seleziona **Connetti all'endpoint usando una connessione privata.**
1. Seleziona una connessione privata esistente che corrisponde all'URL dell'endpoint a cui desideri connetterti oppure seleziona **Crea una nuova connessione privata** per crearne una.
1. Completa il processo di registrazione per il provider di funzionalità.
### Utilizza una connessione privata con un provider di funzionalità tramite la AWS CLI
È possibile registrare le funzionalità con una connessione privata includendo l'`private-connection-name`argomento. Di seguito è riportato un esempio di registrazione di un server MCP con autorizzazione API Key utilizzando la connessione `my-mcp-tool-connection` privata. Sostituite i valori segnaposto con i vostri.
```
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
```
## Verifica una connessione privata
Dopo che la connessione privata ha raggiunto lo stato **Attivo** ed è stata utilizzata da un provider di funzionalità, verifica che AWS DevOps Agent sia in grado di raggiungere il servizio di destinazione:
1. Apri la console dell' AWS DevOps agente e accedi al tuo Agent Space.
1. Inizia una nuova sessione di chat.
1. Invoca un comando che utilizza l'integrazione supportata dalla tua connessione privata. Ad esempio, se lo strumento MCP fornisce l'accesso a una knowledge base interna, poni all'agente una domanda che richieda tale base di conoscenza.
1. Verifica che l'agente restituisca i risultati del servizio privato.
Se la connessione fallisce, controlla quanto segue:
+ [Limiti di **VPC Lattice: verifica di non aver raggiunto alcun gateway di risorse o altri limiti** di quota VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html)
+ **Regole del gruppo di sicurezza**: verifica che i gruppi di sicurezza collegati al sistema ENIs consentano il traffico in uscita sulla porta su cui il servizio è in ascolto. Verifica inoltre che il gruppo di sicurezza del servizio consenta il traffico in entrata sulla porta di destinazione. Il traffico arriva dal piano dati VPC Lattice all'interno dell'intervallo IPs VPC CIDR. È possibile utilizzare il riferimento al gruppo di sicurezza (che consente il gruppo di sicurezza ENI come fonte) o consentire l'ingresso dal VPC CIDR.
+ **Connettività alla sottorete**: verifica che le sottoreti selezionate siano in grado di indirizzare il traffico verso il servizio. Se il servizio viene eseguito in una sottorete diversa, verifica che le tabelle di routing consentano il traffico tra di esse.
+ **Disponibilità del servizio**: verifica che il servizio sia in esecuzione e accetti connessioni sulla porta prevista.
+ **Zona di disponibilità non supportata**: verifica che le sottoreti si trovino nelle zone di disponibilità supportate. Esegui `aws ec2 describe-subnets --subnet-ids --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'` e verifica le zone di disponibilità non supportate elencate sopra.
## Eliminare una connessione privata
È possibile eliminare le connessioni private non utilizzate utilizzando la console di AWS gestione o la AWS CLI.
### Eliminare una connessione privata utilizzando la console
1. Apri la console AWS DevOps dell'agente.
1. Nel riquadro di navigazione, scegli **Provider di capacità**, quindi scegli **Connessioni private**.
1. Seleziona il menu **Azioni** per la connessione privata che desideri eliminare e seleziona **Rimuovi**.
La connessione privata verrà visualizzata con lo stato «Rimozione della connessione» mentre l' AWS DevOps agente rimuove il gateway di risorse gestite e ENIs dal tuo VPC. Una volta completata l'eliminazione, la connessione non viene più visualizzata nell'elenco delle connessioni private.
### Eliminare una connessione privata utilizzando la AWS CLI
```
aws devops-agent delete-private-connection \
--name my-mcp-tool-connection
```
La risposta restituisce uno stato di. `DELETE_IN_PROGRESS` AWS DevOps L'agente rimuove il gateway di risorse gestite e lo rimuove ENIs dal tuo VPC. Una volta completata l'eliminazione, la connessione non viene più visualizzata nell'elenco delle connessioni private.
## Configurazione avanzata utilizzando le risorse VPC Lattice esistenti
Se la tua organizzazione utilizza già Amazon VPC Lattice e gestisce le configurazioni delle risorse, puoi creare una connessione privata in modalità autogestita. Invece di fare in modo che AWS DevOps Agent crei un gateway di risorse per te, fornisci l'Amazon Resource Name (ARN) di una configurazione di risorse esistente che punta al servizio di destinazione.
Questo approccio è utile quando:
+ Desideri il pieno controllo sul Resource Gateway e sul ciclo di vita della configurazione delle risorse.
+ È necessario condividere le configurazioni delle risorse tra più AWS account o servizi.
+ Richiedi i log di accesso VPC Lattice per un monitoraggio dettagliato del traffico.
+ Esegui un'architettura di hub-and-spoke rete.
Per creare una connessione privata autogestita con la 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"
}
}'
```
Per ulteriori dettagli sulla configurazione dei gateway di risorse VPC Lattice e sulle configurazioni delle risorse, consulta la Amazon [VPC](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) Lattice User Guide.
## Argomenti correlati
+ [Endpoint VPC (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)
+ [Connessione dei server MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
+ [Configurazione delle funzionalità per Agent AWS DevOps](configuring-capabilities-for-aws-devops-agent.md)
+ [AWS DevOps Sicurezza degli agenti](aws-devops-agent-security.md)
+ [DevOps Autorizzazioni Agent IAM](aws-devops-agent-security-devops-agent-iam-permissions.md)