Comparativa: Prometheus+Grafana vs Loki+Tempo para observabilidad de aplicaciones PHP

Por · Publicado el · 8 min de lectura

Barras verdes y rojas con líneas de tendencia y eje numérico sobre fondo oscuro
Gráfico de métricas que ilustra la comparativa de stacks de observabilidad Foto: Rafael Minguet Delgado / Pexels

Este comparativo entre Prometheus+Grafana y Loki+Tempo se centra en aplicaciones PHP que prefieren evitar SaaS. Explico dónde cada pila destaca, cómo instrumentar PHP para métricas, logs y traces, costos operativos típicos y cuándo tiene sentido combinarlo todo en Grafana. El objetivo es orientar decisiones prácticas para entornos de producción.

Visión general: dos pilas que se complementan

Prometheus+Grafana cubre métricas y alertas a partir de endpoints por scraping. Es ideal para series temporales: uso de CPU, latencias y conteo de errores.

Loki+Tempo se enfocan en logs y tracing distribuido. Loki indexa etiquetas y almacena logs de forma eficiente. Tempo almacena y consulta traces. Ambos se integran en Grafana.

Para PHP, la pregunta no es solo “cuál es mejor”, sino “qué medir ahora” y “cómo correlacionar eventos” sin depender de SaaS.

Escenarios PHP: web, jobs y colas

En un monolito PHP (Laravel, Symfony o Slim) conviene medir latencia HTTP, errores por ruta, uso de PHP-FPM y base de datos. Logs estructurados facilitan el diagnóstico.

En workers de cola, mida jobs procesados, fallos por tipo y duración. Logs con IDs de correlación permiten seguir una petición a lo largo de la cadena.

Los traces muestran la línea de tiempo de peticiones complejas, llamadas externas y cuellos de botella. La decisión depende de prioridades y presupuesto de datos.

  • Prometheus: latencias, contadores, histogramas y alertas concretas.
  • Loki: logs de aplicación y Nginx en JSON, búsqueda rápida por etiquetas.
  • Tempo: traces con contexto y spans detallados para identificar cuellos de botella.

Arquitectura, almacenamiento y operación

Prometheus es una TSDB local con scrape por pull. Es sencillo para empezar y confiable para métricas. Para retenciones largas, use discos rápidos o integre remote_write.

Loki usa un índice ligero sobre etiquetas y chunks de logs. El costo depende del volumen y la cardinalidad de los labels. Usted controla la retención por stream.

Tempo recibe traces vía OTLP y suele operar con almacenamiento de objetos. La retención depende del muestreo. Tracing sin sampling puede resultar costoso.

  • Prometheus: simple, pero sensible a alta cardinalidad de etiquetas.
  • Loki: eficiente, pero una mala rotulación puede explotar índices y costos.
  • Tempo: requiere estrategia de sampling y límites por servicio.

Instalación y operación con Docker Compose

Ambas pilas funcionan bien con Docker Compose. Lo mínimo es aislar componentes y volúmenes, exponer puertos internos y colocar Grafana encima.

Para métricas, Prometheus hace scrape de exporters y del endpoint /metrics de la app. Para logs, Promtail o Fluent Bit envían a Loki. Para tracing, el SDK de OpenTelemetry envía OTLP a Tempo.

¿Quiere un paso a paso de métricas? Consulte la Guía de Prometheus y Grafana con Docker Compose.

  • Componentes básicos: Grafana, Prometheus, Loki, Tempo, Promtail/Fluent Bit y exporters.
  • Exponga /metrics en la app PHP o use exporters para PHP-FPM y Nginx.
  • Opcional: OpenTelemetry Collector para estandarizar y enrutar datos.

Instrumentación en PHP: métricas, logs y traces

Métricas: use una librería cliente de Prometheus para exponer contadores, gauges e histogramas. Publique /metrics en la app. Para jobs cortos, considere Pushgateway.

Exporters útiles: PHP-FPM exporter, Nginx exporter y Node Exporter en el host. Cubren infraestructura y web server sin tocar la app.

Logs: escriba en JSON con etiquetas estables (app, entorno, servicio). Configure Promtail para recoger archivos y enviarlos a Loki. Use un ID de correlación por petición.

Traces: use el SDK de OpenTelemetry en PHP. Envíe spans vía OTLP a Tempo. Instrumente middleware HTTP y drivers de BD para identificar cuellos de botella.

  • Estandarice nombres de métricas y etiquetas.
  • Use correlación entre log, trace_id y request_id.
  • Documente límites de cardinalidad y retención por servicio.

Consultas y paneles en Grafana

PromQL es expresivo para tasas, percentiles y alertas. Construya SLOs y paneles por servicio.

LogQL permite filtrar por etiquetas y buscar patrones en los logs. Combine con parsers para extraer campos del JSON.

Tempo se integra directamente en Grafana. Investigue spans, dependencias y latencias por operación. Correlacione: de la métrica al log, y del log al trace, en pocos clics.

  • PromQL: rate(), histogram_quantile(), increase().
  • LogQL: {app="php"} |= "error" | json.
  • Traces: visualice el árbol de spans y latencias por capa.

Tabla comparativa: criterios prácticos

