El escudo de Prometheus para VPN: cómo unimos Prometheus y Grafana en 2026

Por qué monitorear VPN en 2026 no es lujo, sino armadura

Los riesgos de la invisibilidad en los túneles

Si la VPN funciona por su cuenta, nos enteraremos de un problema en el peor momento: fallo en una reunión, caída de la facturación, pérdida de telemetría en nodos remotos. En 2026, el tráfico circula cada vez más por túneles cifrados, así que el tiempo de reacción ante una falla es crítico. No podemos permitirnos «cajas negras». Necesitamos métricas, dashboards y alertas que se activen antes de que los usuarios escriban en el chat "nada carga". Y sí, es totalmente posible.

Una VPN sin monitoreo es como un coche sin tablero. Avanzas mientras puedas. Pero es un camino sin retorno. Añadimos Prometheus y Grafana para ver no solo la velocidad, sino también la temperatura del motor, el nivel de combustible y la presión de los neumáticos. Sí, es una metáfora, pero muy acertada. Las métricas de los túneles son nuestro lenguaje de alerta temprana.

Qué KPI y SLO realmente funcionan

Nos encantan los números que tienen sentido. Para VPN son: disponibilidad de túneles, latencia media y p95 del handshake, éxito de establecimiento de conexiones, errores de cifrado, ancho de banda bidireccional, peers y clientes activos, tiempo de rotación de claves, carga de CPU en criptografía. ¿SLO? Por ejemplo, 99.9% de disponibilidad y no más del 0.1% de intentos de conexión fallidos en 28 días. Simple, medible y útil.

Las métricas no están para decorar; sirven para tomar decisiones. Aumentar límites, añadir nodos, rotar claves más o menos frecuentemente, desviar parte del tráfico a una región de respaldo. Cuando hay SLO definidos, desaparece la discusión técnica de “parece que todo está bien” y con ella, las llamadas nocturnas innecesarias.

Qué cambió para 2026

Tres grandes cambios. Primero, las histogramas nativas en Prometheus se volvieron estándar para métricas de red, facilitando almacenamiento y análisis por cuantiles. Segundo, la observabilidad basada en eBPF reduce overhead y ofrece visibilidad detallada hasta flujos y paquetes. Tercero, OpenTelemetry y Prometheus aprenden a convivir en la práctica: mediante OTEL Collector, remote_write y exportación en formato unificado. No son solo tendencias, sino rutina en equipos maduros.

Arquitectura: Prometheus y Grafana para VPN sin dolores de cabeza

Esquema básico y roles de los componentes

La imagen clásica es así: los exportadores corren en los gateways VPN, Prometheus recoge métricas por pull, las almacena y envía a almacenamiento a largo plazo vía remote_write, Grafana crea dashboards y gestiona alertas, y Alertmanager filtra ruido y enruta notificaciones. Mínima magia, máximo control. Cuanto más simple, más confiable.

Agregamos Node Exporter en cada gateway para monitorear CPU, discos, memoria y interfaces de red. Para diagnósticos de capa enlace usamos Blackbox Exporter, que verifica accesibilidad de puertos VPN desde fuera. Y para redes avanzadas, agentes eBPF basados en Cilium u equivalentes, para detectar cuellos de botella a nivel de paquetes. Sin saturar, pero sin mirar a ciegas.

Flujo de datos, almacenamiento y retención

Las métricas VPN suelen ser de alta frecuencia: conexiones suben y bajan, claves rotan, peers cambian. Definimos intervalos de scrape de 5 a 15 segundos para indicadores críticos, y de 30 a 60 para fondo. La retención local en Prometheus es corta, unos 15 días; datos históricos se envían a almacenamiento remoto o servicios TSDB vía remote_write. El equilibrio es simple: agilidad local, historia remota para análisis.

¿Por dónde empezar? Por definir métricas críticas, describir SLO, elegir retenciones, activar muestreo para métricas pesadas, y distribuir scrape en jobs para ajustar frecuencias y timeouts según protocolos y zonas.

Cómo elegir métricas y frecuencias de consulta

El principio es: consultar con más frecuencia métricas sintomáticas y algo menos las causales. Por ejemplo, peers activos, errores en handshake y latencias de encabezado cada 5-10 segundos. Criptografía profunda y tamaño de paquetes cada 30-60 segundos. En 2026 evitamos disparar cañones por moscas: alta frecuencia solo para lo que realmente genera alertas.

