Este producto no es compatible con el sitio Datadog seleccionado. ().
Descripción general
GitLab es una plataforma DevOps que automatiza el ciclo de vida de desarrollo de software con funciones integradas de CI/CD, lo que permite el despliegue automatizado y continuo de aplicaciones con controles de seguridad integrados.
Configure CI Visibility para GitLab a fin de recopilar datos sobre las ejecuciones de sus pipelines, analizar cuellos de botella en el rendimiento, solucionar problemas operativos y optimizar sus flujos de trabajo de despliegue.
Consulte la cantidad de tiempo que los pipelines han estado ejecutando trabajos. Gitlab se refiere a esta métrica como duration. La duración en Gitlab y el tiempo de ejecución pueden mostrar valores diferentes. Gitlab no toma en consideración los trabajos que fallaron debido a ciertos tipos de fallas (como fallas del sistema del ejecutor).
Controle la habilitación de las funciones de CI Visibility, incluyendo el seguimiento de pipelines, el cálculo de rutas críticas y el monitoreo del rendimiento. Asegúrese de que esta casilla esté marcada para activar estas capacidades.
Service (opcional)
Especifique qué nombre de servicio adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre instancias de GitLab. Predeterminado: gitlab-ci
Env (opcional)
Especifique qué entorno (etiqueta env) adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre grupos de instancias de GitLab (por ejemplo, staging o producción). Predeterminado: none
Tags (opcional)
Especifique cualquier etiqueta personalizada para adjuntar a cada tramo generado por la integración. Proporcione una etiqueta por línea en el formato: key:value. Predeterminado: (vacío, sin etiquetas adicionales) Nota: Disponible solo en GitLab.com y GitLab >= 14.8 autogestionado.
Pruebe la integración con el botón Test settings (solo disponible al configurar la integración en un proyecto). Después de que sea exitoso, haga clic en Save changes para finalizar la configuración de la integración. Si el botón falla, haga clic en Save changes y verifique que los primeros webhooks enviados sean exitosos consultando el historial en la sección "Eventos recientes" a continuación.
Configure la integración en un proyecto o grupo yendo a Settings > Integrations > Datadog para cada proyecto o grupo que desee instrumentar. Active la integración a nivel de instancia de GitLab yendo a Admin > Settings > Integrations > Datadog.
Complete los ajustes de configuración de la integración:
Active
Habilita la integración.
Datadog site
Especifique a qué sitio de Datadog enviar los datos. Predeterminado: datadoghq.com Sitio seleccionado:
API URL (opcional)
Permite anular la URL de la API utilizada para enviar datos directamente; solo se usa en escenarios avanzados. Predeterminado: (vacío, sin anulación)
Controle la habilitación de las funciones de CI Visibility, incluyendo el seguimiento de pipelines, el cálculo de rutas críticas y el monitoreo del rendimiento. Asegúrese de que esta casilla esté marcada para activar estas capacidades. Solo está presente a partir de GitLab 17.7 y no es necesario en versiones anteriores.
Service (opcional)
Especifique qué nombre de servicio adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre instancias de GitLab. Predeterminado: gitlab-ci
Env (opcional)
Especifique qué entorno (etiqueta env) adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre grupos de instancias de GitLab (por ejemplo, staging o producción). Predeterminado: none
Tags (opcional)
Especifique cualquier etiqueta personalizada para adjuntar a cada tramo generado por la integración. Proporcione una etiqueta por línea en el formato: key:value. Predeterminado: (vacío, sin etiquetas adicionales) Nota: Disponible solo en GitLab.com y GitLab >= 14.8 autogestionado.
Pruebe la integración con el botón Test settings (solo disponible al configurar la integración en un proyecto). Después de que sea exitoso, haga clic en Save changes para finalizar la configuración de la integración. Si el botón falla, haga clic en Save changes y verifique que los primeros webhooks enviados sean exitosos consultando el historial en la sección "Eventos recientes" a continuación.
Habilite el datadog_ci_integrationfeature flag para activar la integración.
Ejecute uno de los siguientes comandos, que utilizan el Rails Runner de GitLab, dependiendo de su tipo de instalación:
Luego, configure la integración en un proyecto yendo a Settings > Integrations > Datadog para cada proyecto que quiera instrumentar.
Debido a un error en las primeras versiones de GitLab, la integración de Datadog no se puede habilitar a nivel de grupo o instancia en versiones de GitLab < 14.1, incluso si la opción está disponible en la interfaz de usuario de GitLab.
Complete los ajustes de configuración de la integración:
Active
Habilita la integración.
Datadog site
Especifique a qué sitio de Datadog enviar los datos. Predeterminado: datadoghq.com Sitio seleccionado:
API URL (opcional)
Permite anular la URL de la API utilizada para enviar datos directamente; solo se usa en escenarios avanzados. Predeterminado: (vacío, sin anulación)
Especifique qué nombre de servicio adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre instancias de GitLab. Predeterminado: gitlab-ci
Env (opcional)
Especifique qué entorno (etiqueta env) adjuntar a cada tramo generado por la integración. Úselo para diferenciar entre grupos de instancias de GitLab (por ejemplo, staging o producción). Predeterminado: none
Tags (opcional)
Especifique cualquier etiqueta personalizada para adjuntar a cada tramo generado por la integración. Proporcione una etiqueta por línea en el formato: key:value. Predeterminado: (vacío, sin etiquetas adicionales) Nota: Disponible solo en GitLab.com y GitLab >= 14.8 autogestionado.
Pruebe la integración con el botón Test settings (solo disponible al configurar la integración en un proyecto). Después de que sea exitoso, haga clic en Save changes para finalizar la configuración de la integración. Si el botón falla, haga clic en Save changes y verifique que los primeros webhooks enviados sean exitosos consultando el historial en la sección "Eventos recientes" a continuación.
El soporte directo con webhooks no está en desarrollo. Podrían ocurrir problemas inesperados. Datadog recomienda que actualice GitLab en su lugar.
Para versiones anteriores de GitLab, puede usar webhooks para enviar datos de pipeline a Datadog.
Vaya a Settings > Webhooks en su repositorio (o configuración de instancia de GitLab) y agregue un nuevo webhook:
URL: https://webhook-intake./api/v2/webhook/?dd-api-key=<API_KEY> donde <API_KEY> es su clave de Datadog API.
Secret Token: Deje este campo vacío.
Trigger: Seleccione Job events y Pipeline events.
Para establecer parámetros personalizados de env o service, agregue más parámetros de consulta en la URL de los webhooks. Por ejemplo, &env=<YOUR_ENV>&service=<YOUR_SERVICE_NAME>.
Establezca etiquetas personalizadas
Para establecer etiquetas personalizadas en todos los tramos de pipeline y trabajo generados por la integración, agregue un parámetro de consulta codificado en URL tags con pares key:value separados por comas a la URL.
Si un par clave:valor contiene comas, rodéelo con comillas. Por ejemplo, para agregar key1:value1,"key2: value with , comma",key3:value3, se tendría que añadir la siguiente cadena a la Webhook URL: ?tags=key1%3Avalue1%2C%22key2%3A+value+with+%2C+comma%22%2Ckey3%3Avalue3.
Configuración avanzada
Establezca un nombre de pipeline
De forma predeterminada, Datadog utiliza la ruta de su proyecto de GitLab como nombre del pipeline. Como resultado, cada pipeline descendente (secundaria) activada con la palabra clave trigger desde el mismo proyecto aparece con el mismo nombre en Datadog.
Para darle a un pipeline un nombre más significativo, utilice la palabra clave workflow:name de GitLab en su .gitlab-ci.yml. Por ejemplo, para nombrar un pipeline descendente según el trabajo que lo activó:
En el .gitlab-ci.yml del pipeline secundario (o un archivo que incluya), utilice la variable reenviada para establecer el nombre del pipeline:
workflow:name:'$CHILD_PIPELINE_NAME'
Nota: El ejemplo anterior utiliza la expansión de variables en el nombre del pipeline, lo cual requiere GitLab 16.3 o posterior. workflow:name en sí está disponible a partir de GitLab 15.11 para nombres de cadena simples. El nombre del pipeline solo es visible en Datadog a partir de GitLab 16.1, cuando se agregó a la carga útil del webhook del pipeline.
Establezca etiquetas personalizadas
Puede establecer etiquetas personalizadas para todos los tramos de pipeline y trabajo de sus proyectos de GitLab para mejorar la trazabilidad. Para obtener más información, consulte Custom Tags and Measures.
Integre con Datadog Teams
Para mostrar y filtrar los equipos asociados con sus canalizaciones, agregue team:<your-team> como una etiqueta personalizada. El nombre de la etiqueta personalizada debe coincidir exactamente con el identificador de equipo de Datadog Teams.
Correlacione métricas de infraestructura con trabajos
Si utiliza ejecutores de GitLab autohospedados, puede correlacionar los trabajos con la infraestructura que los ejecuta.
La correlación de infraestructura de Datadog es posible utilizando diferentes métodos:
El ejecutor de GitLab debe tener una etiqueta con el formato host:<hostname>. Las etiquetas se pueden agregar al registrar un nuevo ejecutor. Como resultado, este método solo está disponible cuando el ejecutor está ejecutando el trabajo directamente.
Esto excluye a los ejecutores que escalan automáticamente la infraestructura para ejecutar el trabajo (como los ejecutores de Kubernetes, Docker Autoscaler o Instancia), ya que no es posible agregar etiquetas dinámicamente para esos ejecutores.
Para ejecutores existentes:
GitLab >= 15.8: Agregue etiquetas a través de la interfaz de usuario yendo a Settings > CI/CD > Runners y editando el ejecutor correspondiente.
GitLab < 15.8: Agregue etiquetas actualizando el config.toml del ejecutor. O agregue etiquetas a través de la interfaz de usuario yendo a Settings > CI/CD > Runners y editando el ejecutor correspondiente.
Después de estos pasos, CI Visibility agrega el nombre de host a cada trabajo. Para ver las métricas, haga clic en un tramo de trabajo en la vista de traza. En el panel, aparece una nueva pestaña llamada Infrastructure que contiene las métricas del servidor.
CI Visibility admite métricas de infraestructura para ejecutores de “Docker Autoscaler” mediante correlación basada en registros. Para habilitar esto, asegúrese de que los registros de trabajo de GitLab estén indexados para que Datadog pueda vincular los trabajos a los hosts, y que los registros incluyan mensajes en el formato Instance <hostname> connected. Los registros de trabajo de GitLab incluyen las etiquetas datadog.product:cipipeline y source:gitlab, que puede usar en los filtros de Log Indexes. Los usuarios también necesitan acceso de lectura a registros para ver los datos de infraestructura en este escenario. Para obtener más información, consulte la guía de correlación de métricas de infraestructura con trabajos de GitLab.
CI Visibility admite métricas de infraestructura para ejecutores de “Instance” mediante correlación basada en registros. Para habilitar esto, asegúrese de que los registros de trabajo de GitLab estén indexados para que Datadog pueda vincular los trabajos a los hosts, y que los registros incluyan mensajes en el formato Instance <hostname> connected. Los registros de trabajo de GitLab incluyen las etiquetas datadog.product:cipipeline y source:gitlab, que puede usar en los filtros de Log Indexes. Los usuarios también necesitan acceso de lectura a registros para ver la información de infraestructura en este escenario. Para obtener más información, consulte la guía de correlación de métricas de infraestructura con trabajos de GitLab.
CI Visibility admite métricas de infraestructura para el ejecutor de Kubernetes. Para esto, es necesario que el Datadog Agent monitoree la infraestructura de GitLab en Kubernetes. Consulte Instalar el Datadog Agent en Kubernetes para instalar el Datadog Agent en un clúster de Kubernetes.
Debido a limitaciones en el Datadog Agent, es posible que los trabajos más cortos que el intervalo mínimo de recopilación del Agente de Datadog no siempre muestren métricas de correlación de infraestructura. Para ajustar este valor, establezca min_collection_interval en menos de 15 segundos en su archivo de configuración del Datadog Agent.
CI Visibility no admite métricas de infraestructura para otros ejecutores.
Visualizar mensajes de error para fallas de canalización
Para las ejecuciones fallidas de canalizaciones de GitLab, cada error en la pestaña Errors dentro de una ejecución de canalización específica muestra un mensaje asociado con el tipo de error de GitLab.
Análisis de fallas de trabajos de CI
Si la recopilación de registros de trabajos está habilitada, CI Visibility utiliza modelos LLM para analizar los trabajos de CI fallidos basándose en los registros relevantes provenientes de GitLab.
También puede agregar un análisis de falla de trabajo a un comentario de PR. Consulte la guía sobre cómo usar comentarios de PR.
Los mensajes de error son compatibles con las versiones 15.2.0 y superiores de GitLab.
La información de error proporcionada por GitLab se almacena en las etiquetas error.provider_message y error.provider_domain.
La siguiente tabla describe el mensaje y el dominio correlacionado con cada tipo de error. Cualquier tipo de error no listado resulta en un mensaje de error Job failed y un dominio de error unknown.
| Tipo de error | Dominio de error | Mensaje de error |.
|———————————|————–|————————————————————|
| unknown_failure | desconocido | Falló debido a una razón desconocida. |
| config_error | usuario | Falló debido a un error en el archivo de configuración de CI/CD. |
| external_validation_failure | desconocido | Falló debido a la validación de canalización externa. |
| user_not_verified | usuario | La canalización falló debido a que el usuario no está verificado. |
| activity_limit_exceeded | proveedor | Se excedió el límite de actividad de la canalización. |
| size_limit_exceeded | proveedor | Se excedió el límite de tamaño de la canalización. |
| job_activity_limit_exceeded | proveedor | Se excedió el límite de actividad de trabajos de la canalización. |
| deployments_limit_exceeded | proveedor | Se excedió el límite de implementaciones de la canalización. |
| project_deleted | proveedor | El proyecto asociado con esta canalización fue eliminado. |
| api_failure | proveedor | Falla de API. |
| stuck_or_timeout_failure | desconocido | La canalización está bloqueada o agotó el tiempo de espera. |
| runner_system_failure | provider | Falló debido a una falla del sistema del runner. |
| missing_dependency_failure | desconocido | Falló debido a una dependencia faltante. |
| runner_unsupported | provider | Falló debido a un runner no compatible. |
| stale_schedule | provider | Falló debido a un horario obsoleto. |
| job_execution_timeout | desconocido | Falló debido al tiempo de espera del trabajo. |
| archived_failure | proveedor | Falla archivada. |
| unmet_prerequisites | desconocido | Falló debido a un prerrequisito no cumplido. |
| scheduler_failure | provider | Falló debido a un fallo en el horario. |
| data_integrity_failure | provider | Falló debido a problemas de integridad de los datos. |
| forward_deployment_failure | desconocido | Falla de implementación. |
| user_blocked | usuario | Bloqueado por el usuario. |
| ci_quota_exceeded | proveedor | Se excedió la cuota de CI. |
| pipeline_loop_detected | usuario | Se detectó un bucle en la canalización. |
| builds_disabled | usuario | Compilación deshabilitada. |
| deployment_rejected | usuario | Implementación rechazada. |
| protected_environment_failure | proveedor | Falla del entorno. |
| secrets_provider_not_found | usuario | Proveedor de secretos no encontrado. |
| reached_max_descendant_pipelines_depth | usuario | Se alcanzó el máximo de canalizaciones descendientes. |
| ip_restriction_failure | proveedor | Falla por restricción de IP. |
Recopilar registros de trabajo
Las siguientes versiones de GitLab admiten la recopilación de registros de trabajo:
GitLab >= 14.8 (autohospedado) al habilitar la bandera de función datadog_integration_logs_collection
Los registros de trabajo se recopilan en Log Management y se correlacionan automáticamente con la canalización de GitLab en CI Visibility. Los archivos de registro mayores a un GiB se truncan.
Para habilitar la recopilación de registros de trabajo:
Haga clic en la casilla de verificación Enable job logs collection en la integración de GitLab Settings > Integrations > Datadog.
Haga clic en Save changes.
Datadog descarga archivos de registro directamente desde el almacenamiento de objetos de sus registros de GitLab con URL temporales prefirmadas.
Esto significa que para que los servidores de Datadog accedan al almacenamiento, el almacenamiento no debe tener restricciones de red
El punto de conexión, si está configurado, debe resolverse en una URL accesible públicamente.
Haga clic en la casilla de verificación Enable job logs collection en la integración de GitLab en Settings > Integrations > Datadog.
Haga clic en Save changes.
Datadog descarga archivos de registro directamente desde el almacenamiento de objetos de sus registros de GitLab con URL temporales prefirmadas.
Esto significa que para que los servidores de Datadog accedan al almacenamiento, el almacenamiento no debe tener restricciones de red
El punto de conexión, si está configurado, debe resolverse en una URL accesible públicamente.
Habilite el datadog_integration_logs_collectionfeature flag en su GitLab. Esto le permite ver la casilla de verificación Enable job logs collection en la integración de GitLab en Settings > Integrations > Datadog.
Haga clic en Enable job logs collection.
Haga clic en Save changes.
Los registros se facturan por separado de CI Visibility. La retención, exclusión e índices de registros se configuran en Log Management. Los registros de los trabajos de GitLab se pueden identificar mediante las etiquetas datadog.product:cipipeline y source:gitlab.
Para obtener más información sobre el procesamiento de registros de trabajos recopilados de la integración de GitLab, consulte la documentación de procesadores.
Visualizar Pipelines parciales y descendentes
Puede utilizar los siguientes filtros para personalizar su consulta de búsqueda en el CI Visibility explorador.
Nombre de faceta
ID de faceta
Valores posibles
Pipelines descendentes
@ci.pipeline.downstream
true, false
Activado manualmente
@ci.is_manual
true, false
Pipelines parciales
@ci.partial_pipeline
retry, paused, resumed
También puede aplicar estos filtros usando el panel de faceta en el lado izquierdo de la página.
Visualice datos de Pipelines en Datadog
Una vez que la integración se configure correctamente, las páginas Lista de Pipelines de CI y Ejecuciones se completarán con datos después de que los Pipelines finalicen.
La página CI Pipeline List muestra datos solo para la rama predeterminada de cada repositorio. Para obtener más información, consulte Buscar y administrar Pipelines de CI.
Lecturas adicionales
Documentación, enlaces y artículos útiles adicionales:
