Viernes a las 14 horas, el seguimiento está en verde. CPU al 35%, memoria cómoda, disco lejos del techo. Sin embargo, el soporte recibe capturas de pantalla: el pago tarda ocho segundos, a veces más. El equipo abre Grafana, se desplaza entre doce paneles importados de forma predeterminada (node_exporter, nginx, algunos contadores de aplicaciones) y no encuentra nada que sube en el momento de las quejas.
Esto no es un fracaso de Prometeo. Esto es un error en la elección de señales. Estás midiendo el estado de la máquina, no la ruta que toma un comando cuando se ralentiza.
Lo que Prometheus hace bien y lo que no hará por ti
Prometheus almacena series temporales y las consulta en PromQL. Es excelente para responder preguntas como "¿se ha duplicado /api/checkout p95 desde la implementación de las 11 a. m.?" » o "¿El grupo de conexiones de PostgreSQL está constantemente lleno desde ayer?" ".
No adivina qué métricas te conciernen. Antes de instalar un exportador más, haga una pregunta simple: Si el sitio está lento mañana, ¿qué curva debe subir para que el equipo sepa dónde excavar? Todo lo demás es ruido tranquilizador.
Una métrica que no puede responder “más lento que ayer, ¿en qué ruta?” » sólo se utiliza para decorar un salpicadero.
RED, USO y métricas de negocio: tres grillas, un orden
A menudo aparecen tres fotogramas. No son mutuamente excluyentes: se acumulan.
| Marco | Pregunta | Ejemplos útiles |
|---|---|---|
| ROJO | ¿El servicio responde lo suficientemente rápido y sin errores? | http_requests_total, ratio 5xx, histograma de duración por ruta |
| USO | ¿Está saturado el recurso subyacente? | CPU en espera E/S, disco, conexiones de base de datos inactivas = 0 |
| Profesión | ¿El usuario está logrando su objetivo? | checkout_started vs checkout_completed, carrito abandonado |
Para un sitio o API dinámico, comience con RED en rutas críticas, no con todo el catálogo. Un histograma de latencia en /api/cart y /api/paid es mejor que cien contadores en puntos finales de administración raramente llamados.
El método USE se vuelve esencial tan pronto como RED muestra lentitud sin error HTTP: el servidor responde 200 en tres segundos porque la base de datos tiene problemas, no porque PHP calcule mal.
Histogramas: calibre los depósitos en su SLO, no en defectos
Un error común: copiar depósitos genéricos (0.005, 0.01, 0.025…) cuando su SLO interno dice "95% de las solicitudes de pago < 500 ms". Los segmentos mal elegidos se encuentran en la página 95: el cuantil calculado cae entre dos segmentos y suaviza una degradación real.
Ejemplo de consulta PromQL para un p95 por ruta:
histograma_cuantil(
0,95,
suma(tasa(http_request_duration_segundos_bucket[5m])) por (la, ruta)
)
Adapte los depósitos a su realidad: si la mayoría de las solicitudes se ajustan a menos de 200 ms pero el pago puede durar hasta 2 s, sus depósitos deben cubrir este rango, no solo la zona de menos de un segundo.
Alerta sobre lo que interrumpe la experiencia, no sobre umbrales arbitrarios: pago de p95 > 2 s durante diez minutos, grupo de base de datos sin conexión inactiva disponible, retraso del archivo de Redis por encima de un umbral empresarial. Una alerta de "disco al 70%" sin correlación del usuario alimenta la fatiga de alerta sin proteger el pago.
Etiquetas y cardinalidad: la trampa silenciosa
Prometheus no es un almacén de troncos. Cada valor de etiqueta multiplica la serie temporal. http_requests_total{user_id="8842"} o {url="/product/chaise-rouge-42"} pueden llevar una instalación saludable a una TSDB inmanejable en cuestión de días.
Reglas pragmáticas:
- Plantilla de ruta sí (
/api/cart/{id}), URL completa no. - Código HTTP, método, entorno sí; número de identificación del cliente
- ¿Necesita detalles por usuario o por pedido? Rastros o registros estructurados, no etiquetas de Prometheus.
En un VPS modesto, la cardinalidad no controlada cuesta RAM y consultas PromQL lentas, cuando más lo necesita.
Qué instrumentar primero dependiendo de tu hosting
En VPS compartido o pequeño, no duplique la pila de un hiperescalador:
- Aplicación: duración por ruta crítica, errores, saturación del grupo de bases de datos si lo administra.
- Nginx o proxy inverso: latencia ascendente, conexiones activas.
- node_exporter — USO básico (CPU, RAM, disco) para descartar una saturación obvia.
OpenTelemetry o un cliente nativo de Prometheus (Go, Node, PHP con biblioteca adaptada) en el corazón de la aplicación late una colección de exportadores exóticos. A menudo es suficiente una retención local de quince días; Más allá de eso, Thanos o Mimir sólo tienen sentido con volumen y un equipo de operaciones dedicado.
Compare las ofertas donde puede instalar sus propios agentes a través de nuestro directorio: límite estricto compartido a veces Prometheus en el host; un VPS administrado o en la nube abre más margen.
Cuando las métricas ya no son suficientes
Prometeo agregados. Una consulta lenta entre mil rápidas puede permanecer invisible en la página 95. Lentitud esporádica, bloqueos ocasionales de Redis, la consulta SQL olvidada en una ruta de código poco común: aquí, necesita un rastreo (Tempo, Jaeger) o registros correlacionados con un request_id común: tema tratado en Registros centralizados.
Los tres pilares se complementan entre sí:
- Métricas: tendencia, alerta, SLO.
- Registros: contexto textual, seguimiento de pila, parámetros.
- Rastros: ruta de una solicitud a través de los servicios.
Prometeo por sí solo no es una observabilidad total. Esta es la herramienta adecuada para señales agregadas, siempre que haya elegido las señales correctas.
La cumbre: la ilusión de los paneles completos
Esto es lo que omiten los tutoriales "Grafana en diez minutos".
Elegir métricas es apostar por los posibles cuellos de botella de su arquitectura y eliminar el resto del ruido.
Decide y avanza sin puntos ciegos
Al cabo de medio día, podrás volver a poner Prometheus en el servicio de diagnóstico:
- Enumere dos rutas críticas (pago, inicio de sesión, API de socio), no “sitio completo”.
- Aplique ROJO en estas rutas: contador, errores, histograma con depósitos alineados con SLO.
- Agregue una métrica USE vinculada a la sospecha principal (grupo de bases de datos, Redis, cola de trabajos).
- Revise las etiquetas: elimine las dimensiones de cardinalidad alta.
- Reemplace una alerta de CPU con una alerta p95 o de grupo de saturación; prueba bajo carga simulada.
- Documente una consulta PromQL que el servicio de guardia debe iniciar en el primer incidente.
Para comparar hosts donde tendrá control sobre la instalación (VPS, nube, PaaS parcial), utilice el comparador y las guías. Si la lentitud sigue siendo opaca después de limpiar las métricas, continúe con Seguimiento distribuido en lugar de agregar un decimoquinto panel.
Ejercicio concreto: simule una degradación (grupo de bases de datos reducido, latencia artificial) y verifique que una sola consulta PromQL identifique la capa defectuosa en menos de cinco minutos. De lo contrario, sus métricas siguen contando la historia equivocada.
Preguntas frecuentes
¿Qué métricas mínimas para una API?
ROJO: flujo, errores, duración en histograma. Complete con la saturación del grupo de conexiones o del caché si la lentitud se correlaciona con ello, no solo la CPU del servidor.
¿Por qué evitar demasiadas etiquetas?
Cada etiqueta multiplica la serie temporal. Plantilla de ruta y código HTTP sí; user_id y URL completa no. Los detalles individuales entran en rastros o registros.
Contador, indicador o histograma: ¿qué elegir?
Contador con rate() para volúmenes; indicador de estado instantáneo; histograma para latencias con depósitos calibrados según su SLO.
¿Prometeo es suficiente por sí solo para diagnosticar la lentitud?
Para tendencias y alertas agregadas, sí. Para valores atípicos esporádicos, complemente con registros y rastreos correlacionados: Prometheus no reemplaza la investigación línea por línea.
La próxima vez que un panel esté completamente verde mientras los usuarios disminuyen la velocidad, haga una pregunta: ¿qué métrica falta para contar la historia de lo que están experimentando? Aquí es donde comienza un Prometheus útil.