Sobre cardinalidad: etiquetas per-client pueden aniquilar TSDB. Cuidado. Agregamos a nivel nodo o peer y solo para investigaciones activamos exportación detallada per-client en ventanas cortas. Ahorra costos y mantiene sano Prometheus.

Exportación de métricas VPN: OpenVPN, WireGuard, IPsec

OpenVPN: veterano confiable

OpenVPN está en miles de empresas. Para monitoreo usamos exportadores que leen la interfaz management o archivos de estado. Recolectamos clientes activos, bytes entrantes/salientes, duración de sesiones, errores de renegociación y reinicios del demonio. Ejemplo: lanzamos un scraper junto al proceso, damos puerto de gestión y recibimos métricas claras.

Ejemplo de línea de comando minimalista: openvpn_exporter --management.addr 127.0.0.1:7505 --management.auth disabled --web.listen-address :9176. Prometheus consulta el :9176 y recibe métricas. Todo simple y transparente.

WireGuard: moderno, rápido y esencial

WireGuard es estándar cuando importa rendimiento y sencillez. Métricas clásicas: wg_peers, handshake_seconds, bytes_sent, bytes_received, allowed_ips, endpoint. El exportador trabaja con wg show e interfaces de sistema. Medimos no sólo cantidad de peers y bytes, sino latencia del último handshake, que muestra conexiones semi-muertas.

Ejemplo de ejecución: wireguard_exporter --web.listen-address :9586 --include-interfaces wg0,wg1 --resolve-endpoints true. Resultado: métricas limpias con etiquetas de interfaces y peers, perfectas para alertas y dashboards.

IPsec: strongSwan y Libreswan sin misterio

IPsec sigue vigente en redes corporativas. Tomamos métricas vía API Vici de strongSwan o logs y scripts para Libreswan. Lo clave: número de SA establecidas, reinicios, errores de autenticación, duración de claves, eventos rekey, comprobaciones DPD. Mantenemos un job con etiquetas para túneles site-to-site, útil para filtros en Grafana.

Si Vici está cerrado, usamos un colector liviano que parsea ipsec statusall y genera métricas de baja cardinalidad. No es perfecto, pero funcional. Lo importante es mantener formato estable y probar el parser ante actualizaciones.

Enfoques universales: Node Exporter y Blackbox

Node Exporter ayuda cuando el exportador de protocolo falla temporalmente: vemos carga CPU en criptografía, colas saturadas, drops de red, saturaciones en interfaces. Blackbox Exporter es nuestro explorador: prueba TCP, UDP vía proxy, verificación TLS, tiempo de respuesta. Un "paraguas" mínimo de observabilidad en una hora para dormir más tranquilos.

Algunos consejos: no habilitar todos los colectores Node Exporter por defecto; filtrar métricas ruidosas. Para Blackbox, usar módulos separados para UDP/TCP/TLS y etiquetarlos con region y probe.

Configuración de Prometheus: desde scrape hasta seguridad

Ejemplos de scrape_configs

Aquí ejemplos compactos sin saltos. WireGuard: scrape_configs: - job_name: wireguard scrape_interval: 10s metrics_path: /metrics static_configs: - targets: ["vpn-gw-1:9586","vpn-gw-2:9586"] labels: role: "vpn" proto: "wg". OpenVPN: - job_name: openvpn scrape_interval: 15s static_configs: - targets: ["vpn-gw-1:9176"] labels: role: "vpn" proto: "ovpn". IPsec: - job_name: ipsec scrape_interval: 30s static_configs: - targets: ["vpn-gw-1:9905"] labels: role: "vpn" proto: "ipsec".

Blackbox TCP port check: - job_name: vpn-blackbox metrics_path: /probe params: module: ["tcp_connect"] static_configs: - targets: ["vpn.example.internal:51820"] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: "blackbox:9115". La idea es clara: intentamos conexión y medimos tiempo y código de respuesta.

Relabeling, descubrimiento de servicios y etiquetas