Resumen lado a lado para decidir con claridad. Recuerde: puede combinar las pilas dentro de Grafana y evolucionar por etapas.

Criterio Prometheus + Grafana Loki + Tempo (+ Grafana)
Objetivo principal Métricas y alertas Logs y tracing
Colecta en PHP Endpoint /metrics con librería Prometheus Logs JSON vía Promtail; traces vía OpenTelemetry
Ingesta Pull (scrape) y opcional Pushgateway Push (Promtail/OTLP)
Lenguaje de consulta PromQL LogQL para logs; UI/TraceQL para traces
Almacenamiento por defecto TSDB local; opcional remote_write Logs en chunks e índices ligeros; traces en objeto
Curva de despliegue Rápida para comenzar Requiere estandarizar logs e instrumentar tracing
Escalabilidad Buena con etiquetas controladas Buena con rotulación y sampling disciplinados
Cuando destaca SLOs, capacidad y alertas determinísticas Depuración profunda, reproducción de fallos, análisis de causa raíz
Limitaciones comunes Alta cardinalidad degrada TSDB Volumen de logs y traces sin límites explota costos

Cuándo elegir y cuándo combinar

¿Solo métricas? Prometheus resuelve rápidamente SLOs y alertas. ¿Necesita investigar incidentes complejos? Añada Loki para logs detallados. ¿Cuellos de botella entre servicios? Sume Tempo con OpenTelemetry.

Para equipos pequeños, una aproximación incremental funciona: empiece con métricas esenciales y logs estructurados. Active tracing selectivo en las áreas críticas. Revise retención y sampling mensualmente.

  • Empiece simple, mida lo necesario y evolucione.
  • Defina SLOs con Prometheus antes de abrir el “firehose” de logs.
  • Active tracing con muestreo dirigido por error o latencia.

Buenas prácticas y trampas a evitar

Etiquetas en Prometheus: mantenga la cardinalidad bajo control. Evite IDs únicos como etiqueta. Cardinalidad alta degrada el rendimiento y el consumo de RAM.

Logs: escriba JSON limpio y estable. No registre datos sensibles. Separe niveles, estandarice campos y cree pipelines de retención.

Tracing: configure sampling por ruta, código de estado y error. Sin sampling, el volumen crece rápido. Documente costos de almacenamiento y políticas de rotación.

  • Nombre métricas con prefijos claros (p. ej.: http_, db_).
  • Aplique límites por flujo de logs y cuotas por servicio.
  • Monitoree Prometheus, Loki y Tempo desde Grafana.
  • Automatice backups de volúmenes y pruebe restauración.

Próximos pasos y referencias del sitio

¿Quiere empezar por la base de métricas? Siga la Guía de Prometheus y Grafana con Docker Compose.

Para correlacionar todo en PHP, profundice en Tracing distribuido en PHP con OpenTelemetry y en Logs estructurados (JSON) y correlación.

Si aún evalúa alternativas, consulte la comparación sobre APM y observabilidad en PHP en APM para PHP: New Relic vs Elastic vs OTel.

  • Guía de Prometheus y Grafana con Docker Compose.
  • Tracing distribuido en PHP con OpenTelemetry.
  • Logs estructurados en JSON y correlación en producción.
  • Comparativa de herramientas de observabilidad para PHP.

Preguntas frecuentes

¿Se puede usar Prometheus y Loki+Tempo juntos en el mismo Grafana?

Sí. Grafana soporta múltiples fuentes de datos. Puede consultar métricas con PromQL, logs con LogQL y traces desde Tempo. El verdadero beneficio es la correlación: parta de una métrica de latencia, abra los logs de esa ventana y, si hace falta, llegue al trace correspondiente.

¿Cómo correlacionar logs, métricas y traces en PHP?

Propague un request_id y trace_id desde la entrada HTTP. Incluya esos campos en las métricas como etiquetas controladas, en los logs JSON y en los spans de OpenTelemetry. En Grafana use enlaces y variables para navegar del panel de métricas a los logs y del log al trace.

¿Necesito OpenTelemetry para usar Tempo?

Tempo habla OTLP, así que lo recomendado en PHP es instrumentar con el SDK de OpenTelemetry. Este envía spans y atributos estandarizados a Tempo. Existen integraciones para HTTP, base de datos y colas. Configure el sampling para equilibrar detalle y volumen.

¿Y si mis jobs PHP son cortos y acaban rápido?

Para métricas, use Pushgateway de Prometheus: el job empuja métricas antes de terminar. Para logs, escriba JSON y deje que Promtail los recoja. Para tracing, emita spans cortos y asegúrese de hacer flush al finalizar el proceso para no perder eventos.

¿Dónde almacenar los datos en producción?

Depende de volumen, retención y presupuesto. Prometheus puede correr con disco local rápido y backups. Loki y Tempo funcionan bien con almacenamiento de objetos. Defina políticas por entorno y servicio, y revise periódicamente consumo y necesidad de compactación.

¿Quiere ayuda para diseñar su stack de observabilidad open‑source en PHP?

Explique su escenario, prioridades y restricciones. Podemos evaluar juntos la combinación adecuada entre métricas, logs y tracing, y un plan incremental de despliegue.

Hablar sobre observabilidad PHP

Ver también