DORA y SLOs sin Prometheus: métricas de entrega sobre Cloudflare Workers
El enfoque guarda la telemetría de cada petición en una tabla de D1, la agrega con un cron worker y calcula el error budget con SQL plano. Sin Prometheus ni proveedor de observabilidad.
Se puede montar un sistema de métricas DORA y objetivos de nivel de servicio (SLO) sin Prometheus, sin una plataforma de métricas como servicio y sin un stack de observabilidad dedicado. La propuesta se apoya en las dos piezas que ya vienen dentro de Cloudflare Workers: un entorno de ejecución y un almacén duradero. Cada petición añade una fila a una tabla de D1 con el método, la ruta, el código de estado, la latencia y la marca temporal, y con eso ya hay materia prima para calcular disponibilidad y percentiles.
El planteamiento recuerda a las métricas caseras de antes de los vendors: guardas las filas y agregas con consultas. La diferencia es que aquí el cron se ejecuta en la propia plataforma.
El error budget, en una consulta
La consulta de referencia es un SELECT sobre la tabla api_usage que se queda con los últimos 30 días, cuenta las peticiones totales, suma las respuestas con status 500 o superior y divide para sacar la tasa de error. El SLO de partida es 99,9% de disponibilidad, que deja unos 43 minutos de caída tolerada al mes.
Con ese presupuesto, el worker clasifica el consumo como fast, slow u ok. El fast burn gasta el margen a múltiplos de la tasa prevista y dispara el canal de aviso inmediato. El slow burn es el que se cuela sin ruido y abre una revisión. El estado ok no requiere nada. Los percentiles p95 y p99 de latencia viajan en el mismo rollup, así que no hace falta una segunda tubería para vigilar el rendimiento.
El cron corre con los cron triggers de Cloudflare, de modo que el recorrido completo queda en filas de api_usage, rollup por SQL y página de estado. Sin infraestructura externa y sin dependencias de terceros, según el autor.
Qué queda por ver
El autor sostiene que el stack completo se reproduce en un día y que después se puede dar de baja al proveedor de observabilidad. Son afirmaciones suyas: no hay demo pública ni datos de comportamiento con volúmenes altos, y el coste de almacenar una fila por petición depende del tráfico. Que el almacenamiento salga barato es una estimación, no una cifra medida.
Como punto de entrada propone tres SLO: disponibilidad al 99,9%, latencia p95 y latencia p99. Lo demás, dice, es refinamiento. Para un equipo pequeño que ya tenga el tráfico en Workers, la parte interesante no es ahorrarse la licencia, sino que el cálculo del error budget vive junto al código que instrumenta, sin exportadores ni agentes que mantener.
