Monitores de Error Tracking

Documentación > APM > Error Tracking para servicios de backend > Monitores de Error Tracking

Descripción general

Datadog Error Tracking agrupa automáticamente todos sus errores en problemas en sus aplicaciones web, móviles y de backend. Ver los errores agrupados en problemas le ayuda a priorizar y encontrar los problemas que tienen mayor impacto, lo que facilita minimizar los tiempos de inactividad del servicio y reducir la frustración del usuario.

Con Error Tracking habilitado para su organización, puede crear un seguimiento de Error Tracking para alertar cuando un problema en su aplicación web o móvil, servicio de backend o logs sea nuevo, cuando tenga un alto impacto y cuando comience a presentar una regresión.

Cree un seguimiento de Error Tracking

Para crear un seguimiento de Error Tracking en Datadog, navegue a Monitors > New Monitor > Error Tracking.

Existe un límite predeterminado de 1000 seguimientos de Error Tracking por cuenta. Comuníquese con Soporte para aumentar este límite para su cuenta.

Seleccione la condición de alerta

Existen dos tipos de condiciones de alerta con las que puede configurar su seguimiento de Error Tracking:

Condición de alerta	Descripción
Nuevo problema	Alerte cuando un problema ocurre por primera vez o cuando se produce una regresión. Por ejemplo, alete a su servicio siempre que más de 2 usuarios se vean afectados por un error nuevo.
Alto impacto	Alerte sobre problemas con un alto número de usuarios finales afectados. Por ejemplo, alete a su servicio siempre que más de 500 usuarios se vean afectados por este error.

Defina las condiciones de alerta

Problemas sobre los que alertar

Los seguimientos de problemas nuevos alertan sobre problemas que se encuentran en el estado For Review y cumplen con sus condiciones de alerta. Las regresiones pasan automáticamente al estado Para revisar, por lo que se monitorean de forma predeterminada con los seguimientos de problemas nuevos. Para obtener más información sobre los estados, consulte Estados de los problemas.

Seleccione problemas All, Browser, Mobile o Backend y construya una consulta de búsqueda utilizando la misma lógica que la búsqueda del explorador de Error Tracking para las ocurrencias de error de los problemas.

Los seguimientos de problemas nuevos solo consideran los problemas que se crearon o regresaron después de que se creó o editó por última vez el seguimiento. Estos seguimientos tienen un período de revisión de 24 horas.

Defina el umbral de alerta

Elija una de las siguientes opciones:

Alerte sobre todos los problemas nuevos

El seguimiento se activa cuando se detecta cualquier problema nuevo (el número de errores es mayor que 0 durante el último día).

Defina su métrica de seguimiento

Elija la métrica sobre la cual desea hacer un seguimiento. Existen tres opciones de filtro sugeridas para acceder a las facetas utilizadas con mayor frecuencia:
- Error Occurrences: Se activa cuando el recuento de errores es above.
- Impacted Users: Se activa cuando el número de correos electrónicos de usuarios afectados es above.
- Impacted Sessions: Se activa cuando el número de ID de sesión afectados es above.
Si selecciona problemas All o Backend, solo está disponible la opción Error Occurrences.
También puede especificar una medida personalizada que desee utilizar para hacer un seguimiento. Si selecciona una medida personalizada, el seguimiento alerta cuando el recuento de valores únicos de la faceta es above.
Reciba una notificación por cada problema que coincida con su consulta y agrupe los resultados por cualquier otro atributo que requiera (por ejemplo, reciba una notificación por cada problema que coincida con la consulta y en cada entorno).
Consulte datos durante el último día (de forma predeterminada) o cualquier otra ventana de tiempo en cada evaluación.
Elija un umbral para que el seguimiento se active (de forma predeterminada, 0 se activa en la primera ocurrencia).

Administración programática

Si utiliza Terraform o scripts personalizados mediante nuestras API públicas para administrar sus seguimientos, debe especificar algunas cláusulas en la consulta del seguimiento:

Agregue la fuente a la que desea dirigirse entre el problema All, Browser, Mobile y Backend. Utilice la cláusula .source() con "all", "browser", "mobile" o "backend" justo después de su filtro. Nota: solo puede usar una a la vez.
Asegúrese de usar la cláusula .new() para seguimientos de problemas nuevos.

Ejemplo:

error-tracking("{filter}").source("backend").new().rollup("count").by("issue.id").last("1d") > 0

Problemas sobre los que alertar

Los seguimientos de alto impacto alertan sobre problemas que son For Review o Reviewed y que cumplen con sus condiciones de alerta. Lea más sobre Estados de problemas.

Defina el umbral de alerta

