Contrato de evento
Campos que espera la consulta
| Campo | Tipo | Por que existe |
|---|---|---|
| timestamp_utc | Timestamp | Hora del evento del ciclo de vida del trabajo. |
| job_id | Utf8 | Identificador de trabajo lógico estable. |
| queue_name | Utf8 | Cola propietaria del trabajo. |
| event_name | Utf8 | dead_letter_created o dead_letter_resolved. |
| error_type | Utf8 | Fallo terminal categorizado. |
Copiar la consulta
SELECT
date_trunc('day', timestamp_utc) AS day,
queue_name,
SUM(CASE
WHEN event_name = 'dead_letter_created' THEN 1 ELSE 0
END) AS created_jobs,
SUM(CASE
WHEN event_name = 'dead_letter_resolved' THEN 1 ELSE 0
END) AS resolved_jobs,
SUM(CASE
WHEN event_name = 'dead_letter_created' THEN 1
WHEN event_name = 'dead_letter_resolved' THEN -1
ELSE 0
END) AS net_queue_change
FROM job_events
WHERE timestamp_utc >= now() - INTERVAL '30 days'
AND event_name IN ('dead_letter_created', 'dead_letter_resolved')
GROUP BY date_trunc('day', timestamp_utc), queue_name
ORDER BY day, queue_name;Esta consulta de solo lectura se planifica y ejecuta en una tabla escrita vacía con Apache DataFusion 45.2.0. El resultado de la muestra determinista es sintético y se revisa por separado; valide tipos de campos, umbrales y definiciones comerciales con sus propios datos. Lea la metodología de prueba.
Resultado de la consulta
Empleos fallidos creados y resueltos
Facturación acumuló 22 empleos fallidos adicionales el 26 de julio mientras que las importaciones redujeron su cola.
| day | queue_name | created_jobs | resolved_jobs | net_queue_change |
|---|---|---|---|---|
| 2026-07-25 | billing | 18 | 16 | 2 |
| 2026-07-26 | billing | 31 | 9 | 22 |
| 2026-07-27 | imports | 12 | 14 | -2 |
Salida de ejemplo sintético. Ejecute la consulta con su propio esquema de eventos y umbrales antes de utilizarla para decisiones operativas.
Reproducir el ejemplo
Descargar el accesorio público
El paquete JSON incluye el contrato de evento escrito, illustrative filas de entrada, SQL exacto, resultado esperado, notas de revisión y versión del motor. El CSV contiene el resultado mostrado.
Cómo funciona el SQL
- 1Los eventos creados y resueltos permanecen separados, por lo que el mismo cambio neto no puede ocultar cargas de trabajo operativas muy diferentes.
- 2El cambio neto firmado expone días en los que se acumuló trabajo no resuelto.
- 3La agrupación por cola mantiene claras las rutas de propiedad y escalamiento.
Casos extremos para decidir
- Un reintento no es una resolución hasta que el trabajo lógico alcance un éxito terminal documentado o un resultado de descarte.
- Los eventos del ciclo de vida reabastecidos pueden cambiar el movimiento neto histórico.
- Realice un seguimiento del stock en cola actual por separado o calcule una suma acumulada a partir de un saldo inicial conocido.
Panel recomendado
- Barras apiladas: created_jobs y resolved_jobs por cola
- Tendencia: stock acumulado de mensajes fallidos
- Tabla: trabajos más antiguos sin resolver por error_type
Guía de alerta
Alerta cuando net_queue_change sigue siendo positivo para depósitos consecutivos o el trabajo sin resolver más antiguo infringe su objetivo de respuesta.
Leer configuración de alertaPon la receta a trabajar
Instrumentación y guías relacionadas.
Continuar el análisis
Medir el reintento del trabajo en segundo plano y la tasa de fallas
Encuentre trabajos no confiables comparando ejecuciones exitosas, reintentos, fallas y duración de cola.
Receta abiertaEncuentre trabajos en segundo plano estancados con SQL
Únase a los eventos de inicio y finalización del trabajo para identificar el trabajo que excedió su ventana de finalización esperada.
Receta abiertaMedir el tiempo de espera de la cola por trabajo
Separe el tiempo de espera en una cola de la duración de la ejecución y compare el retraso de p50 y p95 por nombre de trabajo.
Receta abiertaEjecútelo en eventos reales.
Crea una tabla, adapta los campos y guarda el resultado.
Comience gratis, envíe eventos estructurados y utilice el resultado de la consulta como un gráfico, un widget de panel compartido o una entrada de alerta.