SLI para colas y trabajos por lotes: antigüedad del mensaje más antiguo, frescura, cobertura y último éxito

Objetivo

Definir indicadores de nivel de servicio para el trabajo asíncrono, de modo que «la cola está bien» y «el trabajo nocturno se ejecutó» pasen a ser afirmaciones medidas con un umbral.

Requisitos previos

Una lista de las colas y los trabajos programados, la expectativa que las personas usuarias tienen de cada uno (cuán desactualizado puede estar el resultado, para cuándo debe terminar la ejecución), y un sistema de métricas que almacene gauges y proporciones. Los tipos de componente del SRE workbook (orientado a peticiones, canalización, almacenamiento) son el vocabulario; sus SLI de canalización son la frescura, la corrección y la cobertura.

Pasos

1. Clasificar cada componente. Una cola consumida y un trabajo programado son, en el sentido del workbook, canalizaciones (pipelines): los registros entran y los resultados salen más tarde.
2. Para una cola, escribir primero el indicador orientado a la persona usuaria: la proporción de elementos procesados dentro de N segundos desde su encolado (frescura). El indicador sustitutivo práctico es la antigüedad del elemento sin procesar más viejo; las colas alojadas lo exponen (Amazon SQS reporta ApproximateAgeOfOldestMessage en segundos). El tamaño del backlog es un indicador de causa, útil para la capacidad, no el SLI en sí.
3. Para un trabajo por lotes, exportar como gauge la marca de tiempo de la última finalización exitosa; la guía de instrumentación de Prometheus la llama la métrica clave de un trabajo por lotes y recomienda enviarla mediante push, junto con las duraciones de cada etapa y los registros procesados, porque un trabajo que no se ejecuta de forma continua es difícil de scrapear.
4. Añadir cobertura: para el procesamiento por lotes, la proporción de ejecuciones que procesaron al menos la cantidad esperada de datos; para streaming, la proporción de registros entrantes procesados dentro de la ventana. Una ejecución que termina al instante porque su entrada estaba vacía es un fallo de cobertura, no un éxito.
5. Añadir corrección donde exista un verificador: la proporción de registros de entrada cuyo resultado es correcto, medida sobre una muestra frente a un cálculo de referencia.
6. Convertir cada indicador en una proporción sobre una ventana (eventos buenos divididos entre eventos totales), fijar un objetivo, y redactar la alerta como «el tiempo transcurrido desde el último éxito supera el doble del período programado» o «el elemento más antiguo lleva más del umbral de frescura durante M evaluaciones consecutivas».
7. Registrar el indicador, la implementación, el objetivo y la ventana en el documento de SLO.

Resultado esperado

Cada cola y cada trabajo cuentan con un indicador de frescura o de último éxito con un umbral, una comprobación de cobertura que detecta las ejecuciones vacías, y una alerta que se dispara tanto ante datos ausentes como ante datos incorrectos.

Límites y base de verificación

Las métricas de antigüedad de las colas alojadas están documentadas como aproximadas; la guía de SQS señala que, en una cola estándar, un mensaje recibido tres o más veces sin borrarse pasa al final de la cola y sale de la métrica de antigüedad, de modo que un mensaje envenenado no aparece como antigüedad creciente. Un trabajo que nunca arranca no emite nada, así que las alertas deben tratar una serie ausente como un fallo. La corrección necesita una referencia independiente y normalmente se muestrea.

Alertas basadas en plazo para trabajos programados

La regla del «doble del período programado» sirve para trabajos cuyo único requisito es la regularidad. Un trabajo con un plazo para quien lo consume (un informe que debe estar listo a las 06:00 a partir de una ejecución de las 03:00) necesita en cambio una alerta derivada del indicador de frescura: dispararse cuando el plazo ya pasó y el último éxito es anterior al inicio programado, por ejemplo hour() >= 6 and time() - job_last_success_timestamp_seconds > 3 * 3600, evaluada en las horas posteriores a la ejecución y expresada en la zona horaria que usa la programación. Conviene anotar el plazo junto a la programación en el documento de SLO, mantener la regla basada en el período como alternativa más gruesa para los trabajos sin un consumidor declarado, y hacer que ambas reglas traten una serie ausente como un fallo con absent().