Pruebe los filtros de retención de RUM en el Centro de aprendizaje

Aprenda a utilizar los filtros de retención de RUM para controlar qué datos de sesión se almacenan y optimizar su presupuesto de observabilidad.

INSCRÍBASE AHORA

Descripción general

RUM without Limits le permite capturar todos los datos de la sesión mientras solo conserva las sesiones que son valiosas para su organización. Esta herramienta mejora la gestión de sus datos mediante la separación de la ingesta de datos de sesión de la indexación.

Características clave

• Filtros de retención dinámicos: Ajuste qué datos conservar sin cambiar ningún código
• Métricas integrales: Las métricas reflejan el 100% de las sesiones, lo que garantiza una visibilidad total
• Retención de sesiones dirigida: Priorice los datos de sesión cruciales para la optimización de costos

Esta guía proporciona estrategias para gestionar sus volúmenes de sesiones de RUM de manera efectiva dentro de su presupuesto de observabilidad.

Secuenciación de filtros de retención

Los filtros de retención de RUM le permiten elegir qué sesiones de usuario conservar. Así es como funcionan:

Cada sesión contiene múltiples eventos (como visualizaciones que representan la navegación, acciones del usuario, errores, recursos que representan solicitudes de red) y cada uno de ellos está lleno de atributos (como duración, contexto, etc.). El sistema evalúa cada evento individualmente con respecto a sus filtros de retención:

1. Sesión conservada: Si al menos un evento en una sesión coincide con un filtro de retención Y se selecciona para su retención, entonces se conserva toda la sesión.
2. Sesión descartada: Si ningún evento coincide con ningún filtro de retención para cuando termina la sesión, se elimina toda la sesión.

Cómo funcionan los diferentes tipos de eventos

Algunos eventos (como errores y acciones) no pueden cambiarse después de que ocurren. Datadog llama a estos eventos inmutables. Otros (como sesiones y visualizaciones) pueden cambiar a medida que el usuario continúa usando su aplicación. Datadog llama a estos eventos mutables.

• Los eventos inmutables (Acción, Error, Recurso, Tarea larga y Vital eventos) solo se verifican una vez frente a sus filtros y no se pueden cambiar una vez creados:

  1. El evento se detiene en el primer filtro que coincide con sus etiquetas y atributos.
  2. Se genera un número aleatorio y se compara con la tasa de muestreo del filtro para decidir si el evento debe conservarse o descartarse.
  3. Si el evento se conserva, toda la sesión (incluidos todos los eventos anteriores) se preserva, y los eventos futuros de la misma sesión omiten automáticamente los filtros de retención.
  4. Si el evento se descarta, no es evaluado por otros filtros, pero otros eventos de la misma sesión continúan procesándose de forma independiente.

• Los eventos mutables (Sesión, Visualización) se vuelven a verificar cada vez que se actualizan:

  • Los eventos de Visualización y Sesión son diferentes de los eventos inmutables porque pueden cambiar con el tiempo. Estos eventos reciben actualizaciones cada vez que ocurren nuevos eventos dentro de ellos.
  • A diferencia de los eventos inmutables que se evalúan solo una vez, los eventos de Visualización y Sesión se vuelven a evaluar frente a los filtros de retención cada vez que reciben una actualización. Esto continúa hasta que coinciden con un filtro por primera vez.

Mejores prácticas

Orden de los filtros de retención

El orden de sus filtros de retención es importante. Datadog recomienda colocar los filtros más específicos con las tasas de muestreo más altas en la parte superior de la lista, y sus filtros más generales con las tasas de muestreo más bajas en la parte inferior.

Por ejemplo, imagine que tiene un evento de bloqueo (un evento de Error con el atributo @error.is_crash:true). Este evento podría coincidir con más de un filtro, pero solo se evalúa frente al primer filtro coincidente en su lista.

• En el ejemplo a continuación, el filtro de retención "Crashes" se coloca por encima del filtro más general "All errors". Esto significa que todas las sesiones de bloqueo se conservan, porque coinciden primero con el filtro "Crashes".

  ✅ Recomendado

• En el siguiente ejemplo, el filtro más general "Todos los errores" aparece antes que el filtro "Fallos". Debido a esto, las sesiones con fallos solo se conservan si son seleccionadas por el filtro "Todos los errores" (por ejemplo, si tiene una tasa de muestreo del 50%). Si no son seleccionadas, no son evaluadas por el filtro "Fallos" y esas sesiones se pierden.

  ❌ No recomendado

Filtros de respaldo para capturar las sesiones restantes

Un filtro de respaldo al final de su lista captura un pequeño porcentaje de sesiones que no coincidieron con otros filtros. Siempre debe incluir @session.is_active:false en su consulta de filtro de respaldo.

• Con @session.is_active:false: El filtro de respaldo solo evalúa las sesiones completadas, permitiendo que sus otros filtros capturen las sesiones primero

  ✅ Recomendado

• Sin @session.is_active:false: El filtro de respaldo captura todas las sesiones inmediatamente, lo que podría anular sus filtros más específicos

  ❌ No recomendado

Exclusión de sesiones

Para evitar que un solo filtro coincida con un subconjunto de eventos, agregue la exclusión dentro de la consulta de ese filtro. Consulte Exclusión de sesiones mediante filtros de retención.

Para excluir eventos en todos sus filtros de retención personalizados a la vez, sin repetir la misma exclusión en cada consulta, utilice filtros de exclusión en su lugar.

Filtros de retención sugeridos y casos de uso

A continuación, describimos el conjunto de filtros predeterminados, los filtros sugeridos y sus casos de uso típicos.

Lecturas adicionales

Más enlaces, artículos y documentación útiles:

Filtros de retenciónDOCUMENTACIÓN RUM without LimitsDOCUMENTACIÓN Analice el rendimiento con métricasDOCUMENTACIÓN Unifique y correlacione datos de frontend y backend con filtros de retenciónBLOG Laboratorio interactivo: Filtros de retención de RUMCENTRO DE APRENDIZAJE