Etiquetas limpias son mitad del éxito. Convertimos instance a nombre comprensible, añadimos labels environment, region, proto, role, cluster. Relabeling elimina basura: descartamos client_id y etiquetas de gran cardinalidad. En Kubernetes usamos filtros por anotaciones para hallar exportadores automáticamente en DaemonSets. En bare-metal mantenemos file_sd_configs generados desde CMDB o Terraform; todo declarativo, sin clics manuales.

Ejemplo relabel para instance: - action: replace source_labels: [__meta_kubernetes_pod_node_name] target_label: instance. Y para protocolo: - action: replace source_labels: [__meta_kubernetes_pod_label_proto] target_label: proto. Nada mágico, pero ahorra horas al construir dashboards.

Remote_write, federación y escalabilidad

Cuando VPN crece, no sobrecargamos Prometheus local con historia. Activamos remote_write a backend de largo plazo. Config en una línea: remote_write: - url: https://tsdb.internal/api/v1/write queue_config: capacity: 200 max_shards: 10. Federación para resúmenes interregionales: agregados p95 de latencia de handshake y número de peers activos se envían con labels region y proto. Así NOC tiene su panel global y equipos regionales sus detalles.

Estabilidad ante todo. No satures las colas de remote_write. Configura alertas por retrasos y rechazos. Si hace falta, divide métricas en perfiles remotos según carga.

Seguridad, límites y confiabilidad

Scrape por TLS con autenticación mutua? Sí. Usuario y contraseña simples? Si es red aislada, posible. Límites de tasa en exportador y Prometheus son imprescindibles: una consulta malintencionada no debe tumbar colector. Timeouts en jobs y honor_timestamps: false para fuentes inconsistentes. Y límite en cantidad de series temporales por job, para no arruinar TSDB con un error de configuración.

Respaldar configs es tan importante como respaldar datos. Guardamos en Git, usamos CI, validamos con promtool check config y pruebas de alertas en pipeline. Sí, es aburrido, pero evita sorpresas nocturnas.

Dashboards de Grafana: del pulso a la diagnosis profunda

Marco del dashboard y patrones UX

Construimos tres zonas horizontales. Arriba: estado y SLO — disponibilidad, peers activos, errores de conexión en 1 y 24 hrs. En medio: rendimiento — ancho de banda, p95 handshake, CPU en crypto, drops en interfaces. Abajo: diagnóstico — peers específicos, eventos DPD, reinicios del demonio, distribución de RTT. Filtros por environment, region, proto, gateway — indispensables.

No saturamos con colores. Verde bien, rojo para problemas graves, amarillo para degradaciones. Leyendas cortas, títulos claros y unidades definidas: bytes, paquetes, segundos. Básico pero previene malinterpretaciones.

Paneles para distintos protocolos

WireGuard: gráficos de peers e interfaces, latencia del último handshake, velocidad de bytes entrada/salida, contador de intentos de conexión. OpenVPN: clientes activos, renegociaciones y fallos, saltos de ruta, carga del proceso. IPsec: SA establecidas, dinámica de rekey, autenticaciones fallidas, DPD en vivo. No mezclamos todo en un solo conjunto. Para cada protocolo su aporte, pero visión global unificada arriba.

El objetivo es rápido salto de síntoma a causa. Clic desde p95 handshake a peer particular, de tráfico global a interface específica, de alerta a panel de nodo. Menos clics = menos estrés.

Tres niveles de vista: ejecutivos, NOC e ingenieros

Se crean tres presets. Vista ejecutiva: 5-7 bloques con SLO, capacidad y tendencias por región, sin detalles finos. Vista NOC: mapa de incidentes, regiones críticas, colas de alertas. Vista ingenieros: todos los detalles, logs, métricas, filtros. Este enfoque resuelve el eterno problema de "solo muéstrame lo importante" y "dame todos los datos". Todos contentos.

Consejo práctico: controlen versiones de dashboards. Si alguien "mejora" ejes o consultas, debe haber forma de regresar. Historial de cambios es seguro contra errores humanos.

Alerting: menos ruido, más valor

Reglas y ventanas guiadas por SLO

Las alertas parten de SLO. Ejemplo: si porcentaje de handshakes fallidos supera 1% durante 5 minutos seguidos, hay advertencia; 5% por 10 minutos, pager. Si la disponibilidad de túneles baja de 99.9% en las últimas 24 horas, incidente de severidad media. Matemática simple, comportamiento previsible. Sin especulaciones.