Elija la métrica sobre la cual desea hacer un seguimiento. Existen tres opciones de filtro sugeridas para acceder a las facetas utilizadas con mayor frecuencia:
- Error Occurrences: Se activa cuando el recuento de errores es above.
- Impacted Users: Se activa cuando el número de correos electrónicos de usuarios afectados es above.
- Impacted Sessions: Se activa cuando el número de ID de sesión afectados es above.
Si selecciona problemas All o Backend, solo está disponible la opción Error Occurrences.
También puede especificar una medida personalizada que desee utilizar para hacer un seguimiento. Si selecciona una medida personalizada, el seguimiento alerta cuando el recuento de valores únicos de la faceta es above.
Tenga una notificación para cada problema que coincida con su consulta y agrupe los resultados por cualquier otro atributo que requiera (por ejemplo, tenga una notificación para cada problema que coincida con la consulta, en cada entorno).
Consulte datos durante el último día (de forma predeterminada) o cualquier otra ventana de tiempo en cada evaluación.
Elija un umbral para que el seguimiento se active (de forma predeterminada, 0 se activa en la primera ocurrencia).

Administración programática

Si utiliza Terraform o scripts personalizados mediante nuestras API públicas para administrar sus seguimientos, debe especificar algunas cláusulas en la consulta del seguimiento:

Agregue la fuente a la que desea dirigirse entre el problema All, Browser, Mobile y Backend. Utilice la cláusula .source() con "all", "browser", "mobile" o "backend" justo después de su filtro. Nota: solo puede usar una a la vez.
Asegúrese de usar la cláusula .impact() para seguimientos de alto impacto.

Ejemplo:

error-tracking("{filter}").source("browser").impact().rollup("count").by("issue.id").last("1d") > 0

Notifications

Para mostrar las etiquetas de activación en el título de la notificación, haga clic en Include triggering tags in notification title.

Además de las variables de atributo coincidentes, están disponibles las siguientes variables específicas de Error Tracking para notificaciones de mensajes de alerta:

{{issue.attributes.error.type}}
{{issue.attributes.error.message}}
{{issue.attributes.error.stack}}
{{issue.attributes.error.file}}
{{issue.attributes.error.is_crash}}
{{issue.attributes.error.category}}
{{issue.attributes.error.handling}}

Para obtener más información sobre la sección Configure notifications and automations, consulte Notifications.

Seleccione alerta múltiple para recibir una notificación por problema. Esta es la experiencia prevista para los seguimientos de Error Tracking.

Silenciar seguimientos

Los seguimientos de Error Tracking utilizan Estados de problemas para garantizar que sus alertas se mantengan enfocadas en asuntos de alta prioridad, reduciendo las distracciones de problemas no críticos.

Ignored los problemas son errores que no requieren investigación ni acción adicional. Al marcar los problemas como Ignored, estos se silencian automáticamente de las Notifications del seguimiento.

Solución de problemas

Los seguimientos de Nuevo problema no tienen en cuenta la antigüedad del problema

issue.age y issue.regression.age no se agregan de forma predeterminada porque pueden causar alertas perdidas. Por ejemplo, si un problema aparece por primera vez en env:staging y luego, una semana después, aparece en env:prod por primera vez, el problema se consideraría de una semana de antigüedad y no activaría una alerta en env:prod por primera vez.

Como resultado, Datadog no recomienda usar issue.age y issue.regression.age. Sin embargo, si el comportamiento del monitor basado en el estado no es adecuado para usted, estos filtros aún pueden usarse si se especifican manualmente.

Nota: Si planea usar issue.age y issue.regression.age en su monitor, esta clave de filtro no es consistente entre productos. Por ejemplo, podría ser @issue.age o issue.age.

Los monitores de problemas nuevos están generando demasiado ruido

Los monitores de problemas nuevos activan alertas sobre problemas marcados como For Review que cumplen con sus criterios de alerta. Si los problemas no se clasifican adecuadamente (marcados como Reviewed, Ignored o Resolved), un monitor de problemas nuevos puede activarse más de una vez para el mismo problema si este fluctúa entre los estados OK y ALERT.

Si sus monitores están generando demasiado ruido, considere los siguientes ajustes:

Clasifique sus alertas: Establezca los problemas como Reviewed, Ignored o Resolved cuando sea apropiado
Amplíe la ventana de tiempo de evaluación: La ventana de evaluación predeterminada es de 1 día. Si los errores ocurren con poca frecuencia (por ejemplo, cada dos días), el monitor puede cambiar entre los estados OK y ALERT. Ampliar la ventana ayuda a evitar que se vuelvan a activar y mantiene al monitor en el estado ALERT.
Aumente el umbral de alerta: El umbral predeterminado está establecido en 0, lo que significa que las alertas se activan en la primera ocurrencia de un problema nuevo. Para reducir el ruido de errores únicos o esporádicos, aumente el umbral para alertar solo después de múltiples ocurrencias de un error.