Estrategias de muestreo de eventos para Telemetry estructurado

El muestreo mantiene un subconjunto de eventos elegibles. Puede reducir el volumen de entrega y almacenamiento, pero también cambia lo que el conjunto de datos puede responder. El muestreo debe seguir un costo medido o un problema de escala, no reemplazar la revisión del esquema, la eliminación de duplicados o la política de retención.

Antes del muestreo, elimine los campos no utilizados, normalice los valores accidentales de alta cardinalidad, detenga los productores duplicados y mida el recuento de eventos y los bytes de carga útil con el receta de volumen de telemetría.

Preservar resultados raros e importantes

Mantenga las fallas de terminales, los eventos relevantes para la seguridad, los registros de facturación, los hitos de incidentes y los resultados poco comunes del flujo de trabajo con total fidelidad, a menos que un control aprobado indique lo contrario. Una muestra uniforme del uno por ciento puede borrar exactamente los eventos que un operador necesita durante un incidente.

Una política inicial común es:

• conservar todos los fallos, tiempos de espera, reintentos agotados y eventos explícitos de impacto en el cliente;
• retener todos los eventos de una pequeña lista de diagnóstico permitido durante una ventana de incidente limitada;
• muestrear sólo resultados exitosos de gran volumen;
• Mantenga los hitos comerciales de bajo volumen sin muestrear.

Muestra determinista

El muestreo determinista hace que las decisiones relacionadas sean reproducibles. Haga un hash de un identificador estable como request_id, trace_id o account_id con una política versionada y luego compárelo con la tasa objetivo. El mismo identificador debería tomar la misma decisión mientras la versión de la política permanezca sin cambios.

Registro:

• sampled o un resultado de cobro equivalente;
• sample_rate, como 0.1;
• sampling_policy, como api_success_v2;
• la dimensión estable utilizada para la decisión.

No almacene la entrada hash sin procesar cuando sea sensible. No genere una nueva decisión aleatoria de forma independiente para cada paso de un flujo de trabajo si el análisis espera que los pasos sigan siendo unibles.

Hacer explícito el análisis ponderado

Si los eventos exitosos se muestrean al diez por ciento, cada éxito retenido representa aproximadamente diez éxitos elegibles según los supuestos de la política. Almacene la probabilidad de inclusión y utilice una ponderación explícita al estimar los recuentos.

SELECT
  route_template,
  SUM(1.0 / sample_rate) AS estimated_requests
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
ORDER BY estimated_requests DESC;

Los recuentos ponderados no reparan automáticamente todas las estadísticas. Los percentiles de cola, los recuentos de usuarios distintos, los embudos, la retención de cohortes y los segmentos de clientes pequeños pueden volverse inestables o sesgados. Mantenga datos sin muestrear para análisis cuyos denominadores o relaciones de secuencia deben ser exactos.

Versionar y evaluar la política

Cambiar una tasa cambia el conjunto de datos. Registre una versión de la política y el tiempo efectivo para que las consultas puedan evitar comparar períodos incompatibles como si la recopilación fuera constante.

Evaluar:

1. Recuento de eventos y bytes retenidos.
2. Cobertura de fracasos y resultados poco comunes.
3. Error de métrica estimado frente a un dispositivo no muestreado o una reserva temporal.
4. Cobertura de segmentos para rutas, planes y regiones de bajo volumen.
5. Las preguntas que el conjunto de datos muestreado ya no puede responder.

No infiera una mejora del producto a partir de una caída de volumen que se produjo como resultado de un cambio en la política de cobranza.

Prefiere cambios de retención cuando el problema es el historial

El muestreo reduce la cobertura futura de las hileras. La retención elimina los datos más antiguos después de un período definido por la política. Si los detalles del incidente actual deben permanecer completos pero el historial a largo plazo es costoso, una política de retención más corta puede ser una mejor opción. Revise retención y eliminación de datos por separado del muestreo.

Continúe con campos de alta cardinalidad, gestión de costes de telemetría y recetas SQL con calidad de datos.