Definir la consulta de búsqueda

1. Crea una consulta de búsqueda utilizando la misma lógica de una búsqueda del explorador de pipelines CI.
2. Selecciona el nivel de eventos de pipelines CI:
   • Pipeline: evalúa la ejecución de un pipeline completo, normalmente compuesto por una o varias tareas.
   • Stage (Etapa): evalúa la ejecución de un grupo de una o varias tareas en los proveedores CI compatibles
   • Job (Tarea): evalúa la ejecución de un grupo de comandos.
   • Command (Comando): evalúa manualmente eventos de comandos personalizados instrumentados que son comandos individuales que se ejecutan en una tarea.
   • All (Todo): evalúa todos los tipos de eventos.
3. Elige monitorizar un recuento de eventos de pipelines CI, una faceta o una medida:
   • CI Pipeline event count (Recuento de eventos de pipelines CI): utiliza la barra de búsqueda (opcional) y no selecciones una faceta o una medida. Datadog evalúa el número de eventos de pipelines CI, a lo largo de un periodo de tiempo seleccionado, y luego lo compara con las condiciones del umbral.
   • Dimensión (Dimensión): selecciona la dimensión (faceta cualitativa) para emitir alertas sobre el Unique value count de la faceta.
   • *Measure (Medida): selecciona la medida (faceta cuantitativa) para emitir alertas sobre el valor numérico de la medida del pipeline CI (similar a un monitor de métricas). Selecciona la agregación (min, avg, sum, median, pc75, pc90, pc95, pc98, pc99 o max).
4. Agrupa los eventos de pipelines CI por múltiples dimensiones (opcional):
   • Todos los eventos de pipelines CI que coinciden con la consulta se agregan a grupos basados en el valor de hasta cuatro facetas.
5. Configura la estrategia de agrupación de alertas (opcional):
   • Si la consulta tiene un group by, las alertas múltiples aplican la alerta a cada origen, en función de tus parámetros de grupo. Se genera un evento de alerta para cada grupo que cumple las condiciones establecidas. Por ejemplo, podrías agrupar una consulta por @ci.pipeline.name, para recibir una alerta separada para cada nombre de pipeline CI cuando el número de errores es elevado.

Mediante fórmulas y funciones

Se pueden crear monitores de pipelines CI utilizando fórmulas y funciones. Esto puede utilizarse, por ejemplo, para crear monitores de la tasa de ocurrencia de un evento, como por ejemplo la tasa de fallo de un pipeline (tasa de error).

El siguiente ejemplo es un monitor de tasa de error de pipeline que utiliza una fórmula que calcula la proporción del “número de eventos de pipeline fallidos” (ci.status=error) sobre el “número de eventos de pipelines totales” (sin filtro), agrupados por ci.pipeline.name (para ser alertados una vez por cada pipeline). Para obtener más información, consulta Información general en la sección Funciones.

Definir la consulta de búsqueda

1. Tipos frecuentes de monitores (opcional): Proporciona una plantilla de consulta para cada uno de los tipos frecuentes de monitores, Nuevos tests defectuosos, Fallos en los tests y Rendimiento de los tests, que luego puedes personalizar. Para obtener más información sobre esta característica, consulta Realizar un seguimiento de nuevos tests defectuosos.
2. Crea una consulta de búsqueda utilizando la misma lógica de una búsqueda del explorador de tests CI. Por ejemplo, puedes buscar tests fallidos para la rama main del test de servicio myapp utilizando la siguiente consulta: @test.status:fail @git.branch:main @test.service:myapp.
3. Elige monitorizar un recuento de eventos de tests CI, una faceta o una medida:
   • CI Test event count (Recuento de eventos de tests CI): utiliza la barra de búsqueda (opcional) y no selecciones una faceta o una medida. Datadog evalúa el número de eventos de tests de pipelines CI, a lo largo de un periodo de tiempo seleccionado, y luego lo compara con las condiciones del umbral.
   • Dimensión (Dimensión): selecciona la dimensión (faceta cualitativa) para emitir alertas sobre el Unique value count de la faceta.
   • *Measure (Medida): selecciona la medida (faceta cuantitativa) para emitir alertas sobre el valor numérico de la faceta del pipeline CI (similar a un monitor de métricas). Selecciona la agregación (min, avg, sum, median, pc75, pc90, pc95, pc98, pc99 o max).
4. Agrupa los eventos de tests CI por múltiples dimensiones (opcional):
   • Todos los eventos de tests CI que coinciden con la consulta se agregan a grupos basados en el valor de hasta cuatro facetas.
5. Configura la estrategia de agrupación de alertas (opcional):
   • Si la consulta tiene un group by, se envía una alerta para cada origen en función de los parámetros del grupo. Se genera un evento de alerta para cada grupo que cumple las condiciones establecidas. Por ejemplo, puedes agrupar una consulta por @test.full_name para recibir una alerta distinta para cada nombre completo de test CI, cuando el número de errores es elevado. El nombre completo del test es una combinación del grupo de tests y el nombre del test, por ejemplo: MySuite.myTest. En Swift, el nombre completo del test es una combinación del grupo de tests, del conjunto de tests y del nombre del test, por ejemplo: MyBundle.MySuite.myTest.

Ejecución de tests con diferentes parámetros o configuraciones

Utiliza @test.fingerprint en el monitor group by cuando tengas tests con el mismo nombre completo de test, pero diferentes parámetros o configuraciones de test. De esta forma, las alertas se activan para ejecuciones de tests con parámetros o configuraciones de test específicos. El uso de @test.fingerprint proporciona el mismo nivel de especificidad que la sección Estados de tests fallado y defectuoso, en la página Información general sobre las confirmaciones.

Por ejemplo, si un test con el mismo nombre completo falla en Chrome, pero se aprueba en Firefox, el uso de la huella digital sólo activa la alerta en la ejecución del test de Chrome.

El uso de @test.full_name en este caso activa la alerta, aunque el test haya sido aprobado en Firefox.

Fórmulas y funciones

Puedes crear monitores de tests CI utilizando fórmulas y funciones. Esto puede utilizarse, por ejemplo, para crear monitores de la tasa de ocurrencia de un evento, como por ejemplo la tasa de fallo de un test (tasa de error).

El siguiente ejemplo es un monitor de la tasa de errores de tests que utiliza una fórmula para calcular la proporción del “número de eventos de test fallidos” (@test.status:fail) sobre el “número de eventos de test totales” (sin filtro), agrupados por @test.full_name (para ser alertados una vez por test). Para obtener más información, consulta Información general en la sección Funciones.

Uso de CODEOWNERS para las notificaciones

Puedes enviar la notificación a diferentes equipos utilizando la información de CODEOWNERS disponible en el evento de test.

El siguiente ejemplo configura la notificación con la siguiente lógica:

• Si el propietario del código de test es MyOrg/my-team, envía la notificación al canal Slack my-team-channel.
• Si el propietario del código de test es MyOrg/my-other-team, envía la notificación al canal Slack my-other-team-channel.

{{#is_match "citest.attributes.test.codeowners" "MyOrg/my-team"}}
  @slack-my-team-channel
{{/is_match}}
{{#is_match "citest.attributes.test.codeowners" "MyOrg/my-other-team"}}
  @slack-my-other-team-channel
{{/is_match}}

En la sección Notification message de tu monitor, añade un texto similar al fragmento de código anterior para configurar las notificaciones del monitor. Puedes añadir tantas cláusulas is_match como necesites. Para obtener más información sobre las variables de notificación, consulta las variables condicionales de monitores.