Clave elegir bien ventanas. Muy cortas generan ruido, muy largas retrasan respuesta. Para VPN funcionan bien 2-5 minutos para síntomas y 15-30 para tendencias. No olvidar ventanas nocturnas durante rotaciones regulares de claves para no molestar innecesariamente.

Síntomas versus causas

Síntoma: p95 handshake sobre 500 ms o caída repentina de peers activos. Causa: CPU en criptografía saturado o enlace caído. Configuramos dos tipos de alertas. Sintomáticas, fuertes pero breves para reacción urgente. Causales, complementarias para orientar el análisis. Juntas ofrecen claridad, no caos.

En 2026 la integración de anotaciones entre Grafana y Alertmanager permite adjuntar links a paneles y checklists breves. En práctica acelera solución en 20-30%. Un detalle pequeño, pero efectivo.

Enrutamiento y supresión de ruido en Alertmanager

Enrutamos por región, proto y severidad. Técnicos de guardia reciben solo críticas en su región. El resto va a canal común con retraso y deduplicación. Usamos inhibidores: si hay alerta de "degradación regional", alertas de "puerto inaccesible" en mismo lugar quedan bloqueadas. Resultado: 60% menos notificaciones innecesarias en crisis.

Ejemplo corto de regla sin saltos: groups: - name: vpn-alerts rules: - alert: WireGuardHandshakeSlow expr: histogram_quantile(0.95, sum(rate(wg_handshake_seconds_bucket[5m])) by (le,region)) > 0.5 for: 5m labels: severity: warning annotations: summary: p95 handshake sobre 500 ms description: Región {{ $labels.region }} está experimentando latencias.

Pruebas de alertas y validación continua

Definimos perfiles de carga y simulamos fallas: bajamos interfaces, saturamos CPU crypto, apagamos gestión OpenVPN. Las alertas deben activarse como se espera. Registramos resultados en playbook. Ejercicios regulares enseñan al equipo y reducen MTTD y MTTR. Sin magia, solo disciplina.

Además, las reglas pasan por CI: promtool check rules, linters para expresiones, series sintéticas para cuantiles complejos. No es perfecto, pero evita errores de sintaxis y umbrales absurdos.

Logs, trazas y eBPF como potenciadores

Logs de VPN transformados en métricas con parsing

Los logs son fuente de detalles: eventos DPD, renegociación, errores CRL. No nos ahogamos en texto sino convertimos lo importante en métricas: contadores de errores por tipo, histogramas de duración de handshake, etiquetas por región y nodo. Complemento útil cuando el protocolo da pocas métricas. En 2026 muchos equipos usan parsers unificados y meten métricas a Prometheus vía Pushgateway para eventos raros o por OTEL Collector con prometheusremotewrite.

Clave: no confundir roles. Logs para investigar, métricas para alertar. Mantenemos links de alertas a paneles de logs. Contexto breve ayuda mucho.

eBPF: más profundo pero con cuidado

eBPF muestra tráfico detallado: flujos, latencias, retransmisiones, drops con causa. En VPN es oro ante casos conflictivos entre equipos de redes y desarrollo. Instalamos agentes eBPF en peers y gateways con tráfico alto, recogiendo métricas agregadas. Controlamos overhead y actualizaciones del kernel. La regla es simple: activar solo lo que se va a monitorear frecuentemente.

Con eBPF es más fácil entender por qué peers "parpadean": ruta perdida, MTU rompe fragmentación o colas saturadas. Estas pistas ahorran horas y nervios.

OpenTelemetry y Prometheus en conjunto

En 2026 OpenTelemetry no solo es trazas, también métricas. Enviamos métricas VPN por OTEL Collector, normalizamos labels y convertimos a formato Prometheus para almacenamiento. Ventajas: punto único para configuración, filtros flexibles, triple compatibilidad con logs y trazas. Desventajas: requiere disciplina y documentación para no perderse.

Esquema: exportadores mandan métricas directas a Prometheus para alertas urgentes, y paralelo el Collector enriquece y envía remote_write al almacenamiento prolongado. Puede parecer redundante, pero aporta robustez ante fallos.

Operación: rendimiento, costo y confiabilidad

Presupuesto de recursos bajo carga

