Un stack de monitoreo completo para servidores y Kubernetes
Un stack de monitoreo completo no es Grafana con un dashboard bonito. Un dashboard ayuda a mirar el sistema, pero por sí solo no responde a la pregunta operativa principal: qué se rompió, dónde exactamente, qué tan grave es y a quién hay que despertar.
Un producto pequeño suele necesitar cinco capas: métricas, logs, trazas, alertas y una arquitectura de almacenamiento sensata. Prometheus, Grafana, Loki, Tempo, OpenTelemetry y Alertmanager cubren esas capas sin atarte a un único proveedor de nube. Este stack se puede ejecutar en un solo VPS, en un puñado de servidores o en Kubernetes. Pero no conviene desplegarlo como un montón de contenedores de moda. Hay que armarlo como un sistema que tu equipo pueda operar de verdad y del que obtenga valor.
Qué debe cubrir un stack completo
El monitoreo no empieza eligiendo una herramienta. Empieza con la lista de preguntas que tu equipo quiere responder en producción.
Primera pregunta: ¿está vivo el servicio? Para eso necesitas métricas de disponibilidad, health checks, latencia, tasa de errores y SLOs básicos. Si la API devuelve 200 pero la latencia p95 ha subido a cinco segundos, eso ya es un incidente, aunque el uptime formalmente siga intacto.
Segunda pregunta: ¿alcanzan los recursos? CPU, RAM, I/O de disco, espacio libre, red, file descriptors, estado de los contenedores, presión sobre la base de datos: es la parte aburrida del monitoreo, pero es la que más a menudo te salva de caídas nocturnas. Un disco lleno o un volumen de logs descontrolado tumba productos pequeños más a menudo que los bugs distribuidos complejos.
Tercera pregunta: ¿qué pasó dentro de la aplicación? Aquí las métricas por sí solas no bastan. Necesitas logs estructurados y trazado de peticiones: qué endpoint va lento, qué llamada externa se cuelga, dónde apareció el error y por qué servicios pasó la petición.
Cuarta pregunta: ¿quién se entera del problema? Una alerta sin enrutamiento es solo una entrada en una interfaz. Necesitas reglas, agrupación, supresión de alertas dependientes, silencios durante el mantenimiento y entrega a Telegram, Slack, correo, PagerDuty u otro sistema de guardia.
Quinta pregunta: ¿cuánto cuesta almacenar? La retención de métricas, logs y trazas debe ser una decisión consciente. Guardar todos los logs de debug durante un año en un Loki self-hosted no suele ser una estrategia, sino una futura caída por disco lleno.
El papel de cada componente
En este stack cada herramienta tiene su propia zona de responsabilidad.
Prometheus recopila y almacena métricas como series temporales. Sus puntos fuertes son el modelo pull, el service discovery, los labels y PromQL. Para servidores toma datos de node_exporter, para contenedores de cAdvisor o métricas de runtime, y para Kubernetes del kubelet, kube-state-metrics, el ingress controller, las bases de datos y las aplicaciones. Prometheus responde bien a las preguntas «cuánto», «qué tan rápido», «con qué frecuencia» y «cuándo empezó». (Prometheus)
Grafana es la interfaz de investigación. Grafana se conecta a Prometheus, Loki, Tempo y otras fuentes de datos, construye dashboards, ayuda a explorar los datos con Explore y enlaza distintas señales entre sí. Grafana no debería ser la única fuente de verdad: si Prometheus o Loki desaparecen, los paneles bonitos no te salvan. Pero como ventana única para la operación se ha convertido en la opción habitual. (Grafana)
Loki almacena logs. Su diferencia clave frente al enfoque de Elasticsearch es que Loki no indexa todo el texto de los logs, sino los labels de los streams de logs. Eso reduce el coste de almacenamiento, pero exige disciplina: los labels deben ayudar a filtrar por servicio, namespace, pod, host y entorno, y no convertirse en un conjunto infinito de valores únicos. (Loki)
Tempo almacena trazas distribuidas. Las trazas importan donde una sola petición de usuario pasa por una API, una cola, un worker, una base de datos y un servicio externo. Una métrica muestra el aumento de la latencia. Un log muestra un evento aislado. Una traza muestra el camino de la petición y el lugar donde se consumió el tiempo. (Tempo)
OpenTelemetry es la capa de instrumentación y enrutamiento de la telemetría. Su valor no está en ser «un agente más», sino en que puedes instrumentar la aplicación una vez y enviar trazas, métricas y logs a distintos backends a través de un protocolo común y del Collector. Eso reduce el vendor lock-in y te ayuda a no reescribir la aplicación al cambiar de almacenamiento. (OpenTelemetry)
Alertmanager recibe las alertas de Prometheus, las agrupa, las deduplica, suprime los eventos dependientes y envía notificaciones a los receptores. Prometheus decide que una condición se ha vuelto verdadera. Alertmanager decide cómo evitar que eso se convierta en spam y a quién exactamente debe llegar la señal. (Alertmanager)
Arquitectura para uno o varios servidores
Para un solo VPS o un grupo pequeño de servidores no hace falta empezar con un diseño nativo de Kubernetes. Basta con un stack self-hosted ordenado que puedas levantar con Docker Compose o servicios de systemd.
Un esquema mínimo se ve así:
| Capa | Componentes | Qué recopila |
|---|---|---|
| Métricas del servidor | node_exporter + Prometheus |
CPU, RAM, disco, red, load average |
| Métricas de contenedores | cAdvisor o un exporter de runtime | uso de contenedores, reinicios, límites |
| Métricas de la aplicación | endpoint de Prometheus u OpenTelemetry Collector | request rate, latencia, errores, métricas de negocio |
| Logs | Grafana Alloy u otro agente compatible con Loki + Loki | stdout/stderr de contenedores, logs del sistema, logs de la app |
| Trazas | OpenTelemetry SDK/agente + Collector + Tempo | el camino de la petición entre servicios |
| UI y alertas | Grafana + Alertmanager | dashboards, Explore, notificaciones |
En un solo servidor puedes tener Prometheus, Loki, Tempo, Grafana y Alertmanager junto a la aplicación si la carga es baja. Pero es un compromiso: cuando el servidor cae por completo, el monitoreo cae con él. Un montaje más maduro es un pequeño VPS de monitoreo aparte, que observa los servidores de producción desde fuera y guarda al menos las métricas básicas separadas de la aplicación.
Un mínimo práctico para un VPS: node_exporter, Prometheus, Grafana, Loki, un agente de logs y Alertmanager. Vale la pena añadir Tempo y OpenTelemetry cuando ya tienes varios servicios, colas, dependencias externas o investigaciones de latencia frecuentes. Para un monolito en un solo servidor las trazas pueden ser útiles, pero no deberían retrasar el arranque del monitoreo básico.
Arquitectura para Kubernetes
En Kubernetes el monitoreo deja de ser solo un conjunto de procesos y pasa a formar parte del control plane operativo. Aquí importan el service discovery, los labels, los namespaces, el ownership y las reglas de scrape.
La capa base suele construirse en torno a kube-prometheus-stack. Instala el Prometheus Operator, Prometheus, Alertmanager, Grafana, node exporter, kube-state-metrics y un conjunto de reglas listas. El valor principal del Prometheus Operator no es que «instale Prometheus», sino su modelo de configuración nativo de Kubernetes: ServiceMonitor, PodMonitor, PrometheusRule y la gestión declarativa de los scrape targets. (Prometheus Operator)
Para los logs en el clúster, un agente se despliega como DaemonSet en cada nodo. Lee los logs de los contenedores, añade labels como namespace, pod, container, app, cluster y empuja los streams a Loki. Aplica la misma disciplina de labels que antes: request_id, user_id y las URL en bruto deben quedarse dentro de la línea de log o del payload estructurado, no en el índice.
Para las trazas, las aplicaciones se instrumentan con el OpenTelemetry SDK, autoinstrumentación o un enfoque de sidecar/agente. El OpenTelemetry Collector puede correr como DaemonSet para la ingesta de telemetría local al nodo o como gateway en Deployment para el procesamiento centralizado. En un clúster pequeño suele bastar el modo gateway. En uno grande, la combinación de agente + gateway reduce las pérdidas de red y centraliza el sampling, el enriquecimiento y la exportación.
En Kubernetes, Tempo suele recibir trazas por endpoints compatibles con OTLP, Jaeger o Zipkin y las almacena en object storage o en un backend local si es un entorno pequeño. Para un clúster de producción, un disco local como almacenamiento de trazas a largo plazo es un punto débil. El object storage es casi siempre la opción más honesta.
Cómo conectar métricas, logs y trazas
El error principal en la observabilidad self-hosted es montar tres almacenamientos y dejarlos como tres mundos separados. Entonces un ingeniero ve un pico en Prometheus, luego busca a mano los logs en Loki y después adivina una traza en Tempo. Es mejor que nada, pero todavía no es un stack completo.
La conexión empieza con labels coherentes: service, environment, cluster, namespace, pod, instance. Si el servicio se llama api en Prometheus, backend-api en Loki y main-http en las trazas, la investigación se convierte en una traducción manual entre sistemas.
La segunda conexión son trace_id y span_id en los logs. Cuando la aplicación escribe logs estructurados con contexto de traza, Grafana puede abrir una traza desde una línea de log concreta. En sentido inverso, Tempo puede mostrar los logs relacionados con un span. Esto es especialmente útil con errores que solo se ven en una única petición y no generan un pico apreciable en un dashboard.
La tercera conexión son los exemplars. Una métrica de latencia muestra un agregado, pero un exemplar puede atar un punto del gráfico a una traza concreta. El camino de la investigación se acorta: pico en el gráfico → traza de la petición lenta → logs del span concreto → causa.
Justo aquí OpenTelemetry importa más de lo que parece al principio. Aporta un contexto común para las señales de telemetría y evita que recopiles métricas, logs y trazas como tres proyectos independientes.
Cuándo se justifica un stack self-hosted
Un stack de monitoreo self-hosted tiene sentido cuando el equipo tiene una razón para ser dueño tanto de los datos como de la operación.
La primera razón es el control. En redes cerradas, entornos regulados, productos B2B con logs sensibles o infraestructura sin acceso saliente estable, enviar telemetría a un SaaS externo puede estar prohibido o resultar incómodo.
La segunda razón es el coste a volumen. Con la observabilidad gestionada, el coste suele crecer con el número de series de métricas, la ingesta de logs, el volumen de trazas y la retención. A volumen pequeño un SaaS puede salir más barato porque no requiere un ingeniero. A volumen grande un stack self-hosted a veces gana, si el equipo sabe gestionar la cardinalidad, la retención y el object storage.
La tercera razón es la independencia. Prometheus, Loki, Tempo y OpenTelemetry permiten construir una arquitectura portable: la aplicación no tiene por qué saber que hoy las trazas van a Tempo y mañana parte de la telemetría se duplica a otro backend.
La cuarta razón es el aprendizaje operativo. Un equipo que ha configurado sus propias alertas, dashboards, scrape configs y retención suele entender mejor sus sistemas. Pero esa ventaja solo aparece cuando hay un owner. Un monitoreo self-hosted abandonado es peor que un servicio gestionado, porque crea la ilusión de control.
Cuándo un stack self-hosted es peligroso
El riesgo principal es subestimar que el monitoreo también es un sistema de producción. Hay que actualizarlo, respaldarlo, asegurarlo, escalarlo y comprobarlo.
El primer error típico es la cardinalidad. En Prometheus no puedes añadir sin pensar labels como user_id, email, session_id, path con parámetros en bruto o request_id. Cada combinación única de labels crea una nueva serie temporal. Una sola métrica mala puede comerse más recursos que toda la aplicación.
El segundo error son los logs sin presupuesto. Si cada aplicación escribe a nivel debug en producción, Loki se convierte rápido en una máquina de quemar disco. Los logs hay que normalizarlos: niveles, sampling, retención, exclusión de líneas ruidosas y una política aparte para los audit logs.
El tercer error son las alertas ruidosas. Una alerta que se dispara diez veces al día y no requiere acción enseña al equipo a ignorar el monitoreo. Una buena alerta debería significar: tiene que intervenir una persona, o sufrirá un usuario o el negocio.
El cuarto error es el monitoreo dentro del mismo dominio de fallo. Si toda la observabilidad vive en el mismo clúster que debe diagnosticar, una caída de red o de almacenamiento puede llevarse por delante tanto la aplicación como tus herramientas de investigación. Para proyectos pequeños es un compromiso aceptable, pero hay que entenderlo.
Una configuración mínima de arranque
Para un VPS es el mismo conjunto base de métricas, logs, Grafana y Alertmanager de la sección de servidores. Solo vale la pena añadir una cosa aparte: una comprobación de uptime externa. Un Prometheus interno no siempre mostrará que el servicio es inalcanzable para los usuarios de internet, porque él mismo puede quedar del mismo lado de la caída.
Para Kubernetes la configuración de arranque es distinta: kube-prometheus-stack, Loki con un agente DaemonSet, fuentes de datos de Grafana para Prometheus y Loki, rutas de Alertmanager y PrometheusRules separadas para las aplicaciones. Después añade el OpenTelemetry Collector y Tempo para los servicios donde la latencia y las llamadas entre servicios realmente requieran trazas.
No empieces con Thanos, Mimir, federación multiclúster, un diseño HA complejo y un año de retención si tienes un solo clúster y un equipo de unas pocas personas. Esas son herramientas de la siguiente etapa. La primera etapa es ver los síntomas antes que el usuario, tener alertas que funcionen y pasar rápido de un gráfico a los logs.
Una baseline práctica:
| Escenario | Mínimo | Cuándo ampliar |
|---|---|---|
| Un solo VPS | Prometheus, node_exporter, Grafana, Loki, Alertmanager | Cuando aparecen varios servicios, colas o investigaciones de latencia frecuentes |
| Varios servidores | Un VPS de monitoreo aparte, exporters en los hosts, Loki centralizado | Cuando necesitas Prometheus en HA o retención larga |
| Un clúster de Kubernetes | kube-prometheus-stack, Loki, Grafana, Alertmanager | Cuando necesitas trazas, correlación entre señales y object storage para retención larga |
| Varios clústeres | Un plano de observabilidad aparte, remote write o federación, labels coherentes | Cuando los equipos y entornos empiezan a estorbarse entre sí |
Conclusión breve
Un stack de monitoreo completo para servidores y Kubernetes no es una lista de proyectos open source de moda. Es una arquitectura en la que Prometheus se encarga de las métricas, Loki de los logs, Tempo de las trazas, OpenTelemetry de la recopilación y la portabilidad de la telemetría, Grafana de la investigación y Alertmanager de hacer llegar las notificaciones a las personas.
La opción self-hosted es buena cuando necesitas control, costes predecibles e independencia de una plataforma gestionada. Pero exige disciplina: labels, retención, alertas, actualizaciones, almacenamiento y owners tienen que estar pensados desde el primer día.
Si quieres un consejo práctico breve: empieza con métricas, logs y alertas decentes. Después añade trazas y OpenTelemetry donde de verdad acorten las investigaciones. El monitoreo debe reducir el tiempo hasta entender un problema, no convertirse en otro sistema más que nadie tiene tiempo de monitorear.
Y si tu equipo o producto necesita este tipo de monitoreo pero no tiene capacidad para montarlo y operarlo internamente, delegar la configuración y la operación es una decisión de ingeniería perfectamente razonable. Lo que se puede externalizar está en nuestro catálogo de servicios: desde una configuración puntual de monitoreo y logging hasta soporte SRE continuo.