# 📊 SLOs — Service Level Objectives ## 🤔 ¿Qué hago? ¿Cómo lo hago? ¿Y para qué lo hago? **¿Qué hago?** Defino objetivos de confiabilidad medibles para klaude-proxy usando error budgets de 30 días. **¿Cómo lo hago?** Cada SLO se mide via métricas Prometheus (`/metrics`) con ventana rolling de 30 días. El error budget determina si podemos desplegar con riesgo. **¿Para qué lo hago?** Sin SLOs no hay decisiones objetivas sobre confiabilidad. Con SLOs, el oncall sabe cuándo puede experimentar (error budget positivo) vs. cuándo debe frenar cambios (error budget quemado). --- ## 📋 SLOs de klaude-proxy ### SLO-1: Disponibilidad (Availability) **Definición:** % de requests que retornan status < 500 en una ventana rolling 30 días. **Métrica Prometheus:** `requests_total{status="200,201,206,3xx,4xx"} / requests_total{status="*"}` **Target:** 99.5% (error budget = 3.6 horas/mes) **Impacto:** Si cae por debajo, se activa: - Código amarillo: revisar logs de error, escalado a oncall - Código rojo: freeze de despliegues no-críticos, solo hotfixes **Cálculo de error budget:** - 99.5% target = 0.5% error = 432 minutos permitidos / mes - Si acumulamos 432+ minutos de downtime, el SLO se rompe --- ### SLO-2: Latencia p99 (Latency) **Definición:** El percentil 99 de latencia end-to-end (proxy → provider + pseudonymizer + pseudonym restore) es < 2s. **Métrica Prometheus:** `histogram_quantile(0.99, request_duration_seconds)` **Target:** < 2s p99 (error budget = 7.2 minutos de violaciones/mes en ventana rolling) **Impacto:** Si latencia p99 > 2s consistently: - Investigar: ¿Qdrant saturado? ¿Anthropic lento? ¿Red del cliente? - Acción: Escalar o optimizar path de latencia crítica **Nota:** Este SLO se puede hacer progresivamente más estricto (1.5s, 1s) a medida que se optimiza. --- ### SLO-3: Cache Hit Rate (interno, no es SLI de usuario) **Definición:** % de requests que reciben respuesta cacheada (no requieren forward a Anthropic). **Métrica Prometheus:** `cache_hits_total / (cache_hits_total + cache_misses_total)` **Target:** > 70% (error budget = 9 días/mes de cache deshabilitado sin romper el SLO) **Impacto:** Indicador de salud del sistema de cache. Si cae: - < 50%: Cache probablemente está corrompido o deshabilitado - < 70% pero > 50%: Investigar patrones de queries que no cachean **Relación:** Afecta a SLO-2 (latencia) — si cache no funciona, latencia se dispara. --- ## 🔄 Error Budget en acción ### Ejemplo: Julio 2026 - Disponibilidad meta: 99.5% de 44,640 minutos = 223 minutos error budget - Uso real: 180 minutos de downtime (4 incidents de 45 min cada uno) - Error budget restante: 43 minutos - **Decisión:** Freeze de despliegues no-críticos en últimos días de mes. Solo hotfixes permitidas. ### Ejemplo: Si latencia p99 viola SLO-2 - Detectado: Latencia p99 = 2.5s durante 3 horas - Impacto en SLO-2: 180 minutos de violación = quema todo el error budget - **Decisión:** Revert del último cambio, investigar causa raíz, tomar SLI post-mortem --- ## 📊 Dashboard recomendado (Grafana) ```yaml Paneles: 1. Availability — requests_total por status (gauge: % con status < 500 vs. 99.5% target) 2. Latency p99 — histogram_quantile(0.99, request_duration_seconds) vs. 2s target 3. Cache Hit Rate — ratio de cache_hits / total vs. 70% target 4. Error Budget Burn Rate — derivada 30d del error presupuesto vs. 30 días disponibles 5. Request Volume — rate(requests_total[5m]) por provider 6. Qdrant Saturation — qdrant_connections_active / max_connections ``` --- ## 🚀 Evoluación de SLOs ### Fase 1 (Ahora): Objetivos base - Availability 99.5% (3.6h/mes error budget) - Latency p99 < 2s - Cache > 70% ### Fase 2 (4-8 semanas): Tightening - Availability 99.8% (43 min/mes) — requiere infra HA real - Latency p99 < 1.5s — optimizaciones de Qdrant query - Cache > 80% — mejor estrategia de segmentación ### Fase 3 (3 meses+): Elite - Availability 99.95% (21.6 min/mes) — multi-zona, failover automático - Latency p50 < 500ms, p99 < 1s — caching inteligente, pre-warming - Cache > 85% --- ## 📚 Referencias - [Google SRE Book — SLOs](https://sre.google/sre-book/service-level-objectives/) - [Prometheus Alerting for SLOs](https://prometheus.io/docs/alerting/latest/overview/) - [DORA Metrics — Reliability](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-devops-performance)