Gateways VPN suelen saturar CPU por cifrado. Monitoreamos cpu_utilization, crypto_time, irq_load. En Prometheus limitamos TSDB y controlamos cache de página. Para decenas de gateways basta con 2 vCPU y 4-8 GB RAM. Para cientos, escalamos horizontalmente con sharding, federación y separación por zonas. No intentamos hacer "un gigante" en un solo nodo, es caro y poco confiable.

Un par de reglas: si topas en escritura, baja frecuencia, reduce cardinalidad y combina eventos raros en contadores. Si topas en lectura en dashboards, cachea consultas, escribe expresiones simples y usa downsampling cuando sea posible.

Cardinalidad, retención y economía

La cardinalidad es enemiga de la observabilidad. Cientos de miles de etiquetas per-client destruyen TSDB y presupuesto. Mantenemos agregaciones por peer o túnel, activamos logs detallados temporales solo para investigaciones. Política de retención por capas: caliente 7-15 días localmente, templado 30-90 días en TSDB remotos, archivo más largo en almacenamiento objeto o base económica.

En dinero es claro: cardinalidad extra es discos, CPU y licencias extras para almacenamiento a largo plazo. Reducimos 80% de etiquetas "innecesarias" y presupuesto bajó un tercio. Doloroso al principio, pero al final es más fácil para todos.

Backups, actualizaciones y planes DR

Prometheus es stateful pero no tan crítico; configs y alertas son tu responsabilidad. Hacemos backup de repositorio Git, snapshots de almacenamiento a largo plazo, secretos y certificados. Actualizaciones por patrón canario: un colector, una Grafana, un Alertmanager adelante. Si hay falla, revertimos sin pánico.

En DR hay región secundaria con Prometheus frío y sincronización de dashboards. Si cae principal, activamos respaldo. Verificamos migraciones trimestralmente. Sí, aburrido, pero es confiabilidad real.

Compliance, auditoría y privacidad

Métricas VPN pueden tener datos sensibles. Evitamos IDs personales en etiquetas, usamos hashing o seudónimos. Control de acceso a dashboards por roles: NOC, ingenieros, auditores. Guardamos logs de accesos y cambios centralizados. Esto ayuda no solo para auditoría sino para entender quién hizo qué en caso de problemas.

Casos: desde pequeñas oficinas a redes globales

Pequeñas empresas: 10-50 usuarios

Un gateway OpenVPN, otro WireGuard como respaldo. Node Exporter, exportador básico del protocolo, Prometheus en servidor pequeño, Grafana al lado. Alertas: disponibilidad, errores de autenticación, peers offline más de 5 minutos. Puesta en marcha en uno o dos días. Obtienes un dashboard "todo verde" y un par de notificaciones a la semana, nada pesado.

Optimización: elimina métricas costosas, activa solo paneles esenciales, programa rotación de claves. No olvides pruebas regulares de failover: el equipo debe saber qué hacer cuando el gateway principal queda fuera.

Empresas medianas: sucursales y empleados móviles

Varios gateways en regiones, WireGuard para site-to-site, OpenVPN para clientes. Prometheus en cada región, federación al cluster central, almacenamiento remoto común. Alerting con Alertmanager enruta por regiones. Dashboards en tres niveles, roles en Grafana. eBPF activado en momentos puntuales para incidentes de red complejos.

Resultado: detección de fallas baja de decenas a minutos, investigaciones duran horas no días. El negocio ve SLO claros y puede planificar capacidad sin adivinanzas.

Proveedor o red global

Cientos de gateways, miles de peers. Aquí no hay atajos. Colectores shardados, agregaciones regionales, reglas estrictas de etiquetas, generación automática de configs desde CMDB. Remote_write a múltiples almacenes, pruebas de carga frecuentes, actualizaciones canarias. Dashboard NOC con reducción de ruido. Dedicamos tiempo a automatización para evitar dolores de cabeza manuales.

Efecto: incidentes previsibles, respuestas rápidas y ruido mínimo. Sale caro, pero es más barato que caídas masivas o sanciones SLA. El equipo respira tranquilo y el negocio duerme seguro.

Errores comunes y cómo evitarlos

Primero: exceso de métricas y etiquetas per-client descontroladas. Se soluciona con política de cardinalidad. Segundo: alertas sin prioridad ni instrucciones. Se arregla con anotaciones, playbooks y SLO. Tercero: dashboards con 100 paneles sin sentido. Se mejora con estructura, UX y tres niveles. Cuarto: seguridad "para después". Se sana con TLS, roles y auditoría desde el día uno. Quinto: falta de pruebas y plan DR. Lo corrige la disciplina o el azar te golpea.

Y sí, no temas eliminar lo innecesario. El monitoreo no es museo de métricas, sino herramienta. Mejor poco y bueno.

Checklist para implementación: breve y al grano

Preparación

Definir protocolos y nodos. Elegir exportadores. Documentar SLO. Decidir retención y presupuesto. Diseñar esquema de etiquetas. Establecer roles de acceso y requisitos mínimos de seguridad. Preparar CMDB o archivos para file_sd_configs. Todo puede hacerse en una semana sin heroísmo.

Clave acordar desde el inicio: qué incidentes consideramos críticos, a dónde van notificaciones, quién está de guardia. Sin esto, el mejor monitoreo será solo un bonito screensaver en la sala de reuniones.

Despliegue

Instalar Node Exporter y exportadores de protocolo. Levantar Prometheus y Alertmanager. Configurar scrape_configs, relabeling, remote_write. Desplegar Grafana, importar dashboards base, añadir plantillas. Crear primeras alertas. Hacer pruebas rápidas: cerrar puerto, saturar demonio, verificar que lleguen alertas y que paneles respondan.

Registrar resultados, medir MTTD. Ajustar umbrales y frecuencias. Esta etapa es tu oportunidad para adaptar el monitoreo a tu realidad, no solo seguir manuales.

Lanzamiento y capacitación

Hacer sesión para NOC e ingenieros: cómo leer paneles, filtrar por etiquetas, buscar causas. Documentar playbooks para los 5 incidentes principales. Programar fire-drills mensuales con simulación de fallas reales. Actualizar guías tras cada incidente. Estos detalles ahorran semanas en conjunto.

Al mes, hacer retrospectiva: qué alertas sobraron, qué métricas no ayudaron, dónde faltó contexto. Conversa sincera y dos días para mejoras — y tu sistema empezará a sumar, no a restar.

FAQ: lo que se pregunta mucho pero se escribe poco

Respuestas rápidas

¿Es necesario monitorear clientes per-user?

Sólo para investigaciones cortas. Para monitoreo continuo, agrega por peer o túnel. Etiquetas personales matan cardinalidad y presupuesto. Sí, es el dolor de cabeza común para novatos.

¿Qué intervalo elegir para WireGuard?

Para síntomas 5-10 segundos, para métricas causales 30-60 segundos. Si el presupuesto aprieta, amplía ventanas pero mantén chequeos rápidos de puertos.

¿Qué es más rápido de implementar: monitoreo OpenVPN o WireGuard?

WireGuard suele ser más sencillo: menos entidades, métricas limpias. Pero si ya tienes interface management en OpenVPN, levantarlo toma un par de horas también.

Detalles técnicos

¿Qué conservar a largo plazo y qué localmente?

Local: datos calientes 7-15 días para respuesta rápida. Largo plazo: agregados de latencias, errores, capacidad y throughput. Series sin procesar sólo si cuentas con análisis real.

¿Cómo probar alertas sin miedo y sin dolor?

Escenarios en Git, promtool para validar, series sintéticas para cuantiles complejos. Cada mes, simulacros secas con puerto caído, CPU alta y tests manuales desde panel. Aburrido pero efectivo.

Operación

¿Qué hacer con alertas falsas en la noche?

Usar inhibidores, ajustar ventanas, añadir anotaciones con contexto y playbook. Y lo más importante: dedicar tiempo post-incidente para eliminar la causa del ruido o estarás atrapado en el ciclo.

¿Debe usarse OpenTelemetry desde el inicio?

Si empiezas, no. Primero métricas básicas y alertas, luego logs e integración OTEL. Al avanzar, Collector será tu aliado. Intentar todo de golpe es receta para frustración.

¿Cómo entregar métricas de forma segura desde DMZ?

mTLS, listas blancas estáticas, agente Prometheus dedicado en DMZ con federación hacia arriba. No expongas todo indiscriminadamente. Y no olvides rotar certificados y revocarlos.