🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Monitorización Avanzada con Prometheus, Grafana y OpenTelemetry

Actualizado el 23 de octubre de 2025

Imagina tu servicio de hosting como un motor de avión en pleno vuelo: cualquier pequeño desajuste puede desencadenar una catástrofe en cadena. Durante años, los administradores de sistemas dependían de herramientas como Nagios o Zabbix para lanzar alertas reactivas. Pero el ecosistema moderno de microservicios, contenedores y escalado automático exige una observabilidad total. Aquí es donde la tríada Prometheus, Grafana y OpenTelemetry redefine el estándar.

Este artículo es una guía técnica de campo para implementar una monitorización avanzada que no solo detecte fallos, sino que los anticipe. Vamos a construir un pipeline de telemetría completo, desde la recolección de métricas de hosting hasta dashboards dinámicos que harán las delicias de cualquier SysAdmin.

El Problema de la Monitorización Tradicional en Hosting

La monitorización clásica se basaba en sondeos periódicos (ping, check de puertos) y agentes que enviaban datos a un servidor central. Este modelo tiene tres fallas mortales:

  • Latencia en la detección: Los intervalos de 5 minutos pueden ocultar picos de CPU que duran segundos.
  • Falta de contexto: Saber que el disco está al 90% no explica por qué. ¿Es un proceso leak? ¿Un ataque DDoS?
  • Ceguera ante dependencias: Un fallo en la base de datos puede parecer un problema de red desde la perspectiva del servidor web.

Prometheus nació en SoundCloud para resolver esto con un modelo pull (extracción) y un almacenamiento de series temporales optimizado. Grafana puso la guinda con visualizaciones reactivas. Y OpenTelemetry, el estándar de la CNCF, unifica métricas, logs y trazas en un solo protocolo.

[WARNING] No confundas Prometheus con una base de datos relacional. Su modelo es de series temporales (TSDB) y no soporta consultas JOIN complejas. Diseña tus métricas pensando en etiquetas (labels), no en tablas.

Arquitectura de la Monitorización Moderna: El Stack de Tres Capas

Para una monitorización avanzada necesitas tres capas bien diferenciadas:

  1. Recolección y Exportación: OpenTelemetry Collector recibe señales de cualquier fuente (métricas, trazas, logs) y las transforma.
  2. Almacenamiento y Alerta: Prometheus scrapea los endpoints, almacena en TSDB y evalúa reglas de alerta.
  3. Visualización y Análisis: Grafana consulta Prometheus (y otras fuentes) para construir dashboards interactivos.

Componentes Clave

  • Prometheus Server: Su corazón es el retrieval (scrape) y el TSDB. Almacena datos con precisión de milisegundos.
  • Exporters: Agentes que exponen métricas en formato /metrics. El node_exporter es indispensable para servidores bare metal o VPS.
  • OpenTelemetry Collector: Un proxy que recibe datos en formato OTLP y los reenvía a Prometheus, Jaeger o cualquier backend. Ideal para entornos Kubernetes.
  • Grafana: No solo dashboards. También permite explorar datos con Explore, crear alertas visuales y anotar eventos.

Instalación Paso a Paso del Stack

1. Prometheus: El Corazón del Scraping

Instálalo desde los binarios oficiales o usa Docker para entornos de desarrollo.

# Descargar la última versión (ejemplo Linux amd64)
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar xvf prometheus-*.tar.gz
cd prometheus-*

Configura prometheus.yml para scrapearte a ti mismo y a tu servidor:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

Inicia el servidor:

./prometheus --config.file=prometheus.yml

[TIP] Para monitorización servidores en producción, usa systemd. Crea un archivo /etc/systemd/system/prometheus.service y habilítalo con systemctl enable prometheus.

2. Node Exporter: Métricas de Sistema Operativo

Este exportador es la navaja suiza para métricas de hosting: CPU, memoria, disco, red, procesos.

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar xvf node_exporter-*.tar.gz
cd node_exporter-*
./node_exporter

Por defecto escucha en el puerto 9100. Verifica que Prometheus pueda scrapearlo accediendo a http://localhost:9090/targets.

3. Grafana: El Panel de Control

Instala Grafana desde el repositorio oficial (para Debian/Ubuntu):

sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
sudo apt-get update
sudo apt-get install grafana
sudo systemctl start grafana-server

Accede a http://localhost:3000 con usuario admin y contraseña admin (cámbiala inmediatamente). Añade tu fuente de datos Prometheus: URL http://localhost:9090.

4. OpenTelemetry Collector: La Puerta de Enlace Universal

OpenTelemetry es el pegamento que conecta aplicaciones multi-lenguaje con el stack de monitorización. Instálalo con el script oficial:

curl -sSL https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.104.0/otelcol-contrib_0.104.0_linux_amd64.tar.gz | tar xz
./otelcol-contrib --config config.yaml

Un config.yaml mínimo que recibe OTLP y lo exporta a Prometheus:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "myapp"

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

Ahora, cualquier aplicación instrumentada con OpenTelemetry (Java, Python, Go, Node.js) puede enviar métricas a este collector, que las expone en formato Prometheus.

Métricas Clave para Servidores de Hosting

No todas las métricas importan igual. Céntrate en las que predicen fallos:

Métricas de Sistema (Node Exporter)

  • CPU: node_cpu_seconds_total (modo user, system, iowait). Un iowait alto (>20%) indica cuello de botella en disco.
  • Memoria: node_memory_MemAvailable_bytes. La memoria disponible real incluye buffers y caché.
  • Disco: node_disk_io_time_seconds_total mide latencia de I/O. node_filesystem_avail_bytes para espacio libre.
  • Red: node_network_receive_bytes_total y node_network_transmit_bytes_total. Útil para detectar tráfico anómalo.

Métricas de Aplicación (OpenTelemetry)

  • Latencia: http.server.duration (histograma). El percentil 99 (p99) revela outliers.
  • Tasa de error: http.server.request_count con etiqueta status_code. Si >1% de 5xx, algo va mal.
  • Throughput: http.server.request_count por segundo. Útil para escalado automático.

[INFO] En monitorización servidores, las métricas de sistema son la base, pero las de aplicación (OpenTelemetry) son las que te salvan de una crisis. No escatimes en instrumentar tu código.

Creando Dashboards Avanzados en Grafana

Grafana permite consultas ad-hoc, pero los dashboards bien diseñados ahorran horas de debugging.

Dashboard de Visión General del Servidor

  1. Panel de CPU: Consulta 100 - (avg by (instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100). Muestra el uso total.
  2. Panel de Memoria: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100. Porcentaje usado.
  3. Panel de Disco: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_avail_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100. Útil para alertar cuando supere el 90%.

Dashboard de Alertas y SLOs

Crea un panel que muestre el burn rate de tu SLO (Service Level Objective). Por ejemplo, si tu SLO es 99.9% de disponibilidad, el burn rate te indica si estás consumiendo tu presupuesto de error demasiado rápido.

Consulta para error budget restante (en segundos):

(1 - (sum(rate(http_server_request_count{status_code=~"5.."}[5m])) / sum(rate(http_server_request_count[5m])))) * 86400

Multiplica por 30 días para obtener el presupuesto mensual.

Alertas Inteligentes con Prometheus

Las alertas no deben ser ruido. Configura alert.rules.yml:

groups:
  - name: servidores
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU alta en {{ $labels.instance }}"
          description: "Uso de CPU al {{ $value }}% durante más de 10 minutos."

[WARNING] Evita alertas por debajo de 5 minutos de duración. Los picos transitorios generan fatiga. Usa la cláusula for para confirmar la persistencia.

Integra Alertmanager para enviar notificaciones a Slack, PagerDuty o correo.

OpenTelemetry en la Práctica: Instrumentando una Aplicación Web

Supongamos que tienes una API en Python con Flask. Instala el SDK de OpenTelemetry:

pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp-proto-http

Instrumenta tu aplicación:

from opentelemetry import metrics
from opentelemetry.exporter.otlp.proto.http.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.resources import Resource

resource = Resource(attributes={"service.name": "mi-api"})
exporter = OTLPMetricExporter(endpoint="http://localhost:4318/v1/metrics")
provider = MeterProvider(resource=resource, metric_readers=[PeriodicExportingMetricReader(exporter)])
metrics.set_meter_provider(provider)

meter = metrics.get_meter(__name__)
request_counter = meter.create_counter("http.server.request_count", description="Número de peticiones")
request_duration = meter.create_histogram("http.server.duration", description="Duración de peticiones", unit="ms")

Ahora, cada petición HTTP genera métricas que viajan por OTLP al Collector, que las expone a Prometheus. Grafana las visualiza en tiempo real.

Buenas Prácticas y Optimización

Cardinalidad de Etiquetas

Las etiquetas (labels) son el talón de Aquiles de Prometheus. Cada combinación única crea una serie temporal. Si etiquetas con user_id o request_id, puedes saturar la base de datos. Límite recomendado: < 100,000 series activas por servidor.

Almacenamiento a Largo Plazo

Prometheus no está diseñado para retención de años. Usa Thanos o Cortex para almacenamiento en S3/GCS. Thanos extiende Prometheus con consultas globales y retención ilimitada.

Seguridad

  • Protege los endpoints de Prometheus y Grafana con autenticación (HTTPS + OAuth).
  • Usa --web.enable-lifecycle solo en desarrollo. En producción, recarga la configuración con kill -HUP.
  • Los exporters no deben exponerse a internet. Úsalos solo en redes internas.

Conclusión: De la Monitorización a la Observabilidad

La combinación de Prometheus, Grafana y OpenTelemetry transforma la monitorización servidores de un ejercicio reactivo a una ciencia proactiva. Con Prometheus como motor de series temporales, Grafana como interfaz visual y OpenTelemetry como capa de instrumentación universal, tienes un stack que escala desde un solo VPS hasta clusters de Kubernetes con miles de nodos.

La clave está en la calidad de los datos: métricas con contexto (etiquetas), alertas con umbrales dinámicos y dashboards que cuenten una historia, no solo números. Invertir tiempo en diseñar este sistema hoy te ahorrará horas de debugging mañana.

[TIP] Comienza pequeño: instala Prometheus y node_exporter en un servidor de pruebas, luego añade Grafana. Cuando domines lo básico, integra OpenTelemetry en una aplicación. El camino hacia la observabilidad total es incremental, pero cada paso reduce el tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR).

La próxima vez que tu servidor de hosting empiece a fallar, no estarás a oscuras. Tendrás un mapa en tiempo real de cada proceso, cada conexión y cada latencia. Eso, amigo SysAdmin, es el poder de la monitorización avanzada.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel