Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Configuración de las capacidades del AWS DevOps agente
AWS DevOps Las capacidades del agente amplían la funcionalidad de su agente al conectarlo a sus herramientas e infraestructura existentes. Configure estas capacidades para permitir una investigación exhaustiva de incidentes, flujos de trabajo de respuesta automatizados y una integración perfecta con su DevOps ecosistema.
Las siguientes funciones le ayudan a maximizar la eficacia de su DevOps agente:
+ **AWS Configuración de acceso a EKS**: permita la introspección de los clústeres, los registros de los pods y los eventos de los clústeres de Kubernetes para entornos EKS públicos y privados
+ **Integración con Azure**: conecte las suscripciones de Azure y DevOps las organizaciones de Azure para investigar los recursos de Azure y correlacionar las DevOps implementaciones de Azure con los incidentes
+ **Integración de tuberías CI/CD**: Connect GitHub y GitLab canalizaciones para correlacionar las implementaciones con los incidentes y rastrear los cambios de código durante las investigaciones
+ **Conexiones al servidor MCP**: amplíe las capacidades de investigación conectando herramientas de observabilidad externas y sistemas de monitoreo personalizados mediante el protocolo Model Context
+ ** AWS Acceso multicuenta**: configure AWS cuentas secundarias para investigar los recursos de toda su organización durante la respuesta a los incidentes
+ **Integración de fuentes de telemetría**: conecte plataformas de monitoreo como Datadog, Dynatrace, Grafana, New Relic y Splunk para un acceso integral a los datos de observabilidad
+ **Integración de tickets y chat**: Connect ServiceNow y Slack para automatizar los flujos de trabajo de respuesta a incidentes y permitir la colaboración en equipo PagerDuty
+ **Configuración de webhook**: permite que los sistemas externos activen automáticamente las investigaciones de los DevOps agentes mediante solicitudes HTTP
+ ** EventBridge Integración con Amazon**: incorpore el AWS DevOps agente a las aplicaciones basadas en eventos mediante el direccionamiento de los eventos del ciclo de vida de investigación y mitigación a los objetivos de Amazon EventBridge
Puede configurar cada capacidad de forma independiente en función de las necesidades específicas de su equipo y del conjunto de herramientas existente. Comience con las integraciones más importantes para su flujo de trabajo de respuesta a incidentes y, a continuación, amplíelas con capacidades adicionales según sea necesario.
# Migración de la versión preliminar pública a la disponibilidad general
Si utilizó AWS DevOps Agent durante la versión preliminar pública, debe actualizar sus funciones de IAM antes del lanzamiento de la versión general. Esta guía explica cómo actualizar las funciones de supervisión y las funciones de operador en sus cuentas.
## ¿Qué está cambiando
1. [Ya no se puede acceder a los historiales de chat bajo demanda durante la vista previa](#on-demand-chat-history-from-public-preview)
1. [Las nuevas políticas gestionadas sustituyen a las políticas disponibles durante la versión preliminar](#new-managed-policies)
1. [Es posible que Agent Spaces tenga un ámbito de acceso a la aplicación IAM Identity Center desactualizado](#reconnect-iam-identity-center-if-applicable)
## Historial de chats bajo demanda obtenido de una vista previa pública
La versión de GA introduce medidas de seguridad adicionales para reforzar los controles de acceso a los historiales de chat. Como resultado de estos cambios, ya no se puede acceder a los historiales de chat bajo demanda del período de versión preliminar pública (antes del 30 de marzo de 2026). Las revistas de investigación y los hallazgos creados durante la vista previa pública no se ven afectados. **Este cambio solo se aplica a las conversaciones de chat a pedido.**
## Nuevas políticas gestionadas
Para GA, AWS proporciona nuevas políticas administradas que sustituyen a las políticas de la era de la versión preliminar:
| Tipo de rol | Quitar | Add (Suma) |
| --- | --- | --- |
| Supervisión | Política administrada de AIOpsAssistantPolicy | Política administrada de AIDevOpsAgentAccessPolicy |
| Operador (IAM e IDC) | Política insertada | Política administrada de AIDevOpsOperatorAppAccessPolicy |
Además, las funciones de operador requieren políticas de confianza actualizadas y las funciones de operador de IDC requieren una nueva política en línea.
### Requisitos previos
+ Acceda a las AWS cuentas en las que están configuradas sus funciones de DevOps agente (cuentas principales y todas las secundarias)
+ Permisos de IAM para modificar las funciones, las políticas y las relaciones de confianza
+ Su ID de Agent Space, su ID de AWS cuenta y su región (visibles en la consola de DevOps Agent)
### Paso 1: Actualizar las funciones de supervisión
Actualiza la función de supervisión en tu cuenta principal y en cada cuenta secundaria. Estos son los roles de Primary/Secondary origen configurados en la pestaña **Capacidades** de su espacio de agente ( primary/secondary rol de ejemplo:`DevOpsAgentRole-AgentSpace-3xj2396z`).
1. En la consola de DevOps agentes, vaya a su espacio de agente y seleccione la pestaña **Capacidades**.
1. Busca la función de supervisión de tus Primary/Secondary fuentes (por ejemplo`DevOpsAgentRole-AgentSpace-3xj2396z`) y selecciona **Editar**.
1. En **Políticas de permisos**, elimina la política `AIOpsAssistantPolicy` AWS gestionada.
1. Seleccione **Añadir permisos**, **Adjuntar políticas** y adjuntar la política `AIDevOpsAgentAccessPolicy` gestionada.
1. Edita la política en línea y sustituye su contenido por lo siguiente, sustituyendo tu ID de cuenta:
```
{
"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 política de confianza para la función de supervisión no requiere cambios. Compruebe que coincida con lo siguiente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnLike": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/*"
}
}
}
]
}
```
+ Repita los pasos 2 a 6 para la función de supervisión en cada cuenta secundaria.
### Paso 2: Actualice el rol de operador (IAM)
1. En la consola del DevOps agente, seleccione la pestaña **Acceso** y busque el rol de operador.
1. En la consola de IAM, elimine la política en línea existente del rol de operador.
1. Seleccione **Añadir permisos**, **Adjuntar políticas y adjuntar** la política `AIDevOpsOperatorAppAccessPolicy` gestionada.
1. Seleccione la pestaña **Relaciones de confianza** y elija **Editar política de confianza**. Sustituya la política de confianza por la siguiente, sustituyendo su ID de cuenta, región e ID de 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/"
}
}
}
]
}
```
### Paso 3: Actualizar las funciones de los operadores (IDC)
Si utiliza el Centro de identidad de IAM con DevOps un agente, actualice cada función de operador de IDC.
1. En la consola de IAM, vaya a **Funciones** y busque `WebappIDC` las funciones de su DevOps agente en IDC (por ejemplo,). `DevOpsAgentRole-WebappIDC-`
1. Para cada función de IDC:
a. Elimine la política en línea existente.
b. Seleccione **Añadir permisos**, **Adjuntar políticas** y adjuntar la política `AIDevOpsOperatorAppAccessPolicy` gestionada.
c. Seleccione la pestaña **Relaciones de confianza** y elija **Editar política de confianza**. Sustituya la política de confianza por la siguiente, sustituyendo su ID de cuenta, región e ID de 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 nueva política en línea con los siguientes permisos, sustituyéndola por tu ID de cuenta:
```
{
"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/*"
]
}
]
}
```
## Vuelva a conectar el centro de identidad de IAM (si corresponde)
Los espacios de agente creados durante la versión preliminar pública pueden tener una aplicación del Centro de Identidad de IAM configurada con un alcance de acceso obsoleto. En el caso de GA, el ámbito correcto es **`aidevops:read_write`**. Si su aplicación del Centro de Identidad de IAM tiene el alcance anterior (**`awsaidevops:read_write`**), debe desconectar y volver a conectar el Centro de Identidad de IAM.
### ¿Cómo comprobar el alcance de su aplicación en el Centro de Identidad de IAM
Ejecute el siguiente comando AWS CLI para comprobar el alcance de la aplicación IAM Identity Center. **Puede encontrar el ARN de la aplicación en la consola de IAM Identity Center, en Aplicaciones.**
```
aws sso-admin list-application-access-scopes \
--application-arn arn:aws:sso:::application//
```
El resultado debe mostrar el alcance correcto: **`aidevops:read_write`**
```
{
"Scopes": [
{
"Scope": "aidevops:read_write"
}
]
}
```
Si se muestra el alcance **`awsaidevops:read_write`**, significa que está desactualizado. Siga los pasos que se indican a continuación para actualizarlo.
### ¿Cómo volver a conectar el Centro de Identidad de IAM
El alcance de acceso de una aplicación AWS gestionada del Centro de Identidad de IAM no se puede actualizar directamente. Debe desconectarse y volver a conectarse:
1. En la consola del AWS DevOps agente, vaya a su espacio de agente y seleccione la pestaña **Acceso**.
1. Seleccione **Desconectar** junto a la configuración del centro de identidad de IAM.
1. Confirme la desconexión.
1. Elija **Connect** para volver a configurar el Centro de identidad de IAM. El servicio crea una nueva aplicación del IAM Identity Center con el alcance correcto.
1. Reasigne los usuarios y grupos a la nueva aplicación en la consola del IAM Identity Center.
**importante**
Al desconectarse, se elimina el historial de chat y artefactos de los usuarios individuales asociado a las cuentas de usuario del IAM Identity Center. Los usuarios deberán volver a iniciar sesión después de volver a conectarse.
## Verificación
Tras completar todos los pasos:
1. Regrese a la consola del DevOps agente y compruebe que no aparecen errores de permisos en la pestaña Agent Space **Access**.
1. Pruebe la aplicación web del operador para confirmar que se carga y funciona correctamente.
1. Si utilizas IDC, verifica que los usuarios puedan autenticarse y acceder a la experiencia del operador.
## Resolución de problemas
**Errores de permiso denegado tras la migración**
+ Compruebe que `AIOpsAssistantPolicy` se haya eliminado y que `AIDevOpsAgentAccessPolicy` esté asociado a las funciones de supervisión.
+ Compruebe que se hayan eliminado las políticas integradas antiguas y `AIDevOpsOperatorAppAccessPolicy` que estén asociadas a las funciones de los operadores.
+ Compruebe que las políticas de confianza de los operadores incluyan`sts:TagSession`.
+ Confirme que ha sustituido todos los valores de marcador de posición (````,,``) por valores reales.
**Las cuentas secundarias no funcionan**
+ La función de supervisión de cada cuenta secundaria debe actualizarse de forma independiente. Inicie sesión en cada cuenta y repita el paso 1.
**Fallos de autenticación de IDC**
+ Compruebe que la política de confianza de IDC incluya tanto la `sts:TagSession` sentencia`sts:AssumeRole`/como la `TrustedIdentityPropagation` sentencia.
+ Confirme la política en línea con `sso:ListInstances``sso:DescribeInstance`, y `identitystore:DescribeUser` se creó.
**Falta el historial de chats bajo demanda tras la migración**
+ No se podrá acceder a los historiales de chat bajo demanda del período de vista previa pública tras su lanzamiento en GA. Este comportamiento es de esperar debido a las medidas de seguridad mejoradas introducidas en Georgia. Los diarios de investigación y los resultados de la versión preliminar pública no se ven afectados.
# AWS Configuración de acceso a EKS
Puede permitir que AWS DevOps Agent investigue los problemas en sus clústeres de Amazon EKS ejecutando `kubectl` comandos de solo lectura en clústeres públicos y privados. Puede conectar cualquier número de clústeres de EKS al mismo espacio de agente.
Una vez conectado, el agente puede ayudar a diagnosticar problemas operativos en los clústeres: describe los recursos, recupera los registros de los módulos, inspecciona los eventos del clúster, comprueba el estado de los nodos y mucho más. El agente no puede crear, modificar ni eliminar ningún recurso del clúster.
## Requisitos previos
Antes de configurar el acceso a EKS, asegúrese de que el modo de autenticación del clúster de EKS incluya la API de EKS. Puede comprobarlo en la pestaña **Acceso** de la [consola de Amazon EKS](https://console.aws.amazon.com/eks). Si el modo no incluye la API EKS, seleccione un modo que sí la incluya antes de continuar.
## Configuración
Estos pasos deben completarse desde la [consola de Amazon EKS](https://console.aws.amazon.com/eks) para cada clúster para el que desee crear una entrada de acceso. Puede encontrar el ARN de su rol de IAM en su espacio de agente ([Creación de un espacio de agentes](getting-started-with-aws-devops-agent-creating-an-agent-space.md)consulte) en **Capacidades > Nube > Fuente principal > Editar**.
1. Ve a la pestaña **Acceso**. Si el modo de autenticación ya indica API EKS, puede añadir entradas de acceso. De lo contrario, seleccione un modo que incluya la API EKS.
1. En la pestaña Acceso, cree una nueva entrada de acceso de IAM. Copie el ARN del rol de IAM de la fuente principal en la nube e introdúzcalo como el principal de IAM para la entrada de acceso. Haga clic en **Next (Siguiente)**.
1. Selecciona la política de AIOps AssistantPolicy acceso a **Amazon AWS ** gestionado y selecciona **Clúster** para el ámbito de acceso. (Como alternativa, si quieres que el agente acceda solo a determinados espacios de nombres, selecciona los espacios de nombres de **Kubernetes** que desees). **Haz clic en **Añadir política** y, a continuación, en Siguiente.**
1. Revise los cambios y confirme que se eligieron la política de entrada de acceso y el rol de IAM correctos, y cree su entrada de acceso haciendo clic en **«Crear».**
Para comprobar que el acceso a EKS se configuró correctamente, navegue hasta la aplicación Operator e inicie una nueva investigación y formule al agente una pregunta sobre su clúster, como «incluir todos los pods en el espacio de nombres predeterminado» o «mostrarme los eventos recientes de mi clúster».
## Resolución de problemas
Si el agente no puede acceder a tu clúster, comprueba que la entrada de acceso utiliza el ARN del rol de IAM correcto que se muestra en el cuadro de diálogo de configuración y que se adjunta la política de acceso de **AIOpsAssistantPolicyAmazon**.
# Conexión de Azure
La integración con Azure permite a AWS DevOps Agent investigar los recursos de su entorno de Azure y correlacionar las implementaciones en DevOps canalización de Azure con los incidentes operativos. Al conectar Azure, el agente obtiene visibilidad de su infraestructura de Azure y puede realizar un análisis de la causa raíz tanto en los recursos de Azure como en AWS los de Azure.
La integración de Azure consta de dos capacidades independientes:
+ **Recursos de Azure**: permite al agente descubrir e investigar los recursos de la nube de Azure, como máquinas virtuales, clústeres de Azure Kubernetes Service (AKS), bases de datos y componentes de red. El agente usa Azure Resource Graph para consultar sus recursos durante la investigación de incidentes.
+ **Azure DevOps**: permite al agente acceder a los DevOps repositorios de Azure y al historial de ejecución de las canalizaciones. El agente puede correlacionar los cambios de código y las implementaciones con los incidentes para ayudar a identificar las posibles causas fundamentales.
Cada capacidad se registra a nivel de AWS cuenta y, a continuación, se puede asociar a espacios de agentes individuales.
## Métodos de registro
AWS DevOps El agente admite dos métodos para conectarse a Azure:
+ Consentimiento del **administrador: un flujo simplificado basado en el consentimiento** en el que se autoriza la aplicación AWS DevOps Agent Entra en su inquilino de Azure. En la consola, aparece como la opción de consentimiento del **administrador**. Este método requiere iniciar sesión con una cuenta que tenga permiso para otorgar el consentimiento de administrador en Microsoft Entra ID.
+ **Registro de aplicaciones**: un enfoque autogestionado en el que puede crear su propia aplicación Entra con credenciales de identidad federadas mediante Outbound Identity Federation. En la consola, aparece como la opción de registro de **aplicaciones**. Este método es adecuado cuando se necesita un mayor control sobre la configuración de la aplicación o cuando los permisos de consentimiento del administrador no están disponibles.
Ambos métodos ofrecen las mismas capacidades. Puede usar uno o ambos métodos en la misma AWS cuenta.
## Limitaciones conocidas
+ **Consentimiento del administrador: una AWS cuenta por inquilino** de Azure: cada inquilino de Azure solo puede tener su aplicación AWS DevOps Agent Entra asociada a una AWS cuenta a la vez. Para asociar el mismo inquilino a una AWS cuenta diferente, primero debe anular el registro existente.
+ **Registro de aplicaciones: aplicación única por registro**: cada registro de aplicación debe usar una aplicación diferente (ID de cliente). No puede registrar varias configuraciones con el mismo ID de cliente.
+ **Azure DevOps: acceso al código fuente:** la DevOps integración de Azure proporciona acceso al historial de ejecución de la canalización, independientemente de dónde esté alojado el código fuente. Sin embargo, para acceder al código fuente real, el repositorio debe estar conectado por separado a través de un proveedor de código fuente compatible (por ejemplo,[Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md)). No se puede acceder directamente al código fuente alojado en Bitbucket a través de la DevOps integración con Azure.
## Temas
+ [Conexión de los recursos de Azure](connecting-azure-connecting-azure-resources.md)
+ [Conexión de Azure DevOps](connecting-azure-connecting-azure-devops.md)
# Conexión de los recursos de Azure
La integración de Azure Resources permite al AWS DevOps agente descubrir e investigar los recursos de sus suscripciones de Azure durante la investigación de incidentes. El agente usa Azure Resource Graph para descubrir recursos y puede acceder a las métricas, los registros y los datos de configuración de todo el entorno de Azure.
Esta integración sigue un proceso de dos pasos: registre Azure a nivel de AWS cuenta y, a continuación, asocie suscripciones específicas de Azure a Agent Spaces individuales.
## Requisitos previos
Antes de conectar Azure Resources, asegúrese de tener:
+ Acceso a la consola del AWS DevOps agente
+ Una cuenta de Azure con acceso a la suscripción de destino
+ Para el método de consentimiento del administrador: una cuenta con permiso para otorgar el consentimiento del administrador en Microsoft Entra ID
+ Para el método de registro de aplicaciones: una aplicación Entra con permisos para configurar las credenciales de identidad federadas y una [federación de identidades salientes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) habilitada en su cuenta AWS
**Nota:** También puede iniciar el registro desde un espacio de agente. Vaya a **Fuentes secundarias**, haga clic en **Agregar** y seleccione **Azure**. Si Azure Cloud aún no está registrado, la consola le guiará primero por el proceso de registro.
## Cómo registrar los recursos de Azure mediante el consentimiento del administrador
El método de consentimiento del administrador utiliza un flujo basado en el consentimiento con la aplicación administrada por el AWS DevOps agente.
### Paso 1: iniciar el registro
1. Inicie sesión en la consola AWS de administración y navegue hasta la consola del AWS DevOps agente
1. Vaya a la página **de proveedores de capacidades**
1. Busque la sección **Azure Cloud** y haga clic en **Registrar**
1. Seleccione el método de registro con **el consentimiento del administrador**
### Paso 2: Completar el consentimiento del administrador
1. Revisa los permisos que se solicitan
1. Haga clic para continuar: se le redirigirá a la página de consentimiento del administrador de Microsoft Entra
1. Inicia sesión con una cuenta principal de usuario que tenga permiso para otorgar el consentimiento de administrador
1. Revisa la solicitud de AWS DevOps agente y otorga tu consentimiento
### Paso 3: Completar la autorización del usuario
1. Tras el consentimiento del administrador, se le solicitará la autorización de usuario para verificar su identidad como miembro del arrendatario autorizado
1. Inicie sesión con una cuenta que pertenezca al mismo inquilino de Azure
1. Tras la autorización, se le redirigirá de nuevo a la consola del AWS DevOps agente con un estado correcto
### Paso 4: Asignar funciones
Consulte [Asignación de roles de Azure](#assigning-azure-roles) a continuación. Busque un **AWS DevOps agente** al seleccionar los miembros.
## Registro de recursos de Azure mediante el registro de aplicaciones
El método de registro de aplicaciones utiliza su propia aplicación Entra con credenciales de identidad federadas.
### Paso 1: Iniciar el registro
1. En la consola del AWS DevOps agente, vaya a la página **de proveedores de capacidades**
1. Busque la sección **Azure Cloud** y haga clic en **Registrar**
1. Seleccione el método de **registro de la aplicación**
### Paso 2: Crea y configura tu aplicación Entra
Siga las instrucciones que aparecen en la consola para:
1. Habilite la federación de identidades salientes en su AWS cuenta (en la consola de IAM, vaya a **Configuración de la cuenta** → Federación de identidades **salientes**)
1. Cree una aplicación Entra en su ID de Microsoft Entra o utilice una existente
1. Configure las credenciales de identidad federadas en la aplicación
### Paso 3: Proporcione los detalles de registro
Rellene el formulario de registro con:
+ **ID de inquilino**: su identificador de inquilino de Azure
+ **Nombre del inquilino**: nombre visible del inquilino
+ **ID de cliente**: el ID de aplicación (cliente) de la aplicación Entra que creó
+ **Audiencia**: el identificador de audiencia de la credencial federada
### Paso 4: Crear el rol de IAM
Al enviar el registro a través de la consola, se creará automáticamente un rol de IAM. Permite al AWS DevOps agente asumir las credenciales e `sts:GetWebIdentityToken` invocarlas.
### Paso 5: Asignar funciones
Consulte [Asignación de roles de Azure](#assigning-azure-roles) a continuación. Busque la aplicación Entra que creó al seleccionar los miembros.
### Paso 6: Complete el registro
1. Confirme la configuración en la consola del AWS DevOps agente
1. Haga clic en **Enviar** para completar el registro
## Asignación de roles de Azure
Tras el registro, conceda a la aplicación acceso de lectura a su suscripción de Azure. Este paso es el mismo para los métodos de consentimiento del administrador y registro de la aplicación.
1. En el Portal de Azure, navegue hasta la suscripción de destino
1. Vaya a **Control de acceso (IAM**)
1. Haga clic en **Añadir** > **Añadir asignación de funciones**
1. Seleccione el rol de **lector** y haga clic en **Siguiente**
1. Haga clic en **Seleccionar miembros** y busque la aplicación (ya sea **AWS DevOps un agente** para obtener el consentimiento del administrador o su propia aplicación Entra para registrar la aplicación)
1. Seleccione la aplicación y haga clic en **Revisar \$1 asignar**
1. (Opcional) Para permitir que el agente acceda a los clústeres de Azure Kubernetes Service (AKS), complete la siguiente configuración de acceso a AKS.
**Requisito de seguridad:** al director del servicio solo se le debe asignar la función de **lector** (y, opcionalmente, las funciones de solo lectura de AKS que se indican a continuación). La función de lector sirve como límite de seguridad que restringe al agente a operaciones de solo lectura y limita el impacto de los ataques indirectos de inyección inmediata. La asignación de funciones con permisos de escritura o acción aumenta considerablemente el radio de acción de las inyecciones rápidas y puede comprometer los recursos de Azure. AWS DevOps El agente solo realiza operaciones de lectura. El agente no modifica, crea ni elimina los recursos de Azure.
### Configuración de acceso a AKS (opcional)
#### Paso 1: acceso a nivel de Azure Resource Manager (ARM)
Asigne el **rol de usuario del clúster de servicios de Azure Kubernetes a la aplicación**.
En Azure Portal, vaya a **Suscripciones** → seleccione una suscripción → **Control de acceso (IAM)** → **Agregar asignación de funciones → seleccione la función** de **usuario del clúster de servicios de Kubernetes de Azure** → asígnela a la aplicación (ya sea **AWS DevOps agente** para obtener el consentimiento del administrador o su propia aplicación Entra para registrar la aplicación).
Esto cubre todos los clústeres de AKS de la suscripción. Para abarcar clústeres específicos, en su lugar, asígnelo a nivel de grupo de recursos o de clúster individual.
#### Paso 2: Acceso a la API de Kubernetes
Elige una opción en función de la configuración de autenticación de tu clúster:
**Opción A: Control de acceso basado en roles (RBAC) de Azure para Kubernetes (recomendado)**
1. ****Habilite Azure RBAC en el clúster si aún no lo ha hecho: Azure Portal → Clúster de AKS → Configuración → **Configuración de **seguridad** → Autenticación y autorización → seleccione** Azure RBAC****
1. Asigne una función de solo lectura: Azure Portal → **Suscripciones** → seleccionar suscripción → **Control de acceso (IAM)** → **Agregar asignación de funciones → seleccionar **Azure Kubernetes** Service RBAC Reader → asignar** a la aplicación
Esto cubre todos los clústeres de AKS de la suscripción.
**Opción B: Azure Active Directory (Azure AD) \$1 Kubernetes RBAC**
Úselo si su clúster ya usa la configuración de autenticación predeterminada de Azure AD y prefiere no habilitar el RBAC de Azure. Esto requiere una configuración por clúster. `kubectl`
1. Guarde el siguiente manifiesto como`devops-agent-reader.yaml`:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-agent-reader
rules:
- apiGroups: [""]
resources: ["namespaces", "pods", "pods/log", "services", "events", "nodes"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
verbs: ["get", "list"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: devops-agent-reader-binding
subjects:
- kind: User
name: ""
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: devops-agent-reader
apiGroup: rbac.authorization.k8s.io
```
1. ``Sustitúyalo por el ID de objeto del director de servicio. Para encontrarlo: Azure Portal → Entra ID → Aplicaciones empresariales → busque el nombre de la aplicación (ya sea **AWS DevOps agente** para obtener el consentimiento del administrador o su propia aplicación Entra para registrar la aplicación).
1. Aplíquelo a cada clúster:
```
az aks get-credentials --resource-group --name
kubectl apply -f devops-agent-reader.yaml
```
**Nota:** No se admiten los clústeres que utilizan solo cuentas locales (sin Azure AD). Le recomendamos que habilite la integración de Azure AD en su clúster para usar esta función.
### Función personalizada con menos privilegios (opcional)
Para un control de acceso más estricto, puede crear un rol de Azure personalizado que se limite únicamente a los proveedores de recursos que utiliza el AWS DevOps agente, en lugar del amplio rol de lector:
```
{
"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}"
]
}
```
## Asociar una suscripción a un espacio de agente
Tras registrar Azure a nivel de cuenta, asocie suscripciones específicas a sus Agent Spaces:
1. En la consola de AWS DevOps agentes, seleccione su espacio de agente
1. Ve a la pestaña **Capacidades**
1. En la sección **Fuentes secundarias**, haga clic en **Agregar**
1. Selecciona **Azure**
1. Proporcione el **identificador de suscripción** de la suscripción de Azure que desee asociar
1. Haga clic en **Agregar** para completar la asociación
Puede asociar varias suscripciones al mismo espacio de agente para que el agente tenga visibilidad en todo el entorno de Azure.
## Administrar las conexiones de Azure Resources
+ **Visualización de las suscripciones conectadas**: en la pestaña **Capacidades**, la sección **Fuentes secundarias** muestra todas las suscripciones de Azure conectadas.
+ **Eliminar una suscripción**: para desconectar una suscripción de un Agent Space, selecciónela en la lista de **fuentes secundarias** y haga clic en **Eliminar**. Esto no afecta al registro a nivel de cuenta.
+ **Eliminar el registro**: para eliminar por completo el registro en la nube de Azure, vaya a la página de **proveedores de capacidades** y elimine el registro. Primero se deben eliminar todas las asociaciones de Agent Space.
# Conexión de Azure DevOps
DevOps La integración con Azure permite a AWS DevOps Agent acceder a los repositorios y al historial de ejecución de las canalizaciones de su DevOps organización de Azure. El agente puede correlacionar los cambios de código y las implementaciones con los incidentes operativos para ayudar a identificar las posibles causas fundamentales.
**Nota:** DevOps Las canalizaciones de Azure pueden usar código fuente de Azure Repos o Bitbucket. GitHub La DevOps integración de Azure proporciona acceso al historial de ejecución de la canalización, independientemente del proveedor de origen. Sin embargo, para acceder al código fuente real durante las investigaciones, el repositorio debe estar conectado por separado mediante una integración compatible, por ejemplo[Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md). No se puede acceder directamente al código fuente de Bitbucket a través de esta integración.
Esta integración sigue un proceso de dos pasos: registra Azure DevOps a nivel de AWS cuenta y, a continuación, asocia proyectos específicos a espacios de agente individuales.
## Requisitos previos
Antes de conectar Azure DevOps, asegúrese de tener:
+ Acceso a la consola del AWS DevOps agente
+ Una DevOps organización de Azure con al menos un proyecto que contenga un repositorio y un historial de canalizaciones
+ Permisos para agregar usuarios a su DevOps organización de Azure
+ Para el método de consentimiento del administrador: una cuenta con permiso para otorgar el consentimiento del administrador en Microsoft Entra ID
+ Para el método de registro de aplicaciones: una aplicación Entra con permisos para configurar las credenciales de identidad federadas y una [federación de identidades salientes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html) habilitada en su cuenta AWS
**Nota:** También puede iniciar el registro desde un espacio de agente. Ve a la sección **Pipelines**, haz clic en **Agregar** y selecciona **Azure DevOps**. Si Azure aún no DevOps está registrado, la consola le guiará primero por el proceso de registro.
## Registrar Azure con DevOps el consentimiento del administrador
El método de consentimiento del administrador utiliza un flujo basado en el consentimiento con la aplicación administrada por el AWS DevOps agente.
### Paso 1: iniciar el registro
1. Inicie sesión en la consola AWS de administración y navegue hasta la consola del AWS DevOps agente
1. Vaya a la página **de proveedores de capacidades**
1. Busque la DevOps sección de **Azure** y haga clic en **Registrar**
1. Introduzca el **nombre de su DevOps organización de Azure** cuando se le solicite
### Paso 2: Completar el consentimiento del administrador
1. Haga clic para continuar: se le redirigirá a la página de consentimiento del administrador de Microsoft Entra
1. Inicia sesión con una cuenta principal de usuario que tenga permiso para otorgar el consentimiento de administrador
1. Revisa la solicitud de AWS DevOps agente y otorga tu consentimiento
### Paso 3: Completar la autorización del usuario
1. Tras el consentimiento del administrador, se le solicitará la autorización de usuario para verificar su identidad como miembro del arrendatario autorizado
1. Inicie sesión con una cuenta que pertenezca al mismo inquilino de Azure
1. Tras la autorización, se le redirigirá de nuevo a la consola del AWS DevOps agente con un estado correcto
### Paso 4: Conceder el acceso en Azure DevOps
Consulte [Otorgar acceso en Azure DevOps](#granting-access-in-azure-devops) a continuación. Busque **AWS DevOps Agent** al agregar usuarios.
## Registrar Azure DevOps mediante el registro de aplicaciones
El registro de aplicaciones se comparte entre Azure Resources y Azure DevOps. Si ya ha completado el registro de aplicaciones para los recursos de Azure, puede pasar a [Conceder acceso a Azure DevOps](#granting-access-in-azure-devops).
### Paso 1: Inicie el registro de la aplicación ADO
1. En la consola del AWS DevOps agente, vaya a la página **de proveedores de capacidades**
1. Busque la sección **Azure Cloud** y haga clic en **Registrar**
1. Seleccione el método de **registro de la aplicación**
### Paso 2: Crea y configura tu aplicación Entra
Siga las instrucciones que aparecen en la consola para:
1. Habilite la federación de identidades salientes en su AWS cuenta (en la consola de IAM, vaya a **Configuración de la cuenta** → Federación de identidades **salientes**)
1. Cree una aplicación Entra en su ID de Microsoft Entra o utilice una existente
1. Configure las credenciales de identidad federadas en la aplicación
### Paso 3: Proporcione los detalles de registro
Rellene el formulario de registro con:
+ **ID de inquilino**: su identificador de inquilino de Azure
+ **Nombre del inquilino**: nombre visible del inquilino
+ **ID de cliente**: el ID de aplicación (cliente) de la aplicación Entra
+ **Audiencia**: el identificador de audiencia de la credencial federada
### Paso 4: Crear el rol de IAM
Al enviar el registro a través de la consola, se creará automáticamente un rol de IAM. Permite al AWS DevOps agente asumir las credenciales e `sts:GetWebIdentityToken` invocarlas.
### Paso 5: Complete el registro
1. Confirme la configuración en la consola del AWS DevOps agente
1. Haga clic en **Enviar** para completar el registro
### Paso 6: Conceder el acceso en Azure DevOps
Consulte [Otorgar acceso en Azure DevOps](#granting-access-in-azure-devops) a continuación. Busque la aplicación Entra que creó durante el registro de la aplicación al agregar usuarios.
## Otorgar acceso en Azure DevOps
Tras el registro, conceda acceso a la aplicación a su DevOps organización de Azure. Este paso es el mismo para los métodos de consentimiento del administrador y registro de la aplicación.
1. En Azure DevOps, vaya a **Configuración de la organización** > **Usuarios** > **Agregar usuarios**
1. Busque la aplicación (ya sea **AWS DevOps un agente** para obtener el consentimiento del administrador o su propia aplicación Entra para el registro de la aplicación)
1. Establece el nivel de acceso en **Básico**
1. En **Añadir a proyectos**, seleccione los proyectos a los que desee que acceda el agente
1. En ** DevOps Grupos de Azure**, seleccione **Project Readers**
1. Haga clic en **Agregar** para completar
**Requisito de seguridad:** asigne solo el grupo de **lectores del proyecto**. El acceso de solo lectura sirve como límite de seguridad que restringe al agente a operaciones de solo lectura y limita el impacto de los ataques indirectos de inyección inmediata. La asignación de permisos de escritura o acción a grupos aumenta considerablemente el radio de acción de las inyecciones rápidas y puede comprometer los recursos de Azure. DevOps
## Asociar un proyecto a un espacio de agente
Tras registrar Azure DevOps a nivel de cuenta, asocie proyectos específicos a sus Agent Spaces:
1. En la consola de AWS DevOps Agent, selecciona tu Agent Space
1. Ve a la pestaña **Capacidades**
1. **En la sección **Canalizaciones**, haga clic en Añadir**
1. Seleccione **Azure DevOps** de la lista de proveedores disponibles
1. Seleccione el proyecto en el menú desplegable de proyectos disponibles
1. Haga clic en **Añadir** para completar la asociación
## Administrar DevOps las conexiones de Azure
+ **Visualización de los proyectos conectados**: en la pestaña **Capacidades**, la sección **Pipelines** muestra todos los DevOps proyectos de Azure conectados.
+ **Eliminar un proyecto****: para desconectar un proyecto de un Agent Space, selecciónelo en la sección **Pipelines** y haga clic en Eliminar.**
+ **Eliminar el registro**: para eliminar el DevOps registro de Azure por completo, vaya a la página **de proveedores de capacidades** y elimine el registro. Primero se deben eliminar todas las asociaciones de Agent Space.
# Conexión a CI/CD tuberías
La integración de la canalización de CI/CD permite a AWS DevOps Agent monitorear las implementaciones y correlacionar los cambios de código con los incidentes operativos durante las investigaciones. Al conectar a sus CI/CD proveedores, el agente puede realizar un seguimiento de los eventos de despliegue y asociarlos con AWS recursos para ayudar a identificar las posibles causas fundamentales durante la respuesta a los incidentes.
AWS DevOps El agente permite la integración con CI/CD las plataformas más populares mediante un proceso de dos pasos:
1. **Registro a nivel de cuenta**: registre a su CI/CD proveedor una vez a nivel de cuenta AWS
1. **Conexión con Agent Space**: conecte proyectos o repositorios específicos a Agent Spaces individuales en función de las necesidades de su organización
Este enfoque le permite compartir los registros de CI/CD proveedores en varios espacios de agentes y, al mismo tiempo, mantener un control pormenorizado sobre los proyectos que supervisa cada espacio.
## Proveedores compatibles CI/CD
AWS DevOps El agente es compatible con las siguientes CI/CD plataformas:
+ **GitHub**— Conecta los repositorios desde [GitHub.com](http://GitHub.com) mediante la GitHub aplicación AWS DevOps Agent.
+ **GitLab**— Conecta proyectos desde [GitLab.com,](http://gitlab.com) GitLab instancias gestionadas o GitLab despliegues autohospedados de acceso público.
**Temas**
+ [Conectando GitHub](connecting-to-cicd-pipelines-connecting-github.md)
+ [Conectando GitLab](connecting-to-cicd-pipelines-connecting-gitlab.md)
# Conectando GitHub
GitHub La integración permite al AWS DevOps agente acceder a los repositorios de códigos y recibir los eventos de despliegue durante la investigación de incidentes. Esta integración sigue un proceso de dos pasos: el registro a nivel de cuenta y, a continuación GitHub, la conexión de repositorios específicos a los espacios de agente individuales.
AWS DevOps El agente es compatible con GitHub instancias .com (SaaS) y GitHub Enterprise Server (autohospedadas).
## Requisitos previos
Antes de conectarse GitHub, asegúrese de tener:
+ Acceso a la consola de administración del AWS DevOps agente
+ Una cuenta GitHub de usuario o una organización con permisos de administrador
+ Autorización para instalar GitHub aplicaciones en tu cuenta u organización
Para GitHub Enterprise Server, también necesitas:
+ Una instancia de GitHub Enterprise Server (versión 3.x o posterior) accesible a través de HTTPS
+ La URL HTTPS de su instancia de GitHub Enterprise Server (por ejemplo,`https://github.example.com`)
+ (Opcional) Una conexión privada, si su instancia de GitHub Enterprise Server no es de acceso público
## Registrarse GitHub (a nivel de cuenta)
GitHub se registra a nivel de AWS cuenta y se comparte entre todos los espacios de agentes de esa cuenta. Solo necesita registrarse GitHub una vez por AWS cuenta.
### Paso 1: Dirígete a los proveedores de gasoductos
1. Inicie sesión en la consola AWS de administración
1. Navegue hasta la consola del AWS DevOps agente
1. Vaya a la pestaña **Capacidades**
1. En la sección **Pipeline**, haga clic en **Agregar**
1. Seleccione **GitHub**de la lista de proveedores disponibles
Si GitHub aún no se ha registrado, se le pedirá que lo registre primero.
### Paso 2: elige el tipo de conexión
En la pantalla « GitHub Registrar cuenta/organización», selecciona si te conectas como usuario u organización:
+ **Usuario**: su GitHub cuenta personal con un nombre de usuario y un perfil
+ **Organización**: una GitHub cuenta compartida en la que varias personas pueden colaborar en varios proyectos a la vez
Si te estás conectando a una instancia de GitHub Enterprise Server, marca la casilla **Usar GitHub Enterprise Server** e introduce la URL HTTPS de la instancia (por ejemplo,`https://github.example.com`).
Si su instancia de GitHub Enterprise Server no es de acceso público, si lo desea, puede configurar una conexión privada para que el AWS DevOps agente pueda acceder a su instancia de forma segura. Para obtener más información, consulte [Conexión a herramientas alojadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
**nota**
**No incluyas `/api/v3` ni ninguna ruta final en la URL; introduce solo la URL base.
### Paso 3: Configura la aplicación GitHub
Haga clic en **Enviar** para iniciar el proceso de configuración de la aplicación. Los siguientes pasos varían en función de si se conecta a GitHub .com o GitHub Enterprise Server.
#### Para GitHub .com
1. Se te redirigirá a GitHub para instalar la GitHub aplicación AWS DevOps Agent.
1. Seleccione en qué cuenta u organización desea instalar la aplicación.
1. La aplicación permite al AWS DevOps agente recibir eventos de los repositorios conectados, incluidos los eventos de despliegue.
#### Para GitHub Enterprise Server
GitHub Enterprise Server usa un flujo de manifiesto de GitHub aplicaciones, que configura automáticamente una nueva GitHub aplicación en la instancia. Esto implica dos redireccionamientos a tu instancia de GitHub Enterprise Server.
1. El navegador se redirigirá a la página «Crear GitHub aplicación» de la instancia de GitHub Enterprise Server.
1. Verás el nombre de la aplicación rellenado previamente. No dudes en cambiar el nombre según sea necesario. Haz clic en **Crear GitHub aplicación**.
1. Se te redirigirá de nuevo a AWS DevOps Agent, que intercambia el código del manifiesto por las credenciales de la aplicación.
### Paso 4: Selecciona los repositorios y completa la instalación
1. Verás la página de **instalación y autorización** de la GitHub aplicación.
1. Selecciona a qué repositorios quieres permitir el acceso de la aplicación:
+ **Todos los repositorios**: otorga acceso a todos los repositorios actuales y futuros
+ **Selecciona solo repositorios**: elige repositorios específicos de tu cuenta u organización
1. Haz clic en **Instalar y autorizar**.
1. Se le redirigirá de nuevo a la consola del AWS DevOps agente, donde GitHub aparecerá como registrado a nivel de cuenta.
## Conectar los repositorios a un espacio de agentes
Tras registrarse GitHub a nivel de cuenta, puede conectar repositorios específicos a espacios de agente individuales:
1. En la consola de AWS DevOps agentes, selecciona tu espacio de agente
1. Ve a la pestaña **Capacidades**
1. En la sección **Pipeline**, haga clic en **Agregar**
1. Seleccione **GitHub**de la lista de proveedores disponibles
1. Seleccione el subconjunto de repositorios correspondiente a este espacio de agentes
1. Haga clic en **Agregar** para completar la conexión
Puede conectar diferentes conjuntos de repositorios a diferentes espacios de agentes en función de las necesidades de su organización.
## Entender la aplicación GitHub
La GitHub aplicación AWS DevOps Agent:
+ Solicita acceso de solo lectura a tus repositorios
+ Recibe eventos de despliegue y otros eventos del repositorio
+ Permite al AWS DevOps agente correlacionar los cambios de código con los incidentes operativos
+ Se puede desinstalar en cualquier momento a través de su configuración GitHub
En el caso de GitHub Enterprise Server, la GitHub aplicación se crea automáticamente en la instancia durante el registro. Puede administrar el acceso al repositorio de la aplicación o desinstalarla **desde Configuración > Aplicaciones > GitHub Aplicaciones instaladas**. Para eliminar por completo la definición de la aplicación, ve a **Configuración > Configuración del desarrollador > GitHub Aplicaciones**.
## Administrar GitHub las conexiones
+ **Actualización del acceso a los repositorios**: para cambiar a qué repositorios puede acceder la GitHub aplicación, vaya a la configuración de su GitHub cuenta u organización (o a la configuración de la instancia de GitHub Enterprise Server), vaya a GitHub las aplicaciones instaladas y modifique la configuración de la aplicación AWS DevOps Agent.
+ **Visualización de los repositorios conectados**: en la consola del AWS DevOps agente, seleccione su espacio de agente y vaya a la pestaña Capacidades para ver los repositorios conectados en la sección Pipeline.
+ **Eliminar una GitHub conexión****: para desconectarse GitHub de un espacio de agentes, seleccione la conexión en la sección Pipeline y haga clic en Eliminar.** Para desinstalar la GitHub aplicación por completo, desinstálela de la configuración de su GitHub cuenta u organización. En el caso de GitHub Enterprise Server, dado que la GitHub aplicación se crea directamente en la instancia durante el registro, si lo desea, puede limpiarla por completo realizando las dos acciones siguientes:
+ **Desinstale la aplicación**: vaya a **Configuración > Aplicaciones > GitHub Aplicaciones instaladas**, haga clic en **Configurar** en la aplicación y, a continuación, desinstálela.
+ **Elimine la aplicación**: vaya a **Configuración > Configuración del desarrollador > GitHub Aplicaciones**, seleccione la aplicación, vaya a la pestaña **Opciones avanzadas** y elija **Eliminar GitHub aplicación**. **Advertencia:** la eliminación de la GitHub aplicación es permanente y no se puede deshacer. Si la elimina, tendrá que volver a registrar GitHub Enterprise Server desde el principio en la consola del AWS DevOps agente para crear una nueva aplicación.
# Conectando GitLab
GitLab La integración permite a AWS DevOps Agent monitorear los despliegues desde GitLab Pipelines para fundamentar las investigaciones causales durante la respuesta a los incidentes. Esta integración sigue un proceso de dos pasos: el registro a nivel de cuenta y, a continuación GitLab, la conexión de proyectos específicos con los espacios de agente individuales.
## Registro GitLab (a nivel de cuenta)
GitLab se registra a nivel de AWS cuenta y se comparte entre todos los espacios de agentes de esa cuenta. Los espacios de agente individuales pueden entonces elegir qué proyectos específicos se van a aplicar a su espacio de agente.
### Paso 1: Dirígete a los proveedores en proceso
1. Inicie sesión en la consola AWS de administración
1. Navegue hasta la consola del AWS DevOps agente
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde el panel de navegación lateral)
1. Busque **GitLab**en la sección Proveedores **disponibles** en **Pipeline** y haga clic en **Registrarse**
### Paso 2: Configurar la GitLab conexión
En la página GitLab de registro, configure lo siguiente:
**Tipo de conexión**: seleccione si se va a conectar como persona o como grupo:
+ **Personal** (predeterminada): tu cuenta de GitLab usuario individual con un nombre de usuario y un perfil
+ **Grupo**: en GitLab, los grupos se utilizan para gestionar uno o más proyectos relacionados al mismo tiempo
**GitLab tipo de instancia**: elige el tipo de GitLab instancia al que te vas a conectar:
+ **GitLab.com** (predeterminado): el GitLab servicio público
+ **Autohospedado y de acceso público GitLab**: marca la casilla **Usar punto de conexión GitLab autohospedado** y proporciona la URL de tu instancia GitLab
**nota**
**Actualmente, solo se admiten GitLab las instancias de acceso público.
**Token de acceso**: proporciona un token de acceso GitLab personal:
1. En otra pestaña del navegador, inicia sesión en tu GitLab cuenta
1. Ve a la configuración de usuario y selecciona **Tokens de acceso**
1. Cree un nuevo token de acceso personal con los siguientes permisos:
+ `read_repository`— Necesario para acceder al contenido del repositorio
+ `read_virtual_registry`— Necesario para acceder a la información del registro virtual
+ `read_registry`— Necesario para acceder a la información del registro
+ `api`— Necesario para el acceso a la API de lectura y escritura
+ `self_rotate`- Necesario para la rotación de fichas. El AWS DevOps agente no admite esta función actualmente, pero la admitirá más adelante. Añadir ahora evita la necesidad de crear un nuevo token en el futuro.
1. Establezca la caducidad del token en un máximo de 365 días a partir de la fecha actual
1. Copia el token generado
1. Regrese a la consola del AWS DevOps agente
1. Pegue el token en el campo «Token de acceso»
### Paso 3: Completar el registro
**Etiquetas (opcionales)**: añada AWS etiquetas al GitLab registro con fines organizativos.
Haga clic en **Siguiente** para revisar la configuración y, a continuación, en **Enviar** para completar el proceso GitLab de registro. El sistema validará su token de acceso y establecerá la conexión.
## Conectar proyectos a un espacio de agentes
Tras registrarte GitLab a nivel de cuenta, puedes conectar proyectos específicos a espacios de agentes individuales:
1. En la consola de AWS DevOps agentes, selecciona tu espacio de agente
1. Ve a la pestaña **Capacidades**
1. En la sección **Pipeline**, haga clic en **Agregar**
1. Seleccione **GitLab**de la lista de proveedores disponibles
1. Seleccione los GitLab proyectos relevantes para su espacio de agente
1. Haga clic en **Guardar**
AWS DevOps El agente supervisará estos proyectos en busca de despliegues desde GitLab Pipelines para fundamentar las investigaciones causales.
## Administrar las conexiones GitLab
+ **Actualización del token** de acceso: si su token de acceso caduca o necesita actualizarse, puede actualizarlo en la consola del AWS DevOps agente modificando el GitLab registro a nivel de cuenta.
+ **Visualización de los proyectos conectados**: en la consola del AWS DevOps agente, seleccione su espacio de agente y vaya a la pestaña Capacidades para ver los proyectos conectados en la sección Pipeline.
+ **Eliminar la GitLab conexión**: para desconectar GitLab los proyectos de un espacio de agentes, seleccione la conexión en la sección Pipeline y haga clic en **Eliminar**. Para eliminar el GitLab registro por completo, elimínelo primero de todos los Agent Spaces y, a continuación, elimine el registro a nivel de cuenta.
# Conexión de servidores MCP
Los servidores Model Context Protocol (MCP) amplían las capacidades de investigación del AWS DevOps agente al proporcionar acceso a los datos de sus herramientas de observabilidad externas, sistemas de monitoreo personalizados y fuentes de datos operativos. Esta guía explica cómo conectar un servidor MCP a Agent. AWS DevOps
## Requisitos
Antes de conectar un servidor MCP, asegúrese de que el servidor cumpla estos requisitos:
+ **Protocolo de transporte HTTP con capacidad de transmisión**: solo se admiten los servidores MCP que implementan el protocolo de transporte HTTP con capacidad de transmisión.
+ **Soporte de autenticación**: su servidor MCP debe admitir los flujos de autenticación OAuth 2.0 o la autenticación basada en claves o tokens de API.
## Consideraciones de seguridad
Al conectar los servidores MCP al AWS DevOps agente, tenga en cuenta estos aspectos de seguridad:
+ Lista de **herramientas permitidas: debe incluir** en la lista solo las herramientas específicas que su espacio de agente necesita, en lugar de exponer todas las herramientas de su servidor MCP. Consulte [Configurar las herramientas de MCP en un espacio de agente](#configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers) para ver cómo permitir la creación de listas de herramientas por espacio de agente.
Tenga en cuenta que la longitud máxima de cualquier herramienta MCP es de 64.
+ **Riesgos de inyección inmediata: los** servidores MCP personalizados pueden suponer un riesgo adicional de ataques de inyección inmediata. Para obtener más información, consulte [Protección contra inyecciones rápidas: AWS DevOps Agent Security](aws-devops-agent-security.md).
+ **Acceso y herramientas de solo lectura:** solo permita incluir en la lista las herramientas MCP de solo lectura y asegúrese de que las credenciales de autenticación solo permitan el acceso de solo lectura.
Consulte [AWS DevOps Seguridad del agente](aws-devops-agent-security.md) para obtener más información sobre la inyección rápida y el modelo de responsabilidad compartida.
**nota**
Si su servidor MCP está en una red privada, consulte [Conexión a herramientas alojadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)
## Registrar un servidor MCP (a nivel de cuenta)
Los servidores MCP se registran a nivel de AWS cuenta y se comparten entre todos los espacios de agentes de esa cuenta. A continuación, los espacios de agentes individuales pueden elegir qué herramientas específicas necesitan de cada servidor MCP.
### Paso 1: Detalles del servidor MCP
1. Inicie sesión en la consola de AWS administración
1. Navegue hasta la consola del AWS DevOps agente
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde el panel de navegación lateral)
1. **Busque el **servidor MCP** en la sección de proveedores **disponibles** y haga clic en Registrarse**
1. En la página de **detalles del servidor MCP**, introduzca la siguiente información:
+ **Nombre**: introduzca un nombre descriptivo para su servidor MCP
+ **URL del punto final**: introduzca la URL HTTPS completa del punto final de su servidor MCP
+ **Descripción** (opcional): añada una descripción para ayudar a identificar el propósito del servidor
+ **Habilitar el registro dinámico de clientes**: seleccione esta casilla de verificación si desea permitir que el AWS DevOps agente se registre automáticamente en el servidor de autorización de su servidor MCP
1. Haga clic en **Siguiente**.
**nota**
**La URL del punto final del servidor MCP se mostrará en AWS CloudTrail los registros de su cuenta.
### Paso 2: Flujo de autorización
Seleccione el método de autenticación para su servidor MCP:
**OAuth Credenciales de cliente**: si su servidor MCP usa el flujo de credenciales de OAuth cliente:
1. Seleccione las credenciales **OAuth del cliente**
1. Haga clic en **Siguiente**.
**OAuth 3LO (de tres patas OAuth)**: si su servidor MCP utiliza OAuth 3LO para la autenticación:
1. **Seleccione 3LO OAuth **
1. Haga clic en **Siguiente**.
**Clave API**: si su servidor MCP utiliza la autenticación mediante clave API:
1. Seleccione la clave **de API**
1. Haga clic en **Siguiente**.
### Paso 3: Configuración de la autorización
Configure parámetros de autorización adicionales en función del método de autenticación seleccionado:
**Para las credenciales OAuth del cliente:**
1. **ID de cliente**: introduzca el ID de OAuth cliente del cliente
1. **Secreto de cliente**: introduzca el secreto de OAuth cliente del cliente
1. **URL de Exchange**: introduzca la URL del punto de conexión de intercambio del OAuth token
1. **Parámetros de intercambio**: introduzca los parámetros de intercambio de OAuth tokens para autenticarse con el servicio
1. **Añadir ámbito**: añadir OAuth ámbitos para la autenticación
1. Haga clic en **Siguiente**.
**Para OAuth 3LO:**
1. **ID de cliente**: introduzca el ID de cliente del OAuth cliente
1. **Secreto** de cliente: introduzca el secreto de OAuth cliente del cliente si su OAuth cliente lo requiere
1. **URL de Exchange**: introduzca la URL del punto de conexión de intercambio del OAuth token
1. **URL de autorización**: introduzca la URL del punto final de OAuth autorización
1. **Code Challenge Support**: seleccione esta casilla de verificación si su OAuth cliente admite el desafío de código
1. **Añadir ámbito**: añada OAuth ámbitos para la autenticación
1. Haga clic en **Siguiente**.
**Para la clave de API:**
1. Introduzca un nombre de clave de API
1. Introduce el nombre del encabezado que contendrá la clave de API en la solicitud
1. Introduce el valor de tu clave de API
1. Haga clic en **Siguiente**.
### Paso 4: Revisa y envía
1. Revise todos los detalles de configuración del servidor MCP
1. Haga clic en **Enviar** para completar el registro
1. AWS DevOps El agente validará la conexión con su servidor MCP
1. Tras la validación correcta, su servidor MCP se registrará a nivel de cuenta
## Configuración de las herramientas de MCP en un espacio de agentes
Tras registrar un servidor MCP a nivel de cuenta, puede configurar qué herramientas de ese servidor están disponibles en espacios de agente específicos:
1. En la consola de AWS DevOps agentes, seleccione su espacio de agente
1. Ve a la pestaña **Capacidades**
1. **En la sección **Servidores MCP**, haga clic en Agregar**
1. Seleccione el servidor MCP registrado que desee conectar a este espacio de agentes
1. Configure qué herramientas de este servidor MCP deberían estar disponibles en el espacio de agentes:
+ **Permitir todas las herramientas**: hace que todas las herramientas del servidor MCP estén disponibles
+ **Seleccionar herramientas específicas**: le permite elegir qué herramientas permitir en la lista
1. Haga clic en **Agregar** para conectar el servidor MCP a su espacio de agente
AWS DevOps El agente ahora podrá utilizar las herramientas permitidas de su servidor MCP durante las investigaciones en este espacio de agentes.
## Administrar las conexiones del servidor MCP
**Actualización de las credenciales** de autenticación: si es necesario actualizar sus credenciales de autenticación, tendrá que volver a registrar el servidor MCP. **Vaya a la página **de proveedores de capacidades** de la consola del AWS DevOps agente, localice su servidor MCP, elimine cualquier asociación activa y haga clic en Anular el registro.** A continuación, **registre** su servidor MCP con las nuevas credenciales de autenticación y vuelva a crear las asociaciones necesarias con su espacio de agente.
**Visualización de los servidores MCP conectados****: para ver todos los servidores MCP conectados a su espacio de agente, seleccione su espacio de agente, vaya a la pestaña **Capacidades** y consulte la sección Servidores MCP.** También puede actualizar las herramientas seleccionadas aquí.
**Eliminar las conexiones del servidor MCP****: para desconectar un servidor MCP de un espacio de agentes, seleccione el servidor en la sección **Servidores MCP** y haga clic en Eliminar.** Para eliminar por completo el registro de un servidor MCP, elimínelo primero de todos los Agent Spaces y, a continuación, elimine el registro a nivel de cuenta.
## Temas relacionados
+ Seguridad en el agente AWS DevOps
+ Configuración de un espacio de agentes
+ Protección de inyección rápida
# Conexión de varias AWS cuentas
AWS Las cuentas secundarias permiten al AWS DevOps agente investigar los recursos de varias AWS cuentas de la organización. Cuando sus aplicaciones abarcan varias cuentas, añadir cuentas secundarias garantiza que el agente tenga visibilidad de todos los recursos relevantes durante la investigación de los incidentes. Un mayor acceso a las cuentas y los recursos que componen una aplicación garantiza una mayor precisión en la investigación.
## Requisitos previos
Antes de añadir una AWS cuenta secundaria, asegúrese de tener:
+ Acceso a la consola del AWS DevOps agente desde la cuenta principal
+ Acceso administrativo a la AWS cuenta secundaria
+ Permisos de IAM para crear funciones en la cuenta secundaria
## Añadir una cuenta secundaria AWS
Además de los pasos que se indican a continuación, puede utilizarlos [AWS DevOps Guía de incorporación de Agent CLI](getting-started-with-aws-devops-agent-cli-onboarding-guide.md) para añadir cuentas secundarias mediante programación.
### Paso 1: Inicie la configuración de la cuenta secundaria
1. Inicie sesión en la consola AWS de administración y navegue hasta la consola del AWS DevOps agente
1. Seleccione su espacio de agente
1. Ve a la pestaña **Capacidades**
1. En la sección **Nube**, localice la subsección de **fuentes secundarias**
1. **Haz clic en Añadir**
### Paso 2: especifique el nombre del rol
1. En el campo Asigne un **nombre a su función**, introduzca un nombre para la función que va a crear en la cuenta secundaria
1. Anota este nombre: lo volverás a usar al crear el rol en la cuenta secundaria
1. Copia la política de confianza proporcionada en la consola y guárdala en un espacio temporal
### Paso 3: Crea el rol en la cuenta secundaria
1. Abre una nueva pestaña del navegador e inicia sesión en la consola de IAM en la cuenta secundaria AWS
1. **Vaya a **IAM > Funciones >** **Crear función****
1. Seleccione Política **de confianza personalizada**
1. Pegue la política de confianza que copió del paso 2
1. Haga clic en **Siguiente**.
### Paso 4: Adjunte la política AWS gestionada
1. En la sección **Políticas de permisos**, busque **AIOpsAssistantPolicy**
1. Seleccione la casilla de verificación situada junto a la política **AIOpsAssistantPolicy**gestionada
1. Haga clic en **Siguiente**.
### Paso 5: Asigne un nombre al rol y créelo
1. En el campo **Nombre del rol**, ingresa el mismo nombre del rol que proporcionaste en el paso 2
1. (Opcional) Agregue una descripción para ayudar a identificar el propósito del rol
1. Revise la política de confianza y los permisos adjuntos
1. Haz clic en **Crear rol**
### Paso 6: Adjunte la política en línea
1. En la consola de IAM, busque y seleccione el rol que acaba de crear
1. Vaya a la pestaña **Permisos**
1. Haga clic en **Añadir permisos** > **Crear política en línea**
1. Cambie a la pestaña **JSON**
1. Pegue la política que guardó en el paso 2
1. Pegue la política en el editor JSON de la consola de IAM
1. Haga clic en **Siguiente**.
1. Proporcione un nombre para la política en línea (por ejemplo, "«DevOpsAgentInlinePolicy)
1. Haga clic en **Crear política**
### Paso 7: Complete la configuración
1. Regrese a la consola del AWS DevOps agente en la cuenta principal
1. Haga clic en **Siguiente** para completar la configuración de la cuenta secundaria
1. Compruebe que el estado de la conexión se muestre como **Activo**
## Comprenda las políticas requeridas
AWS DevOps El agente necesita tres componentes de política para acceder a los recursos de una cuenta secundaria:
+ **Política de confianza**: permite que el AWS DevOps agente de la cuenta principal asuma el rol en la cuenta secundaria. Esto establece la relación de confianza entre las cuentas.
+ **AIOpsAssistantPolicy (política AWS gestionada)**: proporciona los permisos básicos de solo lectura que el AWS DevOps agente necesita para investigar los recursos de la cuenta secundaria. Esta política se mantiene AWS y actualiza a medida que se añaden nuevas capacidades.
+ **Política integrada**: proporciona permisos adicionales específicos para la configuración de Agent Space. Esta política se genera en función de la configuración del espacio de agente y puede incluir permisos para integraciones o funciones específicas.
En la cuenta principal, el rol de AWS DevOps agente de IAM debe poder asumir el rol creado en la cuenta secundaria.
## Administrar cuentas secundarias
+ **Visualización de las cuentas conectadas**: en la pestaña **Capacidades**, la subsección **Fuentes secundarias** muestra todas las cuentas secundarias conectadas con su estado de conexión.
+ **Actualización del rol de IAM**: si necesita modificar los permisos, actualice la política interna asociada al rol en la cuenta secundaria. Los cambios surten efecto inmediatamente.
+ **Eliminar una cuenta secundaria****: para desconectar una cuenta secundaria, selecciónela en la lista de **fuentes secundarias** y haga clic en Eliminar.** Esto no elimina la función de IAM en la cuenta secundaria.
# Conexión de fuentes de telemetría
AWS DevOps El agente ofrece tres formas de conectarse a las fuentes de telemetría.
## Integración bidireccional integrada
Actualmente, AWS DevOps Agent apoya a los usuarios de Dynatrace con una integración bidireccional integrada que permite lo siguiente:
+ **Mapeo de recursos topológicos**: AWS DevOps Agent ampliará la topología de su espacio de DevOps agentes con entidades y relaciones disponibles a través de un servidor MCP de Dynatrace alojado en un agente. AWS DevOps
+ **Activación automática de investigaciones: los flujos de trabajo de Dynatrace se pueden configurar para activar** la resolución de incidentes a partir de problemas de Dynatrace.
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección de la** telemetría de Dynatrace mientras investiga un problema a través del servidor MCP de Dynatrace alojado en el agente. AWS DevOps
+ **Actualizaciones de estado**: el AWS DevOps agente publicará en la interfaz de usuario de Dynatrace los principales resultados de la investigación, los análisis de las causas fundamentales y los planes de mitigación generados.
Para obtener más información sobre las integraciones bidireccionales, consulte
+ [Conectando Dynatrace](connecting-telemetry-sources-connecting-dynatrace.md)
## Integración unidireccional integrada
Actualmente, AWS DevOps Agent admite a los usuarios de Datadog AWS CloudWatch, Grafana, New Relic y Splunk con integraciones unidireccionales integradas.
**Mejores prácticas de seguridad:** al configurar las credenciales para las integraciones unidireccionales integradas, recomendamos limitar las claves y los tokens de la API al acceso de solo lectura. AWS DevOps El agente utiliza estas credenciales únicamente para la introspección telemétrica y no requiere acceso de escritura a su proveedor de telemetría.
La integración AWS CloudWatch unidireccional integrada no requiere ninguna configuración adicional y permite lo siguiente:
+ **Mapeo de recursos topológicos**: AWS DevOps Agent ampliará la topología de su espacio de DevOps agentes con entidades y relaciones disponibles a través de sus cuentas de nube principales y secundarias configuradas. AWS
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección** de la AWS CloudWatch telemetría mientras investiga un problema mediante las funciones de IAM asignadas durante la configuración de la cuenta de nube principal y secundaria. AWS
Las integraciones unidireccionales integradas de Datadog, Grafana, New Relic y Splunk requieren configuración y permiten lo siguiente:
+ **Activación automática de investigaciones: los** eventos de Datadog, Grafana, New Relic y Splunk se pueden configurar para activar las investigaciones de resolución de incidentes de los agentes a través de los webhooks de los AWS DevOps agentes. AWS DevOps
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección** de la telemetría de Datadog, Grafana, New Relic y Splunk mientras investiga un problema a través del servidor MCP remoto de cada proveedor.
Para obtener información sobre las integraciones unidireccionales, consulte lo siguiente:
+ [Conectando DataDog](connecting-telemetry-sources-connecting-datadog.md)
+ [Conectando Grafana](connecting-telemetry-sources-connecting-grafana.md)
+ [Conectando New Relic](connecting-telemetry-sources-connecting-new-relic.md)
+ [Conexión de Splunk](connecting-telemetry-sources-connecting-splunk.md)
## Bring-your-own fuentes de telemetría
Para cualquier otra fuente de telemetría, incluidas las métricas de Prometheus, puede aprovechar el soporte de AWS DevOps Agent para la integración de servidores webhook y MCP.
Para obtener más información sobre las integraciones, consulte lo siguiente bring-your-own
+ [Invocar al DevOps agente a través de Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
+ [Conexión de servidores MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
# Conectando Dynatrace
## Integración bidireccional integrada
Actualmente, AWS DevOps Agent apoya a los usuarios de Dynatrace con una integración bidireccional integrada que permite lo siguiente:
+ **Mapeo de recursos topológicos**: AWS DevOps Agent ampliará la topología del espacio de DevOps agentes con las entidades y relaciones disponibles en su entorno de Dynatrace.
+ **Activación automática de investigaciones: los** flujos de trabajo de Dynatrace se pueden configurar para iniciar investigaciones de resolución de incidentes a partir de problemas de Dynatrace.
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección de la** telemetría de Dynatrace mientras investiga un problema a través del servidor MCP de Dynatrace alojado en el agente. AWS DevOps
+ **Actualizaciones de estado**: el AWS DevOps agente publicará en la interfaz de usuario de Dynatrace los principales resultados de la investigación, los análisis de las causas fundamentales y los planes de mitigación generados.
## Incorporación
### Proceso de incorporación
La incorporación del sistema de observabilidad de Dynatrace consta de tres etapas:
1. **Connect**: establezca una conexión con Dynatrace configurando las credenciales de acceso a la cuenta, con todos los entornos que pueda necesitar
1. **Habilitar**: active Dynatrace en espacios de agentes específicos con entornos de Dynatrace específicos
1. **Configure su entorno de Dynatrace**: descargue los flujos de trabajo y el panel de control e impórtelos a Dynatrace y anote los detalles del webhook para iniciar las investigaciones en los espacios de agentes designados
### Paso 1: Conectar
Establezca una conexión con su entorno de Dynatrace
#### Configuración
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. **Busque **Dynatrace** en la sección de proveedores **disponibles**, en **Telemetría**, y haga clic en Registrarse**
1. **Cree un OAuth cliente en Dynatrace, con los permisos detallados.**
1. [Consulte la documentación de Dynatrace](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)
1. Cuando esté listo, presione Siguiente
1. Puedes conectar varios entornos de Dynatrace y, posteriormente, conectarlos a otros específicos para cada espacio de DevOps agente del que dispongas.
1. Introduce los detalles de Dynatrace desde la configuración del cliente: OAuth
+ **Nombre del cliente**
+ **ID de cliente**
+ **Secreto de cliente**
+ **URN de la cuenta**
1. Haga clic en Siguiente.
1. Revisa y agrega
### Paso 2: Habilitar
Active Dynatrace en un espacio de agente específico y configure el alcance adecuado
#### Configuración
1. En la página de espacios de agentes, seleccione un espacio de agentes y pulse ver detalles
1. Seleccione la pestaña Capacidades
1. Localice la sección de telemetría y pulse Añadir
1. Verás que Dynatrace tiene el estado «Registrado». Haga clic en añadir para añadirlo a su espacio de agente
1. ID de entorno de Dynatrace: proporcione el ID de entorno de Dynatrace que le gustaría asociar a este espacio de agentes. DevOps
1. Introduzca una o más entidades de Dynatrace. Estas entidades ayudarán a los DevOps agentes a descubrir sus recursos más importantes IDs ; por ejemplo, servicios o aplicaciones. **Si no está seguro, puede pulsar quitar.**
1. Revise y pulse Guardar
1. Copia la URL del Webhook y el secreto del Webhook. Consulte la [documentación de Dynatrace para añadir estas credenciales](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent) a Dynatrace.
### Paso 3: Configure su entorno de Dynatrace
Para completar la configuración de Dynatrace, deberá realizar ciertos pasos de configuración en su entorno de Dynatrace. [Siga las instrucciones de la documentación de Dynatrace.](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)
#### Esquemas de eventos compatibles
AWS DevOps El agente admite dos tipos de eventos de Dynatrace mediante webhooks. Los esquemas de eventos compatibles se documentan a continuación:
##### Incidente o evento
Los incidentes se utilizan para iniciar una investigación. El esquema de eventos es:
```
{
"event.id": string;
"event.status": "ACTIVE" | "CLOSED";
"event.status_transition": string;
"event.description": string;
"event.name": string;
"event.category": "AVAILABILITY" | "ERROR" | "SLOWDOWN" | "RESOURCE_CONTENTION" | "CUSTOM_ALERT" | "MONITORING_UNAVAILABLE" | "INFO";
"event.start"?: string;
"affected_entity_ids"?: string[];
}
```
##### Evento de mitigación
Los eventos de mitigación se utilizan para activar la generación de un informe de mitigación para la investigación sobre los próximos pasos. El esquema del evento es:
```
{
"task_id": string;
"task_version": number;
"event.type": "mitigation_request";
}
```
## Eliminación
La fuente de telemetría está conectada en dos niveles: a nivel de espacio de agente y a nivel de cuenta. Para eliminarla por completo, primero debe eliminarla de todos los espacios de agentes en los que se utilice y, a continuación, podrá anular su registro.
### Paso 1: Eliminar del espacio de agentes
1. En la página de espacios de agentes, selecciona un espacio de agentes y pulsa ver detalles
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Selecciona Dynatrace
1. Presiona quitar
### Paso 2: Anular el registro de la cuenta
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. Desplázate hasta la sección **Registrados actualmente**.
1. Comprueba que el número de espacios para agentes sea cero (si no, repite el paso 1 anterior en los demás espacios para agentes)
1. Presiona Cancelar registro junto a Dynatrace
# Conectando DataDog
## Integración unidireccional integrada
Actualmente, AWS DevOps Agent admite a los usuarios de Datadog con una integración unidireccional integrada, lo que permite lo siguiente:
+ **Activación automática de la investigación: los** eventos de Datadog se pueden configurar para activar las investigaciones de resolución de incidentes del AWS DevOps agente mediante los webhooks de los agentes. AWS DevOps
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección** de la telemetría de Datadog mientras investiga un problema a través del servidor MCP remoto de cada proveedor.
## Incorporación
### Paso 1: Conectar
Establezca la conexión con su terminal MCP remoto de Datadog con las credenciales de acceso a la cuenta
#### Configuración
1. Vaya a la página de **proveedores de capacidades** (accesible desde el panel de navegación lateral)
1. **Busque **Datadog** en la sección Proveedores **disponibles** en **Telemetría** y haga clic en Registrar**
1. Introduzca los detalles de su servidor MCP de Datadog:
+ **Nombre del servidor**: identificador único (por ejemplo,) my-datadog-server
+ **URL del punto final**: el punto final de su servidor MCP de Datadog. La URL del punto final varía en función del sitio de Datadog. Consulte la tabla de puntos finales del sitio de Datadog que aparece a continuación.
+ **Descripción: descripción del** servidor opcional
1. Haga clic en Siguiente.
1. Revisión y envío
#### Puntos finales del sitio Datadog
La URL del punto final del MCP varía según el sitio de Datadog. [Para identificar su sitio, compruebe la URL en su navegador cuando haya iniciado sesión en Datadog o consulte Acceder al sitio de Datadog.](https://docs.datadoghq.com/getting_started/site/#access-the-datadog-site)
| Sitio de Datadog | Dominio del sitio | URL del punto final de MCP |
| --- | --- | --- |
| US1 (predeterminado) | 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 |
#### Autorización
OAuth Autorización completa por parte de:
+ Autorizar como usuario en la página de Datadog OAuth
+ Si no ha iniciado sesión, haga clic en Permitir, iniciar sesión y, a continuación, autorizar
Una vez configurado, Datadog estará disponible en todos los espacios de agentes.
### Paso 2: Habilitar
Actívelo DataDog en un espacio de agente específico y configure el alcance adecuado
#### Configuración
1. En la página de espacios de agentes, seleccione un espacio de agentes y pulse ver detalles (si aún no ha creado un espacio de agentes, consulte[Creación de un espacio de agentes](getting-started-with-aws-devops-agent-creating-an-agent-space.md))
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Presiona Agregar
1. Seleccione Datadog
1. Next
1. Revise y pulse Guardar
1. Copia la URL y la clave de API de Webhook
### Paso 3: Configurar los webhooks
Con la URL y la clave de API de Webhook, puede configurar Datadog para que envíe eventos que inicien una investigación, por ejemplo, a partir de una alarma.
Para garantizar que el DevOps agente pueda utilizar los eventos enviados, asegúrese de que los datos transmitidos al webhook coincidan con el esquema de datos que se especifica a continuación. El DevOps agente puede ignorar los eventos que no coincidan con este esquema.
Establezca el método y los encabezados
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envía el cuerpo como una cadena 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;
}
```
Envía webhooks con Datadog [https://docs.datadoghq.com/integrations/webhooks/](https://docs.datadoghq.com/integrations/webhooks/) (ten en cuenta que no seleccionas ninguna autorización y, en su lugar, usa la opción de encabezado personalizado).
[Más información: Datadog Remote MCP Server](https://www.datadoghq.com/blog/datadog-remote-mcp-server/)
## Eliminación
La fuente de telemetría está conectada en dos niveles: a nivel de espacio de agente y a nivel de cuenta. Para eliminarla por completo, primero debe eliminarla de todos los espacios de agentes en los que se utilice y, a continuación, podrá anular su registro.
### Paso 1: Eliminar del espacio de agentes
1. En la página de espacios de agentes, selecciona un espacio de agentes y pulsa ver detalles
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Selecciona Datadog
1. Presiona quitar
### Paso 2: Anular el registro de la cuenta
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. Desplázate hasta la sección **Registrados actualmente**.
1. Comprueba que el número de espacios para agentes sea cero (si no, repite el paso 1 anterior en los demás espacios para agentes)
1. Presiona Cancelar registro junto a Datadog
# Conectando Grafana
La integración de Grafana permite al AWS DevOps agente consultar métricas, paneles y datos de alertas de su instancia de Grafana durante la investigación de incidentes. Esta integración sigue un proceso de dos pasos: el registro de Grafana a nivel de cuenta y, a continuación, su conexión a los espacios de agente individuales.
Para mejorar la seguridad, la integración de Grafana solo permite herramientas de solo lectura. Las herramientas de escritura están deshabilitadas y no se pueden activar. Esto significa que el agente puede consultar y leer los datos de tu instancia de Grafana, pero no puede crear, modificar ni eliminar ningún recurso de Grafana, como paneles, alertas o anotaciones. [Para obtener más información, consulta Seguridad en el agente. AWS DevOps ](https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html)
## Requisitos de Grafana
Antes de conectar Grafana, asegúrese de tener:
+ Grafana versión 9.0 o posterior. Es posible que algunas funciones, en particular las operaciones relacionadas con la fuente de datos, no funcionen correctamente con versiones anteriores debido a la falta de puntos finales de la API.
+ Una instancia de Grafana accesible a través de HTTPS. Se admiten puntos de conexión de red públicos y privados. Con la conectividad de red privada, su instancia de Grafana se puede alojar en una VPC sin acceso público a Internet. Para obtener más información, consulte [Conexión a herramientas alojadas de forma privada](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md).
+ Una cuenta de servicio de Grafana con un token de acceso que tenga los permisos de lectura adecuados
## Registro de Grafana (a nivel de cuenta)
Grafana está registrada a nivel de AWS cuenta y se comparte entre todos los Agent Spaces de esa cuenta.
### Paso 1: Configurar Grafana
1. Inicie sesión en la consola de AWS administración
1. Navegue hasta la consola del AWS DevOps agente
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde el panel de navegación lateral)
1. **Busque **Grafana** en la sección Proveedores **disponibles** en **Telemetría** y haga clic en Registrar**
1. En la página **Configurar Grafana**, introduzca la siguiente información:
+ **Nombre del servicio** (obligatorio): introduzca un nombre descriptivo para su servidor Grafana utilizando únicamente caracteres alfanuméricos, guiones y guiones bajos. Por ejemplo, `my-grafana-server`.
+ **URL de Grafana** (obligatorio): introduce la URL HTTPS completa de tu instancia de Grafana. Por ejemplo, `https://myinstance.grafana.net`.
+ **Token de acceso a la cuenta de servicio** (obligatorio): introduce un token de acceso a la cuenta de servicio de Grafana. Los tokens suelen empezar `glsa_` por. Para crear un token de cuenta de servicio, dirígete a tu instancia de Grafana, ve a **Administración > Cuentas de servicio**, crea una cuenta de servicio con el rol de Visor y genera un token.
+ **Descripción** (opcional): agrega una descripción para ayudar a identificar el propósito del servidor. Por ejemplo, `Production Grafana server for monitoring`.
1. (Opcional) Añada AWS etiquetas al registro con fines organizativos.
1. Haga clic en **Siguiente**.
### Paso 2: Revise y envíe el registro de Grafana
1. Revise todos los detalles de configuración de Grafana
1. Haga clic en **Enviar** para completar el registro
1. Tras el registro exitoso, Grafana aparece en la sección **Actualmente registrada** de la página de proveedores de capacidades
## Añadir Grafana a un espacio de agentes
Tras registrar Grafana a nivel de cuenta, puedes conectarla a espacios de agente individuales:
1. En la consola de AWS DevOps agentes, selecciona tu espacio de agente
1. Ve a la pestaña **Capacidades**
1. **En la sección **Telemetría**, haga clic en Agregar**
1. Seleccione **Grafana** de la lista de proveedores disponibles
1. **Haga clic en Guardar**
## Configuración de webhooks de alertas de Grafana
Puedes configurar Grafana para que active automáticamente las investigaciones de los AWS DevOps agentes cuando se activen alertas mediante el envío de webhooks a través de los puntos de contacto de Grafana. Para obtener más información sobre los métodos de autenticación de webhooks y la administración de credenciales, consulte. [Invocar al DevOps agente a través de Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
### Paso 1: Cree una plantilla de notificación personalizada
En tu instancia de Grafana, ve a **Alertas > Puntos de contacto > Plantillas de notificaciones** y crea una nueva plantilla con el siguiente contenido:
```
{{ 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 }}
```
Esta plantilla formatea las alertas de Grafana en la estructura de carga útil de webhook que espera el agente. AWS DevOps Asigna las etiquetas, las anotaciones y el estado de las alertas a los campos correspondientes e incluye todas las etiquetas de alerta como metadatos.
**Nota:** Esta plantilla procesa solo la primera alerta de un grupo. Grafana agrupa varias alertas de disparo en una sola notificación de forma predeterminada. Para asegurarte de que cada alerta se envíe de forma individual, configura tus políticas de notificación para agruparlas por`alertname`. Además, esta plantilla no escapa a los caracteres JSON especiales en los valores o anotaciones de las etiquetas. Asegúrese de que las etiquetas de alerta y la `summary` anotación no contengan caracteres como comillas dobles o líneas nuevas, ya que generarían un JSON no válido.
### Paso 2: Crea un punto de contacto de webhook
1. **En Grafana, vaya a **Alertas > Puntos de contacto** y haga clic en Añadir punto de contacto**
1. Selecciona **Webhook como tipo** de integración
1. Establezca la **URL del punto** final del webhook de su AWS DevOps agente
1. En la sección **Configuración opcional del webhook**, configura los encabezados de autenticación en función del tipo de webhook. Consulta los métodos de [autenticación de Webhook para obtener](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) más información.
1. Configura el campo **Mensaje** para usar tu plantilla personalizada: `{{ template "devops-agent-payload" . }}`
1. Haz clic en **Guardar punto de contacto**
### Paso 3: Asigne el punto de contacto a una política de notificaciones
1. Vaya a **Alertas > Políticas de notificación**
1. Edite una política existente o cree una nueva
1. Configura el punto de contacto en el punto de contacto del webhook que creaste
1. Haz clic en **Guardar política**
Cuando se active una alerta coincidente, Grafana enviará la carga útil formateada al AWS DevOps Agente, que iniciará una investigación automáticamente.
## Limitaciones
+ **ClickHouse herramientas de fuentes de ClickHouse datos**: actualmente no se admiten las herramientas de fuentes de datos.
+ **Prevención proactiva de incidentes**: actualmente [Prevención proactiva de incidentes](working-with-devops-agent-proactive-incident-prevention.md) no utiliza las herramientas de Grafana. Support está previsto para una versión futura.
### Consideraciones sobre Amazon Managed Grafana
Si utilizas [Amazon Managed Grafana](https://aws.amazon.com/grafana/) (AMG), ten en cuenta las siguientes limitaciones:
+ **No se admiten los puntos de contacto de Webhook. Actualmente, AMG no admite** los puntos de contacto de Webhook en su configuración de alertas. No puedes usar AMG para enviar webhooks de alertas directamente al agente. AWS DevOps Para obtener más información, consulta Cómo [alertar a los puntos de contacto en Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/v9-alerting-explore-contacts.html).
+ **Caducidad de los tokens de las cuentas** de servicio de AMG: los tokens de las cuentas de servicio de AMG tienen una caducidad máxima de 30 días. Deberás rotar las fichas y actualizar tu registro de Grafana en AWS DevOps Agent antes de que caduquen. Consulte [Administrar las conexiones de Grafana](#managing-grafana-connections) para saber cómo actualizar las credenciales. Para obtener más información sobre los límites de los tokens AMG, consulte [Cuentas de servicio en Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/service-accounts.html).
## Gestión de las conexiones de Grafana
+ **Actualización de credenciales**: si el token de su cuenta de servicio caduca o necesita actualizarse, anule el registro de Grafana en la página de proveedores de capacidades y vuelva a registrarse con el nuevo token.
+ **Visualización de las instancias conectadas**: en la consola del AWS DevOps agente, selecciona tu espacio de agente y ve a la pestaña Capacidades para ver las fuentes de telemetría conectadas.
+ **Eliminar Grafana****: para desconectar Grafana de un espacio de agentes, selecciónelo en la sección Telemetría y haga clic en Eliminar.** Para eliminar por completo el registro, elimínelo primero de todos los Agent Spaces y, a continuación, anule el registro en la página de proveedores de capacidades.
# Conectando New Relic
## Integración unidireccional integrada
Actualmente, AWS DevOps Agent apoya a los usuarios de New Relic con una integración unidireccional integrada, que permite lo siguiente:
+ **Activación automática de las investigaciones: los** eventos de New Relic se pueden configurar para activar las investigaciones de resolución de incidentes por parte de los AWS DevOps agentes mediante AWS DevOps los webhooks de los agentes.
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección** de la telemetría de New Relic mientras investiga un problema a través del servidor MCP remoto de cada proveedor.
## Incorporación
### Paso 1: Conectar
Establezca la conexión con su terminal MCP remoto de New Relic con las credenciales de acceso a la cuenta
Utilice un usuario de plataforma completa (no básico o básico) en New Relic para habilitar las herramientas MCP de New Relic.
#### Configuración
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. **Busque **New Relic** en la sección de proveedores **disponibles**, en **Telemetría**, y haga clic en Registrarse**
1. Sigue las instrucciones para obtener tu clave de API de New Relic
1. Introduce los detalles de la clave de API de tu servidor MCP de New Relic:
+ **ID de cuenta:** introduce tu ID de cuenta de New Relic obtenido anteriormente
+ **Clave de API:** Introduzca la clave de API obtenida anteriormente
+ **Selecciona la región de EE. UU. o la UE** según la ubicación de tu cuenta de New Relic.
1. Haz clic en Añadir
### Paso 2: Habilitar
Active New Relic en un espacio de agente específico y configure el alcance adecuado
#### Configuración
1. En la página de espacios de agentes, seleccione un espacio de agentes y pulse ver los detalles (si aún no ha creado un espacio de agentes, consulte) [Creación de un espacio de agentes](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Presiona Agregar
1. Selecciona New Relic
1. Next
1. Revisa y presiona Guardar
1. Copia la URL y la clave de API de Webhook
### Paso 3: Configurar los webhooks
Con la URL y la clave de API de Webhook, puedes configurar New Relic para que envíe eventos que activen una investigación, por ejemplo, a partir de una alarma. Para obtener más información sobre la configuración de los webhooks, consulta el artículo sobre el seguimiento de [cambios](https://docs.newrelic.com/docs/change-tracking/change-tracking-webhooks/) en los webhooks.
Para garantizar que el DevOps agente pueda utilizar los eventos enviados, asegúrese de que los datos transmitidos al webhook coincidan con el esquema de datos que se especifica a continuación. El DevOps agente puede ignorar los eventos que no coincidan con este esquema.
Establezca el método y los encabezados
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envía el cuerpo como una cadena 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;
}
```
[Envía webhooks con las notificaciones de webhooks de New Relichttps://newrelic.com/instant-observability/.](https://newrelic.com/instant-observability/webhook-notifications) Puedes seleccionar el token de portador como tipo de autorización o no seleccionar ninguna autorización y, en su lugar, añadirlo como un encabezado personalizado. `Authorization: Bearer `
Más información: [https://docs.newrelic.com/docs/agentic-/ai/mcp/overview](https://docs.newrelic.com/docs/agentic-ai/mcp/overview/)
## Eliminación
La fuente de telemetría está conectada en dos niveles: a nivel de espacio de agente y a nivel de cuenta. Para eliminarla por completo, primero debe eliminarla de todos los espacios de agentes en los que se utilice y, a continuación, podrá anular su registro.
### Paso 1: Eliminar del espacio de agentes
1. En la página de espacios de agentes, selecciona un espacio de agentes y pulsa ver detalles
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Selecciona New Relic
1. Presiona quitar
### Paso 2: Anular el registro de la cuenta
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. Desplázate hasta la sección **Registrados actualmente**.
1. Comprueba que el número de espacios para agentes sea cero (si no, repite el paso 1 anterior en los demás espacios para agentes)
1. Pulsa Cancelar registro junto a New Relic
# Conexión de Splunk
## Integración unidireccional integrada
Actualmente, AWS DevOps Agent apoya a los usuarios de Splunk con una integración unidireccional integrada, que permite lo siguiente:
+ **Activación automática de las investigaciones: los** eventos de Splunk se pueden configurar para activar las investigaciones de resolución de incidentes por parte del AWS DevOps agente mediante AWS DevOps los webhooks de los agentes.
+ Introspección **telemétrica: el AWS DevOps agente puede realizar una introspección** de la telemetría de Splunk mientras investiga un problema a través del servidor MCP remoto de cada proveedor.
## Requisitos previos
### Obtener un token de API de Splunk
Necesitará una URL y un token del MCP para conectarse a Splunk.
### Pasos para el administrador de Splunk
Su administrador de Splunk debe realizar los siguientes pasos:
+ habilitar el acceso a la [API REST](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ [habilite la autenticación mediante 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) en la implementación.
+ cree un nuevo rol 'mcp\$1user', el nuevo rol no necesita tener ninguna capacidad.
+ asigne el rol «mcp\$1user» a todos los usuarios de la implementación que estén autorizados a usar el servidor MCP.
+ cree el token para los usuarios autorizados con el nombre de «mcp» y establezca la caducidad adecuada si el usuario no tiene permiso para crear los tokens por sí mismo.
### Pasos para usar Splunk
Un usuario de Splunk debe realizar los siguientes pasos:
+ Obtenga un token apropiado del administrador de Splunk o cree uno por sí mismo, si tiene el permiso. La audiencia del token debe ser «mcp».
## Incorporación
### Paso 1: Conectar
Establezca la conexión con su terminal MCP remoto de Splunk con las credenciales de acceso a la cuenta
#### Configuración
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. **Busque **Splunk** en la sección Proveedores **disponibles**, en **Telemetría**, y haga clic en Registrar**
1. Introduzca los detalles de su servidor MCP de Splunk:
+ **Nombre del servidor**: identificador único (por ejemplo,) my-splunk-server
+ **URL del punto final**: el punto final de su servidor MCP de Splunk:
`https://.api.scs.splunk.com//mcp/v1/`
+ **Descripción: descripción del** servidor opcional
+ **Nombre del token**: el nombre del token portador para la autenticación: `my-splunk-token`
+ Valor del **token: el valor** del token del portador para la autenticación
### Paso 2: Habilitar
Active Splunk en un espacio de agente específico y configure el alcance adecuado
#### Configuración
1. En la página de espacios de agentes, seleccione un espacio de agentes y pulse ver los detalles (si aún no ha creado un espacio de agentes, consulte) [Creación de un espacio de agentes](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Presiona Agregar
1. Selecciona Splunk
1. Next
1. Revise y pulse Guardar
1. Copia la URL y la clave de API de Webhook
### Paso 3: Configurar los webhooks
Con la URL y la clave de API de Webhook, puede configurar Splunk para que envíe eventos que inicien una investigación, por ejemplo, a partir de una alarma.
Para garantizar que el DevOps agente pueda utilizar los eventos enviados, asegúrese de que los datos transmitidos al webhook coincidan con el esquema de datos que se especifica a continuación. El DevOps agente puede ignorar los eventos que no coincidan con este esquema.
Establezca el método y los encabezados
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
Envía el cuerpo como una cadena 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;
}
```
Envía webhooks 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) (ten en cuenta que no seleccionas autorización y, en su lugar, usa la opción de encabezado personalizado)
### Más información:
+ [Documentación del servidor MCP de 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)
+ Requisitos y limitaciones de acceso a la API REST de la plataforma Splunk Cloud: [https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ [Gestione los tokens de autenticación en Splunk Cloud Platform:/- https://help.splunk.com/en/ splunk-cloud-platform administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage 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)
+ Cree y gestione funciones con Splunk Web: [https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles](https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles)
## Eliminación
La fuente de telemetría está conectada en dos niveles: a nivel de espacio de agente y a nivel de cuenta. Para eliminarla por completo, primero debe eliminarla de todos los espacios de agentes en los que se utilice y, a continuación, podrá anular su registro.
### Paso 1: Eliminar del espacio de agentes
1. En la página de espacios de agentes, selecciona un espacio de agentes y pulsa ver detalles
1. Seleccione la pestaña Capacidades
1. Desplázate hacia abajo hasta la sección de telemetría
1. Selecciona Splunk
1. Presiona eliminar
### Paso 2: Anular el registro de la cuenta
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde la barra de navegación lateral)
1. Desplázate hasta la sección **Registrados actualmente**.
1. Comprueba que el número de espacios para agentes sea cero (si no, repite el paso 1 anterior en los demás espacios para agentes)
1. Presiona Cancelar registro junto a Splunk
# Conexión a la venta de entradas y al chat
AWS DevOps El agente está diseñado para actuar como miembro de tu equipo al participar en los canales de comunicación existentes de tu equipo. Puedes conectar DevOps Agent a tus sistemas de emisión de tickets y alarmas y, por ejemplo ServiceNow , iniciar automáticamente investigaciones a partir de los tickets de incidentes, acelerando la respuesta a los incidentes dentro de tus flujos de trabajo actuales para reducir el tiempo de recuperación previsto (MTTR). PagerDuty También puedes conectar a tu DevOps agente a los sistemas de colaboración de tu equipo, como Slack, para recibir resúmenes de las actividades de tu DevOps agente en un canal de chat.
Para obtener información sobre cómo conectar las integraciones de venta de entradas y chat, consulta lo siguiente:
+ [Conectando PagerDuty](connecting-to-ticketing-and-chat-connecting-pagerduty.md)
+ [Conectando ServiceNow](connecting-to-ticketing-and-chat-connecting-servicenow.md)
+ [Conectar Slack](connecting-to-ticketing-and-chat-connecting-slack.md)
# Conectando PagerDuty
PagerDuty La integración permite al AWS DevOps agente acceder a los datos de los incidentes, los horarios de guardia y la información de servicio de su PagerDuty cuenta y actualizarlos durante la investigación de los incidentes y la respuesta automática. Esta integración utiliza la OAuth versión 2.0 para una autenticación segura.
**importante**
** AWS DevOps El agente solo es compatible con la versión PagerDuty OAuth 2.0 más reciente (con alcance OAuth). No se admite la versión antigua PagerDuty OAuth con URI de redireccionamiento.
## PagerDuty requisitos
Antes de realizar PagerDuty la conexión, asegúrese de tener:
+ Una PagerDuty cuenta con su ID de OAuth cliente y su secreto
+ El subdominio de tu PagerDuty cuenta (por ejemplo, si tu PagerDuty URL es`https://your-company.pagerduty.com`, el subdominio es) `your-company`
## Registrarse PagerDuty
PagerDuty se registra a nivel de AWS cuenta y se comparte entre todos los espacios de agentes de esa cuenta.
### Paso 1: Configurar el acceso en PagerDuty
1. Inicie sesión en la consola AWS de administración
1. Navegue hasta la consola del AWS DevOps agente
1. Vaya a la página de **proveedores de capacidades** (a la que se puede acceder desde el panel de navegación lateral)
1. Busque **PagerDuty**en la sección Proveedores **disponibles** en **Comunicación** y haga clic en **Registrarse**
1. Siga la configuración guiada de la PagerDuty página **Configurar el acceso en**:
**Compruebe la región y el subdominio de su servicio:**
+ **Ámbito de la cuenta**: selecciona tu PagerDuty región (**EE. UU.** o **UE**) e introduce tu PagerDuty subdominio. Por ejemplo, si tu PagerDuty URL es`https://your-company.pagerduty.com`, `your-company` introdúcela.
**Crea una nueva aplicación en PagerDuty:**
+ En otra pestaña del navegador, inicia sesión PagerDuty y ve a **Integraciones > Registro de aplicaciones**
+ Crea una nueva aplicación con **OAuth 2.0 Scope OAuth**
+ En **Permisos**, concede los siguientes ámbitos mínimos obligatorios:`incidents.read`, y `incidents.write` `services.read`
+ Habilite **la integración de eventos** para permitir la comunicación bidireccional entre AWS DevOps el agente y PagerDuty
**Configure OAuth las credenciales:**
+ **Alcance del permiso**: los ámbitos mínimos requeridos son:`incidents.read`,, `incidents.write` `services.read`
+ **Nombre del cliente**: introduzca un nombre descriptivo para su OAuth cliente
+ **ID de cliente**: introduzca el ID de OAuth cliente que aparece en el registro de PagerDuty la aplicación
+ **Secreto de cliente**: introduce el secreto de OAuth cliente que aparece en el registro de PagerDuty la aplicación
### Paso 2: Revisa y envía PagerDuty el registro
1. Revise todos los detalles PagerDuty de configuración
1. Haga clic en **Enviar** para completar el registro
1. Si el registro se ha realizado correctamente, PagerDuty aparece en la sección **actualmente registrados** de la página de proveedores de capacidades
## Añadir PagerDuty a un espacio de agente
Tras registrarse PagerDuty a nivel de cuenta, puede conectarla a espacios de agente individuales:
1. En la consola de AWS DevOps agentes, selecciona tu espacio de agente
1. Ve a la pestaña **Capacidades**
1. En la sección **Comunicaciones**, haga clic en **Agregar**
1. Seleccione **PagerDuty**de la lista de proveedores disponibles
1. Haga clic en **Guardar**
## Administrar PagerDuty las conexiones
+ **Actualización de credenciales**: si es necesario actualizar sus OAuth credenciales, cancele el registro en la página PagerDuty de proveedores de capacidades y vuelva a registrarse con las nuevas credenciales.
+ **Visualización de las conexiones**: en la consola del AWS DevOps agente, seleccione su espacio de agente y vaya a la pestaña Capacidades para ver las integraciones de comunicación conectadas.
+ **Eliminar PagerDuty**: para desconectarse PagerDuty de un espacio de agentes, selecciónelo en la sección de comunicaciones y haga clic en **Eliminar**. Para eliminar por completo el registro, elimínelo primero de todos los espacios de agentes y, a continuación, anule el registro en la página de proveedores de capacidades.
## Soporte para Webhook
AWS DevOps El agente solo admite webhooks PagerDuty V3. No se admiten las versiones anteriores de webhook.
Para obtener más información sobre las suscripciones a los webhooks de la versión PagerDuty 3, consulta la [descripción general de los webhooks](https://developer.pagerduty.com/docs/webhooks-overview#webhook-subscriptions) en la documentación para desarrolladores. PagerDuty
# Conectando ServiceNow
En este tutorial, se explica cómo conectar una ServiceNow instancia con el AWS DevOps agente para que pueda iniciar automáticamente investigaciones de respuesta a incidentes cuando se crea un ticket y publicar sus principales hallazgos en el ticket de origen. También contiene ejemplos sobre cómo configurar la ServiceNow instancia para enviar solo tickets específicos a un espacio de DevOps agente y cómo organizar el enrutamiento de los tickets entre varios espacios de DevOps agente.
## Configuración inicial
El primer paso es crear ServiceNow un cliente de OAuth aplicación que AWS DevOps puedas usar para acceder a tu ServiceNow instancia.
### Cree un cliente ServiceNow OAuth de aplicación
1. Habilite la propiedad del sistema de credenciales de cliente de su instancia
1. Busca `sys_properties.list` en el cuadro de búsqueda del filtro y, a continuación, pulsa enter (no mostrará la opción, pero pulsar enter funciona)
1. Elige Nuevo
1. Añada el nombre como `glide.oauth.inbound.client.credential.grant_type.enabled` y el valor a true y escriba true \$1 false
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/09ed6d5ff911.png)
1. Vaya a Sistema OAuth > Registro de aplicaciones desde el cuadro de búsqueda del filtro
1. Seleccione «Nueva» > «Nueva experiencia de integración entrante» > «Nueva integración» > «OAuth - Concesión de credenciales de cliente»
1. Elija un nombre y establezca el usuario de la OAuth aplicación como «Administrador de problemas» y haga clic en «Guardar»
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/aeff4c127f7c.png)
### Conecta a tu ServiceNow OAuth cliente con el AWS DevOps agente
1. Puede iniciar este proceso en dos lugares. En primer lugar, vaya a la página de **proveedores de capacidades** y busque en **Comunicación** y, **ServiceNow**a continuación, haga clic en **Registrar**. También puede seleccionar cualquier espacio de DevOps agente que haya creado y navegar hasta Capacidades → Comunicaciones → Añadir → ServiceNow y hacer clic en Registrar.
1. A continuación, autorice al DevOps agente a acceder a su ServiceNow instancia mediante el cliente de OAuth aplicación que acaba de crear.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/3db5a9aafc5f.png)
+ Siga los pasos siguientes y guarde la información resultante sobre el webhook
**importante**
No volverás a ver esta información
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/80d0a319f87e.png)
### Configure su regla ServiceNow de negocio
Una vez que haya establecido la conectividad, tendrá que configurar una regla empresarial ServiceNow para enviar los tickets a sus espacios de DevOps agente.
1. Vaya a Suscripciones de actividades → Administración → Reglas empresariales y haga clic en Nuevo.
1. Defina el campo «Tabla» como «Incidente [incidente]», marque la casilla «Avanzado» y configure la regla para que se ejecute después de Insertar, Actualizar y Eliminar.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/6f2a7370e2c0.png)
1. Ve a la pestaña «Avanzado» y añade el siguiente script de webhook, inserta el secreto y la URL del webhook donde se indica y pulsa Enviar.
```
(function executeRule(current, previous /*null when async*/ ) {
var WEBHOOK_CONFIG = {
webhookSecret: GlideStringUtil.base64Encode('<<< INSERT WEBHOOK SECRET HERE >>>'),
webhookUrl: '<<< INSERT WEBHOOK URL HERE >>>'
};
function generateHMACSignature(payloadString, secret) {
try {
var mac = new GlideCertificateEncryption();
var signature = mac.generateMac(secret, "HmacSHA256", payloadString);
return signature;
} catch (e) {
gs.error('HMAC generation failed: ' + e);
return null;
}
}
function callWebhook(payload, config) {
try {
var timestamp = new Date().toISOString();
var payloadString = JSON.stringify(payload);
var payloadWithTimestamp =`${timestamp}:${payloadString}`;
var signature = generateHMACSignature(payloadWithTimestamp, config.webhookSecret);
if (!signature) {
gs.error('Failed to generate signature');
return false;
}
gs.info('Generated signature: ' + signature);
var request = new sn_ws.RESTMessageV2();
request.setEndpoint(config.webhookUrl);
request.setHttpMethod('POST');
request.setRequestHeader('Content-Type', 'application/json');
request.setRequestHeader('x-amzn-event-signature', signature);
request.setRequestHeader('x-amzn-event-timestamp', timestamp);
request.setRequestBody(payloadString);
var response = request.execute();
var httpStatus = response.getStatusCode();
var responseBody = response.getBody();
if (httpStatus >= 200 && httpStatus < 300) {
gs.info('Webhook sent successfully. Status: ' + httpStatus);
return true;
} else {
gs.error('Webhook failed. Status: ' + httpStatus + ', Response: ' + responseBody);
return false;
}
} catch (ex) {
gs.error('Error sending webhook: ' + ex.getMessage());
return false;
}
}
function createReference(field) {
if (!field || field.nil()) {
return null;
}
return {
link: field.getLink(true),
value: field.toString()
};
}
function getStringValue(field) {
if (!field || field.nil()) {
return null;
}
return field.toString();
}
function getIntValue(field) {
if (!field || field.nil()) {
return null;
}
var val = parseInt(field.toString());
return isNaN(val) ? null : val;
}
var eventType = (current.operation() == 'insert') ? "create" : "update";
var incidentEvent = {
eventType: eventType.toString(),
sysId: current.sys_id.toString(),
priority: getStringValue(current.priority),
impact: getStringValue(current.impact),
active: getStringValue(current.active),
urgency: getStringValue(current.urgency),
description: getStringValue(current.description),
shortDescription: getStringValue(current.short_description),
parent: getStringValue(current.parent),
incidentState: getStringValue(current.incident_state),
severity: getStringValue(current.severity),
problem: createReference(current.problem),
additionalContext: {}
};
incidentEvent.additionalContext = {
number: current.number.toString(),
opened_at: getStringValue(current.opened_at),
opened_by: current.opened_by.nil() ? null : current.opened_by.getDisplayValue(),
assigned_to: current.assigned_to.nil() ? null : current.assigned_to.getDisplayValue(),
category: getStringValue(current.category),
subcategory: getStringValue(current.subcategory),
knowledge: getStringValue(current.knowledge),
made_sla: getStringValue(current.made_sla),
major_incident: getStringValue(current.major_incident)
};
for (var key in incidentEvent.additionalContext) {
if (incidentEvent.additionalContext[key] === null) {
delete incidentEvent.additionalContext[key];
}
}
gs.info(JSON.stringify(incidentEvent, null, 2)); // Pretty print for logging only
if (WEBHOOK_CONFIG.webhookUrl && WEBHOOK_CONFIG.webhookSecret) {
callWebhook(incidentEvent, WEBHOOK_CONFIG);
} else {
gs.info('Webhook not configured.');
}
})(current, previous);
```
Si ha decidido registrar su ServiceNow conexión desde la página de **proveedores de capacidades**, ahora tiene que ir al espacio de DevOps agentes en el que desea investigar las denuncias de ServiceNow incidentes, seleccionar Capacidades → Comunicaciones y, a continuación, registrar la ServiceNow instancia que registró en la página de proveedores de capacidades. Ahora, todo está listo y todos los incidentes en los que la persona que llama tenga el nombre de «administrador de problemas» (para imitar los permisos que usted otorgó al AWS DevOps OAuth cliente) darán lugar a una investigación de respuesta al incidente en el espacio de DevOps agente configurado. Para comprobarlo, crea un nuevo incidente ServiceNow y configura el campo de llamada del incidente como «Administrador de problemas».
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/4c7d24a85f88.png)
### ServiceNow actualizaciones de tickets
Durante todas las investigaciones de respuesta a incidentes que se inicien, su DevOps agente actualizará sus principales hallazgos, sus análisis de las causas fundamentales y los planes de mitigación en la solicitud de origen. Las conclusiones del agente se publican junto con los comentarios de un incidente y, por el momento, solo publicaremos los registros de los agentes relacionados con las actualizaciones del tipo `finding` `cause``investigation_summary`,`mitigation_summary`, y del estado de la investigación (p. ej.`AWS DevOps Agent started/finished its investigation`).
## Ejemplos de enrutamiento y organización de tickets
### Escenario: filtrar qué incidentes se envían a un espacio de DevOps agentes
Se trata de un escenario sencillo, pero requiere cierta configuración ServiceNow para crear un campo ServiceNow que permita rastrear el origen del incidente. Para este ejemplo, cree un nuevo campo Source (u\$1source) con el generador de formularios SNOW. Esto permitirá rastrear la fuente del incidente y usarla para enrutar las solicitudes de una fuente en particular a un espacio de DevOps agente. El enrutamiento se logra creando una regla de negocio de Service Now y, en la pestaña Cuándo ejecutar, configurando «Cuándo» se activan y «Condiciones de filtrado». En este ejemplo, las condiciones del filtro se establecen de la siguiente manera:
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/fac7a186beee.png)
### Escenario: enrutar los incidentes a través de varios espacios de DevOps agentes
En este ejemplo, se muestra cómo iniciar una investigación en el espacio de DevOps agentes B cuando la urgencia es`1`, la categoría o el servicio`AWS`, y cómo iniciar una investigación en el espacio de DevOps agentes A cuando el servicio lo es `AWS` y la fuente es`Dynatrace`. `Software`
Este escenario se puede llevar a cabo de dos maneras. El propio script del webhook se puede actualizar para incluir esta lógica empresarial. En este escenario, mostraremos cómo lograrlo con una regla de ServiceNow negocio, para aumentar la transparencia y simplificar la depuración. El enrutamiento se logra mediante la creación de dos reglas comerciales de Service Now.
+ Cree una regla de negocio ServiceNow para el espacio de DevOps agentes A y cree una condición utilizando el generador de condiciones para enviar únicamente los eventos en función de nuestra condición especificada.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/bca2f3928bf0.png)
+ A continuación, cree otra regla de negocio ServiceNow para AgentSpace B, cuya regla de negocio solo se active cuando el servicio sea AWS y la fuente sea Dynatrace.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/bc29e4db1a76.png)
Ahora, cuando cree un nuevo incidente que cumpla con la condición especificada, se iniciará una investigación en el Agent Space A o DevOps en el DevOps Agent Space B, lo que le proporcionará un control pormenorizado sobre la distribución de los incidentes.
# Conectar Slack
Puedes configurar AWS DevOps Agent para que actualice el canal de Slack que selecciones con las principales conclusiones de la investigación sobre la respuesta a incidentes, los análisis de las causas principales y los planes de mitigación generados.
## Antes de empezar
Slack debe estar registrado en DevOps Agent para poder añadirlo a un espacio de agentes. Para integrar AWS DevOps Agent con Slack, debes cumplir los siguientes requisitos:
+ Ten acceso a un espacio de trabajo de Slack con la posibilidad de instalar y autorizar aplicaciones de terceros
+ Has identificado los canales de Slack a los que quieres que el AWS DevOps agente envíe las notificaciones
## Registra la integración de Slack con el agente AWS DevOps
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/4034f56fad96.png)
1. **En la página **Proveedores de capacidades** de la consola del AWS DevOps agente, busca **Slack** en la sección Proveedores **disponibles**, en la sección **Comunicación**, y haz clic en Registrar.**
1. Pulsa el botón de **registro**.
1. Se te redirigirá a Slack para que autorices la solicitud de AWS DevOps agente en tu espacio de trabajo.
1. En la página de autorización de Slack, instálala directamente en los espacios de trabajo, no a nivel de la organización.
1. Elige un espacio de trabajo en el menú desplegable. No selecciones un Enterprise Grid.
1. Instálalo por espacio de trabajo según sea necesario para tu organización.
1. Revisa los ámbitos solicitados y haz clic en **Permitir** para autorizar la integración.
1. Tras la autorización, volverá a la consola del AWS DevOps agente.
## Asocia Slack a tus espacios de DevOps agente
Tras registrar Slack en tu espacio de DevOps agente, puedes asociarlo a tus espacios de DevOps agente:
1. En la pestaña **Capacidades** de tu configuración AgentSpace, ve a **Comunicaciones** > **Slack**.
1. Selecciona **Añadir Slack**
1. Ingresa el ID del canal
1. Selecciona **Crear** para completar la configuración de Slack.
**nota**
**El usuario bot del agente debe añadirse a los canales privados para que pueda publicar mensajes.
**importante**
**Si desinstalas la aplicación de Slack, es posible que no se pueda volver a instalar. Evita desinstalar la aplicación de Slack.
# Invocar al DevOps agente a través de Webhook
Los webhooks permiten que los sistemas externos AWS DevOps activen automáticamente las investigaciones de los agentes. Esto permite la integración con sistemas de emisión de tickets, herramientas de monitoreo y otras plataformas que pueden enviar solicitudes HTTP cuando se producen incidentes.
## Requisitos previos
Antes de configurar el acceso a los webhooks, asegúrate de tener:
+ Un espacio de agente configurado en AWS DevOps Agent
+ Acceso a la consola del AWS DevOps agente
+ El sistema externo que enviará las solicitudes de webhook
## Tipos de webhook
AWS DevOps El agente admite los siguientes tipos de webhooks:
+ **Webhooks específicos para la integración**: se generan automáticamente al configurar integraciones de terceros, como Dynatrace, Splunk, Datadog, New Relic o Slack. ServiceNow Estos webhooks están asociados a la integración específica y utilizan métodos de autenticación determinados por el tipo de integración
+ **Webhooks genéricos**: se pueden crear manualmente para iniciar investigaciones desde cualquier fuente que no esté incluida en una integración específica. Los webhooks genéricos utilizan actualmente la autenticación **HMAC** (el token portador no está disponible actualmente).
+ **Webhooks de alertas de Grafana:** Grafana puede enviar notificaciones de alerta directamente al AWS DevOps agente a través de los puntos de contacto de webhook. Para obtener instrucciones de configuración que incluyen una plantilla de notificación personalizada, consulte [Conectar Grafana](connecting-telemetry-sources-connecting-grafana.md).
## Métodos de autenticación de Webhook
El método de autenticación de tu webhook depende de la integración a la que esté asociado:
**Autenticación HMAC**: utilizada por:
+ Webhooks de integración con Dynatrace
+ Webhooks genéricos (no vinculados a una integración específica de terceros)
**Autenticación mediante token de portador**: utilizada por:
+ Webhooks de integración con Splunk
+ Webhooks de integración de Datadog
+ Webhooks de integración de New Relic
+ ServiceNow webhooks de integración
+ Webhooks de integración de Slack
## Configurar el acceso a los webhooks
### Paso 1: Navega hasta la configuración del webhook
1. Inicie sesión en la consola AWS de administración y navegue hasta la consola del AWS DevOps agente
1. Seleccione su espacio de agente
1. Ve a la pestaña **Capacidades**
1. **En la sección **Webhook**, haga clic en Configurar**
### Paso 2: Generar las credenciales del webhook
**Para webhooks específicos de la integración:**
Los webhooks se generan automáticamente al completar la configuración de una integración de terceros. La URL y las credenciales del punto final del webhook se proporcionan al final del proceso de configuración de la integración.
**Para los webhooks genéricos:**
1. Haz clic en **Generar webhook**
1. El sistema generará un key pair HMAC
1. Guarde de forma segura la clave y el secreto generados; no podrá volver a recuperarlos
1. Copia la URL del punto de conexión del webhook proporcionada
### Paso 3: Configura tu sistema externo
Utilice la URL y las credenciales del punto de conexión del webhook para configurar su sistema externo y enviar solicitudes al AWS DevOps agente. Los pasos de configuración específicos dependen del sistema externo.
## Administrar las credenciales de webhook
**Eliminar credenciales****: para eliminar las credenciales del webhook, vaya a la sección de configuración del webhook y haga clic en Eliminar.** Tras eliminar las credenciales, el punto final del webhook ya no aceptará solicitudes hasta que generes nuevas credenciales.
**Regeneración de credenciales**: para generar nuevas credenciales, elimine primero las credenciales existentes y, a continuación, genere un nuevo key pair o token.
## Uso del webhook
### Formato de solicitud de webhook
Para iniciar una investigación, tu sistema externo debe enviar una solicitud HTTP POST a la URL del punto final del webhook.
**Para la versión 1 (autenticación HMAC):**
Encabezados:
+ `Content-Type: application/json`
+ `x-amzn-event-signature: `
+ `x-amzn-event-timestamp: <+%Y-%m-%dT%H:%M:%S.000Z>`
La firma HMAC se genera al firmar el cuerpo de la solicitud con tu clave secreta mediante el SHA-256.
**Para la versión 2 (autenticación con token de portador):**
Encabezados:
+ `Content-Type: application/json`
+ `Authorization: Bearer `
**Cuerpo de la solicitud:**
El organismo solicitante debe incluir información sobre el incidente:
```
json
{
"title": "Incident title",
"severity": "high",
"affectedResources": ["resource-id-1", "resource-id-2"],
"timestamp": "2025-11-23T18:00:00Z",
"description": "Detailed incident description",
"data": {
"metadata": {
"region": "us-east-1",
"environment": "production"
}
}
}
```
### Código de ejemplo
**Versión 1 (autenticación 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);
});
```
**Versión 1 (autenticación 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 <
### Si no recibes un 200
Un 200 y un mensaje como el webhook recibido indican que la autenticación se ha aprobado y que el mensaje se ha puesto en cola para que el sistema lo verifique y procese. Si no obtienes un 200 sino un 4xx, lo más probable es que haya algún problema con la autenticación o los encabezados. Intenta enviarlo manualmente usando las opciones curl para ayudar a depurar la autenticación.
### Si recibes un 200 pero no se inicia una investigación
La causa probable es una carga mal formateada.
1. Compruebe que tanto la marca de tiempo como el identificador del incidente estén actualizados y sean únicos. Los mensajes duplicados se deduplican.
1. Comprueba que el mensaje es un JSON válido
1. Comprueba que el formato es correcto
### Si recibes un 200\$1 y la investigación se cancela inmediatamente
Lo más probable es que hayas alcanzado el límite del mes. Hable con su persona de AWS contacto para solicitar un cambio en el límite de la tarifa, si es necesario.
## Temas relacionados
+ [Creación de un espacio de agentes](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
+ [¿Qué es una aplicación web para DevOps agentes?](about-aws-devops-agent-what-is-a-devops-agent-web-app.md)
+ [DevOps Permisos de IAM para agentes](aws-devops-agent-security-devops-agent-iam-permissions.md)
# Integración de AWS DevOps Agent con Amazon EventBridge
Puede integrar AWS DevOps Agent con sus aplicaciones basadas en eventos utilizando los eventos que se producen durante los ciclos de vida de la investigación y la mitigación. AWS DevOps El agente envía eventos a Amazon EventBridge cuando cambia el estado de una investigación o mitigación. A continuación, puede crear EventBridge reglas que actúen en función de estos eventos.
Por ejemplo, puede crear reglas que realicen las siguientes acciones:
+ Invoque una función AWS Lambda para procesar los resultados de la investigación cuando se complete una investigación.
+ Envía una notificación a Amazon SNS cuando una investigación falle o se agote el tiempo de espera.
+ Actualice un sistema de emisión de entradas cuando se cree una nueva investigación.
+ Inicie un flujo de trabajo de AWS Step Functions cuando se complete una acción de mitigación.
## ¿Cómo EventBridge dirige los eventos AWS DevOps del agente?
AWS DevOps El agente envía los eventos al bus de eventos EventBridge predeterminado. EventBridge a continuación, evalúa los eventos según las reglas que usted cree. Cuando un evento coincide con el patrón de eventos de una regla, EventBridge envía el evento a los destinos especificados.
El siguiente diagrama muestra cómo se distribuyen EventBridge los eventos AWS DevOps del agente.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/eventbridge-integration-how-it-works.png)
1. AWS DevOps El agente envía un evento al bus de eventos EventBridge predeterminado cuando cambia el estado del ciclo de vida de una investigación o mitigación.
1. EventBridge evalúa el evento según las reglas que usted creó.
1. Si el evento coincide con el patrón de eventos de una regla, EventBridge envía el evento a los destinos especificados en la regla.
## AWS DevOps Eventos del agente
AWS DevOps El agente envía los siguientes eventos a EventBridge. Todos los eventos utilizan la fuente`aws.aidevops`.
### Eventos de investigación respaldados
| detail-type | Description (Descripción) |
| --- | --- |
| Investigation Created | Se creó una investigación en el espacio de agentes. |
| Investigation Priority Updated | Se cambió la prioridad de una investigación. |
| Investigation In Progress | Una investigación inició un análisis activo. |
| Investigation Completed | Una investigación terminó satisfactoriamente con los hallazgos. |
| Investigation Failed | Se detectó un error en la investigación y no se pudo completar. |
| Investigation Timed Out | Una investigación superó la duración máxima permitida. |
| Investigation Cancelled | Se canceló una investigación antes de su finalización. |
| Investigation Pending Triage | Hay una investigación pendiente de clasificación antes de que comience el análisis activo. |
| Investigation Linked | Una investigación estaba relacionada con un incidente o una multa relacionados. |
### Eventos de mitigación compatibles
| detail-type | Description (Descripción) |
| --- | --- |
| Mitigation In Progress | Se inició una acción de mitigación. |
| Mitigation Completed | Una acción de mitigación finalizó satisfactoriamente. |
| Mitigation Failed | Una acción de mitigación detectó un error y no se pudo completar. |
| Mitigation Timed Out | Una acción de mitigación ha superado la duración máxima permitida. |
| Mitigation Cancelled | Se canceló una acción de mitigación antes de completarse. |
Para obtener descripciones de campo detalladas y ejemplos de eventos, consulte[AWS DevOps Referencia detallada de eventos de agentes](integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-devops-agent-events-detail-reference.md).
## Crear patrones de eventos que coincidan con los eventos del AWS DevOps agente
EventBridge las reglas utilizan patrones de eventos para seleccionar eventos y enviarlos a los objetivos. Un patrón de eventos coincide con la estructura de los eventos que gestiona. Los patrones de eventos se crean para filtrar los eventos del AWS DevOps agente en función de los campos de eventos.
Los siguientes ejemplos muestran patrones de eventos para casos de uso comunes.
**Haga coincidir todos los eventos AWS DevOps del agente**
El siguiente patrón de eventos coincide con todos los eventos del AWS DevOps agente.
```
{
"source": ["aws.aidevops"]
}
```
**Coincide solo con los eventos de investigación**
El siguiente patrón de eventos utiliza una coincidencia de prefijos para seleccionar solo los eventos del ciclo de vida de la investigación.
```
{
"source": ["aws.aidevops"],
"detail-type": [{"prefix": "Investigation"}]
}
```
**Haga coincidir solo los eventos de finalización y error**
El siguiente patrón de eventos coincide con los eventos de las investigaciones y mitigaciones finalizadas o fallidas.
```
{
"source": ["aws.aidevops"],
"detail-type": [
"Investigation Completed",
"Investigation Failed",
"Mitigation Completed",
"Mitigation Failed"
]
}
```
**Haga coincidir los eventos de un espacio de agentes específico**
El siguiente patrón de eventos coincide con los eventos de un espacio de agentes específico.
```
{
"source": ["aws.aidevops"],
"detail": {
"metadata": {
"agent_space_id": ["your-agent-space-id"]
}
}
}
```
Para obtener más información sobre los patrones de eventos, consulta los [patrones de EventBridge eventos de Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) en la *Guía del EventBridge usuario de Amazon*.
## EventBridge Permisos de Amazon
AWS DevOps El agente no necesita permisos adicionales para enviar eventos a EventBridge. Los eventos se envían automáticamente al bus de eventos predeterminado.
En función de los destinos que configure para sus EventBridge reglas, es posible que necesite añadir permisos específicos. Para obtener más información sobre los permisos necesarios para los objetivos, consulta [Uso de políticas basadas en recursos para Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) en la Guía del * EventBridge usuario de Amazon*.
## Recursos adicionales EventBridge
Para obtener más información sobre EventBridge los conceptos y la configuración, consulta los siguientes temas de la *Guía del EventBridge usuario de Amazon*:
+ [EventBridge autobuses de eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)
+ [EventBridge eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)
+ [EventBridge patrones de eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [EventBridge reglas](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)
+ [EventBridge objetivos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)
# AWS DevOps Referencia detallada de eventos de agentes
Los eventos de AWS los servicios tienen campos de metadatos comunes `source``detail-type`, como`account`,`region`, y`time`. Estos eventos también contienen un `detail` campo con datos específicos del servicio. En el caso de los eventos del AWS DevOps agente, el símbolo `source` es siempre `aws.aidevops` y el `detail-type` identifica el evento específico.
## Eventos de investigación
Los siguientes `detail-type` valores identifican los eventos de investigación:
+ `Investigation Created`
+ `Investigation Priority Updated`
+ `Investigation In Progress`
+ `Investigation Completed`
+ `Investigation Failed`
+ `Investigation Timed Out`
+ `Investigation Cancelled`
+ `Investigation Pending Triage`
+ `Investigation Linked`
Los `detail-type` campos `source` y se incluyen a continuación porque contienen valores específicos para los eventos AWS DevOps del agente. Para ver las definiciones de los demás campos de metadatos que se incluyen en todos los eventos, consulte [Estructura de eventos](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) en la *referencia de Amazon EventBridge Events*.
La siguiente es la estructura JSON para los eventos de investigación.
```
{
. . .,
"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 el tipo de evento. En el caso de los eventos de investigación, este es uno de los nombres de eventos enumerados anteriormente.
**`source`**Identifica el servicio que generó el evento. Para los eventos del AWS DevOps agente, este valor es`aws.aidevops`.
**`detail`**Un objeto JSON que contiene datos específicos del evento. El `detail` objeto incluye los siguientes campos:
+ `version`(cadena): la versión esquemática del detalle del evento. Actualmente`1.0.0`.
+ `metadata.agent_space_id`(cadena): el identificador único del espacio de agentes donde se originó el evento.
+ `metadata.task_id`(cadena): el identificador único de la tarea.
+ `metadata.execution_id`(cadena): el identificador único de la ejecución. Está presente cuando se ha asignado una ejecución a la investigación.
+ `data.task_type`(cadena): el tipo de tarea. Valor:`INVESTIGATION`.
+ `data.priority`(cadena): el nivel de prioridad. Valores:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(cadena): el estado actual. Valores:`PENDING_START`, `IN_PROGRESS``COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`,`PENDING_TRIAGE`,`LINKED`.
+ `data.created_at`(cadena): marca de tiempo ISO 8601 en la que se creó la tarea.
+ `data.updated_at`(cadena): fecha y hora ISO 8601 de la última actualización de la tarea.
+ `data.summary_record_id`(cadena): identificador del acta resumida que contiene los resultados de la investigación. Se incluye cuando se genera un resumen de la investigación finalizada. Puede recuperar el contenido del resumen a través de la API AWS DevOps Agent utilizando este identificador para buscar el registro del diario con un tipo de registro de`investigation_summary_md`.
**Ejemplo: evento «Investigación completada»**
```
{
"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"
}
}
}
```
**Ejemplo: evento fallido en la investigación**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789016",
"detail-type": "Investigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:10:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "b2c3d4e5-6789-01ab-cdef-example22222"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:10:00Z"
}
}
}
```
## Eventos de mitigación
Los siguientes `detail-type` valores identifican los eventos de mitigación:
+ `Mitigation In Progress`
+ `Mitigation Completed`
+ `Mitigation Failed`
+ `Mitigation Timed Out`
+ `Mitigation Cancelled`
Los `detail-type` campos `source` y se incluyen a continuación porque contienen valores específicos para los eventos AWS DevOps del agente. Para ver las definiciones de los demás campos de metadatos que se incluyen en todos los eventos, consulte [Estructura de eventos](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html) en la *referencia de Amazon EventBridge Events*.
La siguiente es la estructura de JSON para los eventos de mitigación.
```
{
. . .,
"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 el tipo de evento. En el caso de los eventos de mitigación, este es uno de los nombres de eventos enumerados anteriormente.
**`source`**Identifica el servicio que generó el evento. Para los eventos del AWS DevOps agente, este valor es`aws.aidevops`.
**`detail`**Un objeto JSON que contiene datos específicos del evento. El `detail` objeto incluye los siguientes campos:
+ `version`(cadena): la versión esquemática del detalle del evento. Actualmente`1.0.0`.
+ `metadata.agent_space_id`(cadena): el identificador único del espacio de agentes donde se originó el evento.
+ `metadata.task_id`(cadena): el identificador único de la tarea.
+ `metadata.execution_id`(cadena): el identificador único de la ejecución. Está presente cuando se ha asignado una ejecución a la mitigación.
+ `data.task_type`(cadena): el tipo de tarea. Valor:`INVESTIGATION`.
+ `data.priority`(cadena): el nivel de prioridad. Valores:`CRITICAL`,`HIGH`,`MEDIUM`,`LOW`,`MINIMAL`.
+ `data.status`(cadena): el estado actual. Valores:`IN_PROGRESS`,`COMPLETED`,`FAILED`,`TIMED_OUT`,`CANCELLED`.
+ `data.created_at`(cadena): marca de tiempo ISO 8601 en la que se creó la tarea.
+ `data.updated_at`(cadena): fecha y hora ISO 8601 de la última actualización de la tarea.
+ `data.summary_record_id`(cadena): el identificador del registro resumido que contiene los resultados de la mitigación. Se incluye cuando se genera un resumen de la mitigación completada. Puede recuperar el contenido del resumen a través de la API del AWS DevOps agente utilizando este identificador para buscar el registro del diario con un tipo de registro de`mitigation_summary_md`.
**Ejemplo: evento Mitigación completada**
```
{
"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"
}
}
}
```
**Ejemplo: Evento fallido de mitigación**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-12345678901d",
"detail-type": "Mitigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:20:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "c3d4e5f6-7890-12ab-cdef-example33333"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:20:00Z"
}
}
}
```
# Registros y métricas de Vended
Puedes monitorear tus espacios de agente y tus operaciones de servicio mediante CloudWatch métricas y registros vendidos de Amazon. En este tema se describen las CloudWatch métricas que el AWS DevOps agente publica automáticamente en tu cuenta y los registros de ventas que puedes configurar para realizar entregas en los destinos que prefieras.
## Métricas vendidas CloudWatch
AWS DevOps El agente publica automáticamente las métricas CloudWatch en Amazon en tu cuenta. Estas métricas están disponibles sin ninguna configuración. Puede utilizarlos para supervisar el uso, realizar un seguimiento de la actividad operativa y crear alarmas.
### Rol vinculado a servicio
Para que CloudWatch las métricas de Amazon se publiquen en su cuenta para este servicio, el AWS DevOps agente creará automáticamente el [rol vinculado al servicio **AWSServiceRoleForAIDevOps** Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) para usted. Si el rol de IAM que invoca la API no tiene el permiso adecuado, la creación del recurso fallará con un. InvalidParameterException
**importante**
Los clientes que hayan creado su rol AgentSpace antes del 13 de marzo de 2026 deberán crear manualmente el rol vinculado al servicio de **AWSServiceRoleForAIDevoperaciones** para que CloudWatch las métricas del AWS DevOps agente se publiquen en su cuenta.
### Cree manualmente un rol vinculado al servicio (para clientes existentes)
Realice una de las siguientes acciones:
+ **En la consola de IAM, cree el rol **AWSServiceRoleForAIDevOps** en el servicio de agente.AWS DevOps **
+ Desde la AWS CLI, ejecute el siguiente comando:
```
aws iam create-service-linked-role --aws-service-name aidevops.amazonaws.com
```
### Namespace
Todas las métricas se publican en el espacio de `AWS/AIDevOps` nombres.
### Dimensiones
Todas las métricas incluyen la siguiente dimensión.
| Dimensión | Description (Descripción) |
| --- | --- |
| AgentSpaceUUID | El identificador único del espacio de agentes. Para agregar métricas en todos los espacios de agentes de su cuenta, utilice expresiones CloudWatch matemáticas u omita el filtro de dimensiones. |
### Referencia de métricas
| Nombre de métrica | Description (Descripción) | Unidad | Frecuencia de publicación | Estadísticas útiles |
| --- | --- | --- | --- | --- |
| ConsumedChatRequests | El número de solicitudes de chat que ha consumido el espacio de un agente. Para obtener el recuento total de tu cuenta, usa la SUM estadística en todas las AgentSpaceUUID dimensiones. | Recuento | Cada 5 minutos | Suma, media |
| ConsumedInvestigationTime | El tiempo dedicado a realizar investigaciones en un espacio de agentes. | Segundos | Cada 5 minutos | Suma, media, máxima |
| ConsumedEvaluationTime | El tiempo dedicado a ejecutar las evaluaciones en un espacio de agentes. | Segundos | Cada 5 minutos | Suma, media y máxima |
| TopologyCompletionCount | El número de procesamientos topológicos finalizados. AWS DevOps El agente emite esta métrica cuando una topología termina de procesarse, ya sea desde la creación inicial durante la incorporación, una actualización manual o una actualización diaria programada. | Recuento | Basado en eventos (se emite cada vez que se completa) | Suma, SampleCount |
### Visualización de las métricas en la CloudWatch consola
1. Abra la [consola de CloudWatch ](https://console.aws.amazon.com/cloudwatch/).
1. En el panel de navegación, elija **Metrics** (Métricas) y, a continuación, **All metrics** (Todas las métricas).
1. Elija el espacio de nombres **AWS AIDev/Ops**.
1. Seleccione **Por AgentSpace** para ver las métricas de sus espacios de agentes.
**nota**
**Puede crear CloudWatch alarmas en estas métricas para recibir notificaciones cuando el uso supere un umbral. Por ejemplo, crea una alarma `ConsumedChatRequests` para controlar el consumo de solicitudes de chat.
## Requisitos previos
Antes de configurar la entrega de registros, asegúrese de tener lo siguiente:
+ Una AWS cuenta activa con acceso a la consola del AWS DevOps agente
+ Un director de IAM con permisos para la entrega de CloudWatch registros APIs
+ (Opcional) Un bucket de Amazon S3 o una transmisión de entrega de Amazon Data Firehose, si piensa utilizarlos como destinos de registro
## Registros proporcionados
AWS DevOps El agente admite registros vendidos que proporcionan visibilidad de los eventos que procesan los espacios de agente y los registros de servicios. Los registros vendidos utilizan la infraestructura de Amazon CloudWatch Logs para entregar los registros a su destino preferido.
Para utilizar los registros vendidos, debe configurar un destino de entrega. Se admiten los siguientes destinos:
+ **Amazon CloudWatch Logs**: un grupo de registros en tu cuenta
+ **Amazon S3**: un bucket de S3 en su cuenta
+ **Amazon Data Firehose**: un flujo de entrega de Firehose en tu cuenta
### Tipos de registro admitidos
Se admite un solo tipo de registro:. `APPLICATION_LOGS` Este tipo de registro cubre todos los eventos operativos que emite el servicio.
### Registra los tipos de eventos
En la siguiente tabla se resumen los eventos que el AWS DevOps agente registra.
| Event | Description (Descripción) | Nivel de registro |
| --- | --- | --- |
| El agente recibió un evento entrante | Un agente es activado por una fuente integrada y recibe un evento entrante (por ejemplo, un evento de PagerDuty incidente). | INFO |
| Se descarta el evento entrante del agente | Se descartó un evento entrante antes de que el agente lo procesara. El registro incluye el motivo (por ejemplo, datos con formato incorrecto). | POR DETERMINAR |
| Fallo en la comunicación saliente del agente | Se produjo un error en la comunicación saliente con una integración de terceros. El registro incluye el identificador de la tarea y el identificador de destino (por ejemplo, un error de autenticación). | POR DETERMINAR |
| Creación de topología en cola | Se puso en cola un trabajo de creación de topología para su procesamiento. | INFO |
| Se inició la creación de la topología | Se inició el procesamiento de un trabajo de creación de topología. | INFO |
| Finalizó la creación de la topología | Se completó el procesamiento de un trabajo de creación de topología. Este evento se aplica a la creación inicial, a las actualizaciones y a las actualizaciones diarias. | INFO |
| Falló el descubrimiento de recursos | Se produjo un error en la detección de recursos durante la creación de la topología. | ERROR |
| Falló el registro del servicio | El registro del servicio presenta un error irrecuperable | ERROR |
| La validación de Webhook falla | Cuando el webhook recibido por el agente de Devops no coincide con el esquema esperado | ERROR |
| Se actualiza el estado de validación de la asociación | Cuando se asocia un espacio de agentes (una primary/secondary cuenta típica), el estado de la validación cambia de válido a no válido y viceversa (por ejemplo, debido a un rol mal diseñado, que el servicio no puede asumir). | ERROR/INFORMACIÓN |
### Permisos
AWS DevOps El agente usa [registros CloudWatch vendidos (permisos V2)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) para entregar los registros. Para configurar la entrega de registros, la función de IAM que configura la entrega debe tener los siguientes permisos:
+ `aidevops:AllowVendedLogDeliveryForResource`— Necesario para permitir la entrega de registros para el recurso de espacio del agente.
+ Permisos para la entrega de CloudWatch registros APIs (`logs:PutDeliverySource``logs:PutDeliveryDestination`,`logs:CreateDelivery`, y operaciones relacionadas).
+ Permisos específicos para el destino de entrega elegido.
Para ver la política de IAM completa que se requiere para cada tipo de destino, consulte los siguientes temas de la *Guía del usuario de Amazon CloudWatch Logs*:
+ [Registros enviados a CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-CloudWatchLogs.html)
+ [Registros enviados a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html)
+ [Registros enviados a Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)
### Configurar la entrega de registros (consola)
AWS DevOps El agente proporciona dos ubicaciones en la consola AWS de administración para configurar la entrega de registros:
+ **Página de configuración de registro del servicio**: configure la entrega de registros para los eventos de nivel de servicio. Estos registros utilizan el ARN del servicio (`arn:aws:aidevops:::service/`) como recurso.
+ **Página Agent Space**: configure la entrega de registros para los eventos específicos de un espacio de agente individual. Estos registros utilizan el ARN (`arn:aws:aidevops:::agentspace/`) del espacio de agentes como recurso.
#### Para configurar la entrega de registros para el registro de un servicio
1. Abra la consola del AWS DevOps agente en la consola AWS de administración.
1. En el panel de navegación, seleccione **Configuración**.
1. En la pestaña **Proveedores de capacidades** **>** **Registros**, seleccione **Configurar**.
1. En **Tipo de destino**, elija una de las siguientes opciones:
1. **CloudWatch Registros**: seleccione o cree un grupo de registros.
1. **Amazon S3**: introduzca el ARN del bucket S3.
1. **Amazon Data Firehose**: selecciona o crea una transmisión de entrega de Firehose.
1. Para la **configuración adicional** (*opcional*), puede especificar las siguientes opciones:
1. En **Selección de campos**, seleccione los nombres de los campos de registro que desea entregar en su destino. Puede seleccionar [campos de registro de acceso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) y un subconjunto de [campos de registro de acceso en tiempo real](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Solo Amazon S3) En **Partición**, especifique la ruta para particionar los datos del archivo de registro.
1. (Solo Amazon S3) En **Formato de archivo compatible con Hive**, puede seleccionar la casilla de verificación para utilizar rutas de S3 compatibles con Hive. Esto ayuda a simplificar la carga de nuevos datos en las herramientas compatibles con Hive.
1. En **Formato de salida**, especifique el formato que prefiera.
1. En **Delimitador de campo**, especifique cómo separar los campos de registro.
1. Seleccione **Save**.
1. Compruebe que el estado de la entrega sea **Activo**.
#### Para configurar la entrega de registros para un espacio de agentes
1. Abra la consola del AWS DevOps agente en la consola AWS de administración.
1. Elija el espacio de agentes que desee configurar.
1. En la pestaña **Configuración**, elija **Configurar**.
1. En **[Tipo de destino](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2:~:text=sts%3AAssumeRole%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D-,Logging%20that%20requires%20additional%20permissions%20%5BV2%5D,-Some%20AWS%20services)**, elija una de las siguientes opciones:
1. **CloudWatch Registros**: seleccione o cree un grupo de registros.
1. **Amazon S3**: introduzca el ARN del bucket S3.
1. **Amazon Data Firehose**: selecciona o crea una transmisión de entrega de Firehose.
1. Para **ajustes adicionales (\$1opcional)**, puede especificar las siguientes opciones:
1. En **Selección de campos**, seleccione los nombres de los campos de registro que desea entregar en su destino. Puede seleccionar [campos de registro de acceso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) y un subconjunto de [campos de registro de acceso en tiempo real](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection).
1. (Solo Amazon S3) En **Partición**, especifique la ruta para particionar los datos del archivo de registro.
1. (Solo Amazon S3) En **Formato de archivo compatible con Hive**, puede seleccionar la casilla de verificación para utilizar rutas de S3 compatibles con Hive. Esto ayuda a simplificar la carga de nuevos datos en las herramientas compatibles con Hive.
1. En **Formato de salida**, especifique el formato que prefiera.
1. En **Delimitador de campo**, especifique cómo separar los campos de registro.
1. Seleccione **Save**.
1. Comprueba que el estado de la entrega sea **Activo**.
### Configure la entrega de registros (CloudWatch API)
También puede usar la API de CloudWatch registros para configurar la entrega de registros mediante programación. La entrega de un registro funcional consta de tres elementos:
+ A **DeliverySource**: representa el recurso de espacio de AWS DevOps agentes que genera los registros.
+ A **DeliveryDestination**: Representa el destino donde se escriben los registros.
+ Una **entrega**: conecta una fuente de entrega con un destino de entrega.
#### Paso 1: Crear una fuente de entrega
Utilice la [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)operación para crear una fuente de entrega. Pase el ARN de su recurso de espacio de AWS DevOps agente y especifíquelo `APPLICATION_LOGS` como tipo de registro.
El siguiente ejemplo crea una fuente de entrega para un espacio de agentes:
```
{
"name": "my-agent-space-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/my-agent-space-id",
"logType": "APPLICATION_LOGS"
}
```
El siguiente ejemplo crea una fuente de entrega para el servicio:
```
{
"name": "my-service-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:service",
"logType": "APPLICATION_LOGS"
}
```
#### Paso 2: Crear un destino de entrega
Utilice la [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)operación para configurar dónde se almacenan los registros. Puede elegir Amazon CloudWatch Logs, Amazon S3 o Amazon Data Firehose.
En el siguiente ejemplo, se crea un destino de CloudWatch Logs:
```
{
"name": "my-cwl-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/aidevops/my-agent-space"
},
"outputFormat": "json"
}
```
El siguiente ejemplo crea un destino de Amazon S3:
```
{
"name": "my-s3-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::my-aidevops-logs-bucket"
},
"outputFormat": "json"
}
```
El siguiente ejemplo crea un destino Amazon Data Firehose:
```
{
"name": "my-firehose-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-aidevops-log-stream"
},
"outputFormat": "json"
}
```
**nota**
**Si entrega registros entre cuentas, debe utilizarlos [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html)en la cuenta de destino para autorizar la entrega.
Si quieres usar CloudFormation, puedes usar lo siguiente:
+ [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)
El `ResourceArn` es el `AgentSpaceArn` y el `LogType` admitido debe ser `APPLICATION_LOGS`.
#### Paso 3: Crea una entrega
Utilice la [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)operación para vincular la fuente de entrega con el destino de entrega.
```
{
"deliverySourceName": "my-agent-space-delivery-source",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:my-cwl-destination"
}
```
#### AWS CloudFormation
También puede configurar la entrega de registros AWS CloudFormation mediante los siguientes recursos:
+ [AWS: :Registros:: DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
+ [AWS: :Registros:: DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [AWS:: Registros:: Entrega](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
`ResourceArn`Configúrelo en el espacio de AWS DevOps agente o en el ARN del servicio y configúrelo en. `LogType` `APPLICATION_LOGS`
### Referencia del esquema de registro
AWS DevOps El agente usa un esquema de registro compartido en todos los tipos de eventos. No todos los eventos de registro utilizan todos los campos.
En la siguiente tabla se describen los campos del esquema de registro.
| Campo | Tipo | Description (Descripción) |
| --- | --- | --- |
| event\$1timestamp | Largo | Marca de tiempo de Unix del momento en que ocurrió el evento |
| resource\$1arn | Cadena | ARN del recurso que generó el evento |
| optional\$1account\$1id | Cadena | AWS ID de cuenta asociada al registro. |
| nivel\$1opcional | Cadena | Nivel de registro:,, INFO WARN ERROR |
| optional\$1agent\$1space\$1id | Cadena | Identificador del espacio de agentes. |
| optional\$1association\$1id | Cadena | Identificador de asociación para el registro. |
| estado\$1opcional | Cadena | Estado de la operación de topología. |
| optional\$1webhook\$1id | Cadena | Identificador de webhook. |
| optional\$1mcp\$1endpoint\$1url | Cadena | URL del punto final del servidor MCP |
| tipo\$1de\$1servicio\$1opcional | Cadena | Tipo de servicio:DYNATRACE,,,,. DATADOG GITHUB SLACK SERVICENOW |
| optional\$1service\$1endpoint\$1url | Cadena | URL de punto final para integraciones de terceros. |
| optional\$1service\$1id | Cadena | Identificador de la fuente. |
| request\$1id | Cadena | Identificador de solicitud para correlacionarlo con los tickets de soporte AWS CloudTrail o de soporte. |
| operación\$1opcional | Cadena | Nombre de la operación que se realizó. |
| tipo\$1de\$1tarea opcional | Cadena | Tipo de tarea pendiente del agente: o INVESTIGATION EVALUATION |
| optional\$1task\$1id | Cadena | Identificador de tareas pendientes de Agent Backlog Task. IDAgent |
| referencia\$1opcional | Cadena | Referencia de una tarea de un agente (por ejemplo, un ticket de Jira). |
| Tipo\$1de\$1error opcional | Cadena | Tipo de error |
| mensaje\$1de\$1error opcional | Cadena | Descripción del error cuando se produce un error en una operación. |
| detalles\$1opcionales | Cadena (JSON) | Carga útil de eventos específica del servicio que contiene los parámetros y resultados de la operación. |
### Administre e inhabilite la entrega de registros
Puede modificar o eliminar la entrega de registros en cualquier momento desde la consola de AWS DevOps agente de la consola AWS de administración o mediante la API de CloudWatch registros.
#### Gestione la entrega de registros (consola)
1. Abra la consola del AWS DevOps agente en la consola AWS de administración.
1. Diríjase a la página de **configuración** (para los registros de nivel de servicio) o a la página específica de **Agent Space** (para los registros de nivel de Agent Space).
1. En la pestaña **Configuración** (para los registros a nivel de espacio de agente) o en la pestaña **Proveedores de capacidades** **>** Registros (para **los registros** a nivel de servicio), seleccione la entrega que desee modificar.
1. **Actualice la configuración según sea necesario y seleccione Guardar.**
**Nota:** No puedes cambiar el tipo de destino de un envío existente. Para cambiar el tipo de destino, elimina la entrega actual y crea una nueva.
#### Inhabilite la entrega de registros (consola)
1. Abra la consola del AWS DevOps agente en la consola AWS de administración.
1. Diríjase a la página de **configuración** (para los registros de nivel de servicio) o a la página específica de **Agent Space** (para los registros de nivel de Agent Space).
1. En la pestaña **Configuración** (para los registros a nivel de espacio de agente) o en la pestaña **Proveedores de capacidades** **>** **Registros (para los registros** a nivel de servicio), seleccione la entrega que desee eliminar.
1. **Seleccione Eliminar y confirme.**
#### Inhabilite la entrega de registros (API)
Para eliminar una entrega de registros mediante la API, elimine los recursos en el siguiente orden:
1. Elimine la entrega mediante [DeleteDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDelivery.html).
1. Elimine la fuente de entrega mediante [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html).
1. (Opcional) Si el destino de entrega ya no es necesario, elimínelo utilizando [DeleteDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliveryDestination.html).
**importante**
**Usted es responsable de eliminar los recursos de entrega de registros después de eliminar el recurso de espacio de agente que genera los registros (por ejemplo, después de eliminar un espacio de agente). Si no eliminas estos recursos, es posible que queden configuraciones de entrega huérfanas.
## Precios
El AWS DevOps agente no cobra por habilitar los registros vendidos. Sin embargo, puede incurrir en cargos por la entrega, la ingesta, el almacenamiento o el acceso, según el destino de entrega de los registros que seleccione. Para obtener más información sobre los precios, consulta **Vended Logs** en la pestaña **Logs** de [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Para conocer los precios específicos de cada destino, consulta lo siguiente:
+ [Precios de Amazon CloudWatch Logs](https://aws.amazon.com/cloudwatch/pricing/)
+ [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/)
+ [Precios de Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/pricing/)
# Conexión a herramientas alojadas de forma privada
## Descripción general de las conexiones privadas
AWS DevOps El agente se puede ampliar con herramientas personalizadas del Model Context Protocol (MCP) y otras integraciones que permiten al agente acceder a los sistemas internos, como los registros de paquetes privados, las plataformas de observabilidad autohospedadas, la documentación APIs interna y las instancias de control de código fuente (consulte:). [Configuración de las capacidades del AWS DevOps agente](configuring-capabilities-for-aws-devops-agent.md) Estos servicios suelen ejecutarse dentro de una [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide) con acceso a Internet público o restringido, lo que significa que el AWS DevOps agente no puede acceder a ellos de forma predeterminada.
Las conexiones privadas para AWS DevOps Agent le permiten conectar de forma segura su Agent Space a los servicios que se ejecutan en su VPC sin exponerlos a la Internet pública. Las conexiones privadas funcionan con cualquier integración que necesite llegar a un punto final privado, incluidos los servidores MCP, las instancias de Grafana o Splunk autohospedadas y los sistemas de control de código fuente como GitHub Enterprise Server y Self-Managed. GitLab
**nota**
**Si sus herramientas alojadas de forma privada realizan solicitudes salientes al AWS DevOps agente desde su VPC, este tráfico también se puede proteger mediante un punto de enlace de la VPC para que permanezca dentro de la red. AWS Por ejemplo, esto se puede utilizar con herramientas que activan el DevOps agente mediante eventos de webhook (consulte:). [Invocar al DevOps agente a través de Webhook](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) Para obtener más información, consulte [Puntos de enlace de la VPC (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md).
### Cómo funcionan las conexiones privadas
Una conexión privada crea una ruta de red segura entre el AWS DevOps agente y un recurso de destino en la VPC. De manera clandestina, AWS DevOps Agent utiliza Amazon [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) para establecer esta ruta de conectividad privada segura. VPC Lattice es un servicio de redes de aplicaciones que le permite conectar, proteger y supervisar la comunicación entre aplicaciones VPCs, cuentas y tipos de procesamiento, sin administrar la infraestructura de red subyacente.
Al crear una conexión privada, ocurre lo siguiente:
+ Usted proporciona la VPC, las subredes y (opcionalmente) los grupos de seguridad que tienen conectividad de red con el servicio de destino.
+ AWS DevOps El agente crea una [puerta de enlace de recursos gestionada por un servicio y aprovisiona](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html) sus interfaces de red elásticas (ENIs) en las subredes que especificó.
+ El agente usa la puerta de enlace de recursos para enrutar el tráfico a la dirección IP o el nombre DNS del servicio de destino a través de la ruta de red privada.
El AWS DevOps agente administra completamente la puerta de enlace de recursos y aparece como un recurso de solo lectura en su cuenta (nombre`aidevops-{your-private-connection-name}`). No necesita configurarlo ni mantenerlo. Los únicos recursos que se crean en la VPC se encuentran ENIs en las subredes que especifique. ENIs Sirven como punto de entrada para el tráfico privado y el servicio los administra en su totalidad. No aceptan conexiones entrantes de Internet y tú conservas el control total sobre su tráfico a través de tus propios grupos de seguridad.
### Seguridad
Las conexiones privadas están diseñadas con varios niveles de seguridad:
+ **Sin exposición a Internet pública**: todo el tráfico entre el AWS DevOps agente y el servicio de destino permanece en la AWS red. Su servicio nunca necesita una dirección IP pública ni una puerta de enlace de Internet.
+ Puerta de enlace **de recursos controlada por el servicio: la puerta** de enlace de recursos gestionados por el servicio es de solo lectura en su cuenta. Solo la puede usar el AWS DevOps agente y ningún otro servicio o entidad principal puede dirigir el tráfico a través de ella. Puede verificarlo en [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)los registros, que registran todas las llamadas a la API de VPC Lattice.
+ **Sus grupos de seguridad, sus reglas**: usted controla el tráfico entrante y saliente que llega ENIs a los grupos de seguridad de los que es propietario y que administra. Si no especifica los grupos de seguridad, el AWS DevOps agente crea un grupo de seguridad predeterminado con el alcance de los puertos que defina.
+ **Funciones vinculadas a servicios con privilegios mínimos**: el AWS DevOps agente utiliza una [función vinculada a servicios para crear solo los recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) necesarios de VPC Lattice y Amazon EC2. Este rol se limita a los recursos etiquetados con `AWSAIDevOpsManaged` y no puede acceder a ningún otro recurso de su cuenta.
**nota**
**Si su organización tiene [políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) que restringen las acciones de la API VPC Lattice, la puerta de enlace de recursos gestionados por el servicio se crea mediante un rol vinculado al servicio. Asegúrese de SCPs permitir las acciones necesarias para el rol vinculado al servicio.
### Arquitectura
El siguiente diagrama muestra la ruta de red de una conexión privada.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/7cd6182e6b8d.png)
En esta arquitectura:
+ AWS DevOps El agente inicia una solicitud a su servicio de destino.
+ Amazon VPC Lattice enruta la solicitud a través de la puerta de enlace de recursos gestionados por el servicio de su VPC. Para obtener información sobre las configuraciones avanzadas que utilizan sus propios recursos de VPC Lattice, [consulte Configuración avanzada con los recursos de VPC Lattice existentes](#advanced-setup-using-existing-vpc-lattice-resources).
+ Un ENI de su VPC recibe el tráfico y lo reenvía a la dirección IP o al nombre DNS del servicio de destino.
+ Sus grupos de seguridad determinan qué tráfico se permite a través de. ENIs
+ Desde la perspectiva del servicio de destino, la solicitud se origina en direcciones IP privadas de su ENIs VPC.
## Cree una conexión privada
Puede crear una conexión privada mediante la consola AWS de administración o la AWS CLI.
**nota**
**VPC Lattice no admite las siguientes zonas de disponibilidad:`use1-az3`,,,`usw1-az2`,`apne1-az3`, `apne2-az2``euc1-az2`,`euw1-az4`. `cac1-az3` `ilc1-az2`
### Requisitos previos
Antes de crear una conexión privada, compruebe que dispone de lo siguiente:
+ **Un espacio de agente activo**: necesita un espacio de agente existente en su cuenta. Si no dispone de una, consulte [Cómo empezar con AWS DevOps Agent](getting-started-with-aws-devops-agent.md).
+ **Un servicio de destino al que se pueda acceder de forma privada**: se debe poder acceder a su servidor MCP, plataforma de observabilidad u otro servicio en una dirección IP privada conocida o un nombre de DNS de la VPC en la que se implementa la puerta de enlace de recursos. El servicio se puede ejecutar en la misma VPC, en una VPC interconectada o de forma local, siempre que se pueda enrutar desde las subredes de la puerta de enlace de recursos. El servicio debe ofrecer tráfico HTTPS con una versión TLS mínima de 1.2 en un puerto que especifiques al crear la conexión.
+ **Subredes de la VPC**: identifique de 1 a 20 subredes en las que se ENIs crearán. Recomendamos seleccionar subredes en varias zonas de disponibilidad para obtener una alta disponibilidad. Estas subredes deben tener conectividad de red con el servicio de destino. VPC Lattice puede usar una subred por zona de disponibilidad.
+ **Grupos de seguridad (opcionales)**: si desea controlar el tráfico con reglas específicas, prepare hasta cinco grupos de seguridad para adjuntarlos IDs a ellos. ENIs Si omite los grupos de seguridad, el AWS DevOps agente crea un grupo de seguridad predeterminado.
Las conexiones privadas son recursos a nivel de cuenta. Después de crear una conexión privada, puede reutilizarla en varias integraciones y espacios de agentes que necesiten llegar al mismo anfitrión.
### Cree una conexión privada mediante la consola
1. Abre la consola del AWS DevOps agente.
1. En el panel de navegación, elija **Proveedores de capacidades** y, a continuación, elija **Conexiones privadas**.
1. Seleccione **Crear nuevo perfil de conexión**.
1. En **Nombre**, introduzca un nombre descriptivo para la conexión, por ejemplo`my-mcp-tool-connection`.
1. Para la **VPC**, seleccione la VPC en la que se implementará la puerta de enlace ENIs de recursos.
1. Para **las subredes**, seleccione una o más subredes (hasta 20). Recomendamos elegir subredes en al menos dos zonas de disponibilidad.
1. Para el **tipo de dirección IP**, seleccione el tipo de dirección IP del servicio de destino (`IPv4``IPv6`, o`DualStack`).
1. (Opcional) En **Número de IPv4 direcciones**, si IPv4 seleccionó Dualstack como tipo de dirección IP, puede introducir el número de IPv4 direcciones por ENI para su puerta de enlace de recursos. El valor predeterminado es 16 IPv4 direcciones por ENI.
1. (Opcional) Para **los grupos** de seguridad, seleccione los grupos de seguridad existentes (hasta 5) para restringir el tráfico que puede llegar al servicio de destino. Si no selecciona ninguno, se crea un grupo de seguridad predeterminado.
1. (Opcional) Para los **rangos de puertos**, especifique los puertos TCP en los que escucha la aplicación de destino (por ejemplo, `443` o`8080-8090`). Puede especificar hasta 11 rangos de puertos.
1. En **Dirección de host**, introduzca la dirección IP o el nombre DNS del servicio de destino (por ejemplo, `mcp.internal.example.com` o`10.0.1.50`). Se debe poder acceder al servicio desde la VPC seleccionada. Si elige un nombre DNS, debe poder resolverse desde la VPC seleccionada.
1. (Opcional) En el caso de la **clave pública del certificado**, si la dirección de host que especificó utiliza certificados TLS emitidos por una entidad de certificación privada, introduzca la clave pública del certificado codificada en PEM. Esto permite al AWS DevOps agente confiar en la conexión TLS con el servicio de destino.
1. Elija **Crear conexión**.
El estado de la conexión cambia a **Crear en curso**. Este proceso puede tardar hasta 10 minutos. Cuando el estado cambia a **Activo**, la ruta de red está lista.
Si el estado cambia a **Error al crear**, compruebe lo siguiente:
+ Las subredes que especificó tienen direcciones IP disponibles.
+ Su cuenta no ha alcanzado las cuotas de servicio de VPC Lattice.
+ No hay políticas de IAM restrictivas que impidan que el rol vinculado al servicio cree recursos.
**nota**
**Estos pasos también se pueden realizar seleccionando un proveedor de capacidades `Create a new private connection` durante el registro. Para obtener más información, consulte [Usar una conexión privada con un proveedor de capacidades](#use-a-private-connection-with-a-capability-provider).
### Cree una conexión privada mediante la AWS CLI
Ejecute el siguiente comando para crear una conexión privada. Sustituya los valores de los marcadores de posición por los suyos propios.
```
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 respuesta incluye el nombre de la conexión y un estado de`CREATE_IN_PROGRESS`:
```
{
"name": "my-mcp-tool-connection",
"status": "CREATE_IN_PROGRESS",
"resourceGatewayId": "rgw-0123456789abcdef0",
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0"
}
```
Para comprobar el estado de la conexión, utilice el `describe-private-connection` comando:
```
aws devops-agent describe-private-connection \
--name my-mcp-tool-connection
```
Cuando el estado es`ACTIVE`, tu conexión privada está lista para usarse.
## Use una conexión privada con un proveedor de capacidades
Para usar una conexión privada, puede vincularse a ella durante el registro de un proveedor de capacidades. Las capacidades compatibles que se pueden usar con conexiones privadas incluyen: `GitHub``GitLab`,`MCP Server`, y`Grafana`. Puede realizar este paso mediante la consola AWS de administración o la AWS CLI.
**nota**
**Al registrar un proveedor de capacidades, el AWS DevOps agente valida que el punto final es accesible y responde. Asegúrese de que el servicio de destino esté funcionando y aceptando conexiones antes de completar el registro.
### Utilice una conexión privada con un proveedor de servicios mediante la consola
En la consola del AWS DevOps agente, las conexiones privadas se pueden vincular a una capacidad durante el registro seleccionando la opción «Conectar al punto final mediante una conexión privada».
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/devopsagent/latest/userguide/images/a2a7ffb70ffe.png)
1. Abre la consola del AWS DevOps agente y navega hasta tu espacio de agente.
1. En la sección **Proveedores de capacidades**, seleccione **Registro**.
1. Seleccione **Registrar** para el tipo de capacidad que desee utilizar con la conexión privada.
1. En la vista de detalles de registro, introduzca la URL del punto final al que desee conectarse mediante la conexión privada (por ejemplo,`https://mcp.internal.example.com`).
1. Seleccione **Conectarse al punto final mediante una conexión privada**.
1. Seleccione una conexión privada existente que corresponda a la URL del punto final al que desea conectarse o seleccione **Crear una nueva conexión privada** para crear una.
1. Complete el proceso de registro del proveedor de capacidades.
### Utilice una conexión privada con un proveedor de capacidades mediante la AWS CLI
Puede registrar las capacidades con una conexión privada si incluye el `private-connection-name` argumento. A continuación, se muestra un ejemplo de cómo registrar un servidor MCP con la autorización de clave API mediante la conexión `my-mcp-tool-connection` privada. Sustituya los valores de los marcadores de posición por los suyos propios.
```
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 conexión privada
Una vez que la conexión privada alcance el estado **activo** y la haya utilizado un proveedor de capacidades, compruebe que el AWS DevOps agente pueda acceder al servicio de destino:
1. Abra la consola del AWS DevOps agente y diríjase a su espacio de agente.
1. Inicie una nueva sesión de chat.
1. Invoca un comando que utilice la integración respaldada por tu conexión privada. Por ejemplo, si su herramienta MCP proporciona acceso a una base de conocimientos interna, hágale al agente una pregunta que requiera esa base de conocimientos.
1. Confirme que el agente devuelva los resultados del servicio privado.
Si se produce un error en la conexión, compruebe lo siguiente:
+ **Límites de VPC Lattice**[: compruebe que no ha alcanzado ninguna puerta de enlace de recursos u otros límites de cuota de VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html)
+ **Reglas de los grupos de seguridad**: compruebe que los grupos de seguridad adjuntos ENIs permiten el tráfico saliente en el puerto al que atiende su servicio. Compruebe también que el grupo de seguridad de su servicio permita el tráfico entrante en el puerto de destino. El tráfico proviene del plano de datos de VPC Lattice dentro de IPs su rango CIDR de VPC. Puede utilizar la referencia a grupos de seguridad (permitiendo el grupo de seguridad ENI como fuente) o permitir la entrada desde el CIDR de la VPC.
+ **Conectividad de subred**: compruebe que las subredes que ha seleccionado pueden enrutar el tráfico a su servicio. Si el servicio se ejecuta en una subred diferente, confirme que las tablas de enrutamiento permiten el tráfico entre ellas.
+ **Disponibilidad del servicio**: confirme que su servicio se esté ejecutando y aceptando conexiones en el puerto esperado.
+ **Zona de disponibilidad no compatible**: compruebe que las subredes estén en las zonas de disponibilidad compatibles. Ejecute `aws ec2 describe-subnets --subnet-ids --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'` las zonas de disponibilidad no compatibles enumeradas anteriormente y compruébelas.
## Elimine una conexión privada
Puede eliminar las conexiones privadas no utilizadas mediante la consola AWS de administración o la AWS CLI.
### Elimine una conexión privada mediante la consola
1. Abre la consola del AWS DevOps agente.
1. En el panel de navegación, elija **Proveedores de capacidades** y, a continuación, elija **Conexiones privadas**.
1. Seleccione el menú **Acciones** de la conexión privada que desee eliminar y, a continuación, seleccione **Eliminar**.
La conexión privada se mostrará con el estado «Eliminando conexión» mientras el AWS DevOps agente elimina la puerta de enlace de recursos gestionados y la elimina ENIs de su VPC. Una vez completada la eliminación, la conexión dejará de aparecer en la lista de conexiones privadas.
### Eliminar una conexión privada mediante la AWS CLI
```
aws devops-agent delete-private-connection \
--name my-mcp-tool-connection
```
La respuesta devuelve un estado de`DELETE_IN_PROGRESS`. AWS DevOps El agente elimina la puerta de enlace de recursos gestionados y ENIs la elimina de la VPC. Una vez completada la eliminación, la conexión ya no aparece en la lista de conexiones privadas.
## Configuración avanzada con los recursos de VPC Lattice existentes
Si su organización ya utiliza Amazon VPC Lattice y administra sus propias configuraciones de recursos, puede crear una conexión privada en modo autogestionado. En lugar de que el AWS DevOps agente cree una puerta de enlace de recursos para usted, usted proporciona el nombre de recurso de Amazon (ARN) de una configuración de recursos existente que apunta a su servicio de destino.
Este enfoque resulta útil cuando:
+ Desea tener un control total sobre la pasarela de recursos y el ciclo de vida de la configuración de los recursos.
+ Necesita compartir las configuraciones de recursos entre varias AWS cuentas o servicios.
+ Requiera los registros de acceso de VPC Lattice para una supervisión detallada del tráfico.
+ Ejecute una arquitectura de hub-and-spoke red.
Para crear una conexión privada autogestionada 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"
}
}'
```
Para obtener más información sobre la configuración de las pasarelas de recursos y las configuraciones de recursos de VPC Lattice, consulte la Guía del usuario de Amazon [VPC](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) Lattice.
## Temas relacionados
+ [Puntos de enlace de la VPC (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)
+ [Conexión de servidores MCP](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
+ [Configuración de las capacidades del AWS DevOps agente](configuring-capabilities-for-aws-devops-agent.md)
+ [AWS DevOps Seguridad del agente](aws-devops-agent-security.md)
+ [DevOps Permisos de IAM para agentes](aws-devops-agent-security-devops-agent-iam-permissions.md)