davidtoribioeu/Plan2026
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
Plan2026/02-decision-monitoring.md

296 lines
13 KiB
Markdown
Raw Blame History

# Decision: Stack de monitoring para infraestructura Proxmox/PBS (100-500 servidores)
## Descartados y por que
| Herramienta | Motivo de descarte |
|-------------|-------------------|
| **Checkmk** | Probado en produccion. Nagios por debajo, consumo de recursos excesivo, version open source limitada. Descartado por experiencia directa. |
| **Nagios/Icinga** | Misma generacion que Checkmk. Modelo de plugins obsoleto. No merece la pena en 2026. |
| **Datadog/New Relic** | SaaS. A 100-500 servidores el coste mensual es prohibitivo y dependes de terceros para tu infra critica. |
---
## La pregunta clave: Prometheus vs VictoriaMetrics
No son competidores exactos. VictoriaMetrics es la **evolucion** de Prometheus:
| Aspecto | Prometheus | VictoriaMetrics |
|---------|-----------|-----------------|
| Lenguaje de consulta | PromQL | MetricsQL (superset de PromQL, compatible) |
| Consumo de RAM | Alto (todo en memoria) | 5-10x menos RAM |
| Consumo de disco | Alto (TSDB poco eficiente) | 7-10x menos disco (compresion agresiva) |
| Retencion largo plazo | Problematico (necesita Thanos/Cortex) | Nativo, sin componentes extra |
| Alta disponibilidad | Necesita Thanos o Cortex | Nativo en cluster mode |
| Compatibilidad | Es el estandar | 100% compatible (scrape, exporters, Grafana, Alertmanager) |
| Scraping | Integrado | vmagent (separado, mas eficiente) |
| Alertas | Alertmanager (separado) | vmalert (integrado) O Alertmanager (compatible) |
| Escalabilidad | Un Prometheus por ~500 targets | Un VictoriaMetrics para miles de targets |
| Complejidad | Simple a escala pequeña | Simple a cualquier escala |
### Recomendacion: **VictoriaMetrics** (single-node)
A 100-500 servidores, un solo nodo de VictoriaMetrics gestiona todo sin problemas. Si algun dia pasais de 1000, se escala a cluster sin cambiar nada mas.
Toda la comunidad de exporters de Prometheus funciona tal cual. Grafana se conecta igual. Los dashboards existentes de Proxmox/ZFS funcionan sin cambiar nada.
---
## Stack propuesto: 4 capas
```
┌─────────────────────────────┐
│ GRAFANA │
│ Dashboards + Alertas UI │
└──────────┬──────────────────┘
│ consulta
┌──────────▼──────────────────┐
│ VICTORIA METRICS │
│ Almacen de metricas │
│ (retencion 1 año+) │
└──────────┬──────────────────┘
│ recibe
┌──────────▼──────────────────┐
│ VMAGENT │
│ Scraping de todos los │
│ exporters (reemplaza │
│ Prometheus server) │
└──────────┬──────────────────┘
│ scrape
┌────────────────────┼────────────────────┐
│ │ │
┌──────▼──────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ node_exporter│ │ pve_exporter │ │ pbs-exporter │
│ (cada server)│ │ (cada PVE) │ │ (natrontech) │
│ │ │ │ │ multi-target │
│ CPU, RAM, │ │ VMs, nodos, │ │ datastores, │
│ disco, red, │ │ storage, │ │ snapshots/VM, │
│ ZFS pools │ │ cluster │ │ ultimo backup,│
│ │ │ │ │ + script jobs │
│ │ │ │ │ (GC/verify/ │
│ │ │ │ │ sync) │
└──────────────┘ └───────────────┘ └───────────────┘
+ Uptime Kuma (aparte, para checks binarios de disponibilidad)
```
---
## Capa 1: Recoleccion (exporters en cada servidor)
### node_exporter (obligatorio en todos los servidores)
- Metricas de sistema: CPU, RAM, disco, red, load, filesystem
- Incluye metricas de ZFS automaticamente (pool health, space, IO, ARC)
- 5MB de RAM, impacto nulo en rendimiento
- Despliegue: un playbook de Ansible, 2 minutos por servidor
### pve_exporter (uno por cluster Proxmox)
- Metricas de la API de Proxmox: estado de VMs, nodos, storage, replicacion
- No necesita instalarse en cada nodo, consulta la API del cluster
- Una instancia por cluster PVE
### pbs-exporter (natrontech) - centralizado, multi-target
- Exporter comunitario en Go: https://github.com/natrontech/pbs-exporter
- **Modo multi-target**: una sola instancia para N servidores PBS (no instalar en cada PBS)
- Cubre: datastores (espacio), snapshots por VM, ultimo backup por VM, host metrics
- Complementado con script de ~40 lineas via textfile collector para GC/verify/sync jobs
- Detalle completo en `decision-monitoring-pbs.md`
- Un unico backend: VictoriaMetrics. Sin InfluxDB.
---
## Capa 2: Almacenamiento (VictoriaMetrics)
### Despliegue single-node
- Una VM con 2-4 vCPU, 4-8GB RAM, 100-200GB disco
- Retencion de 1 año de metricas con compresion agresiva
- Parametros clave:
- `-retentionPeriod=12m` (12 meses)
- `-storageDataPath=/data/victoria-metrics`
- `-httpListenAddr=:8428`
- Recibe metricas de vmagent via remote_write
- Compatible con todas las consultas PromQL/MetricsQL de Grafana
### vmagent (scraper)
- Reemplaza al Prometheus server para la funcion de scraping
- Configuracion identica a Prometheus (mismo YAML de scrape_configs)
- Descubrimiento de targets: desde Netbox (via HTTP SD) o fichero estatico
- Envia todo a VictoriaMetrics via remote_write
- Puede correr en la misma VM o separado
---
## Capa 3: Alertas (vmalert + Alertmanager)
### vmalert
- Evalua reglas de alerta contra VictoriaMetrics
- Misma sintaxis de reglas que Prometheus alerting rules
- Envia a Alertmanager para routing y notificacion
### Alertmanager
- Routing: que alerta va a quien
- Agrupacion: no enviar 100 alertas individuales si hay un fallo general
- Silenciado: mantenimientos programados sin spam de alertas
- Integraciones de notificacion:
- **Telegram** (recomendado para alertas criticas, llega al movil)
- **Email** (para alertas informativas)
- **Webhook** (para integrar con ICSManager, Mattermost, etc.)
### Alertas minimas obligatorias
```yaml
# DISCO
- alert: DiskSpaceWarning
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.20
for: 10m
labels: { severity: warning }
annotations: { summary: "Menos del 20% libre en {{ $labels.instance }}" }
- alert: DiskSpaceCritical
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.10
for: 5m
labels: { severity: critical }
# ZFS
- alert: ZFSPoolDegraded
expr: node_zfs_zpool_state{state!="online"} > 0
for: 1m
labels: { severity: critical }
annotations: { summary: "ZFS pool degradado en {{ $labels.instance }}" }
- alert: ZFSPoolSpaceHigh
expr: (node_zfs_zpool_allocated / node_zfs_zpool_size) > 0.85
for: 30m
labels: { severity: warning }
# PBS
- alert: PBSDatastoreNoBackup48h
expr: (time() - pbs_datastore_last_backup_timestamp) > 172800
for: 1h
labels: { severity: critical }
annotations: { summary: "Sin backup en 48h: {{ $labels.datastore }}" }
- alert: PBSGCNotRunning
expr: (time() - pbs_gc_last_run_timestamp) > 259200
for: 1h
labels: { severity: warning }
annotations: { summary: "GC no ejecutado en 3 dias: {{ $labels.datastore }}" }
- alert: PBSVerifyErrors
expr: pbs_verify_errors_total > 0
for: 5m
labels: { severity: warning }
- alert: PBSDatastoreQuota90
expr: (pbs_datastore_used_bytes / pbs_datastore_quota_bytes) > 0.90
for: 30m
labels: { severity: warning }
# NODO
- alert: NodeDown
expr: up == 0
for: 3m
labels: { severity: critical }
- alert: HighCPU
expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 15m
labels: { severity: warning }
- alert: HighMemory
expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.90
for: 10m
labels: { severity: warning }
# SEGURIDAD (basado en lo aprendido)
- alert: SuspiciousFileChange
expr: node_textfile_mtime_seconds{file="pam_integrity"} != node_textfile_mtime_seconds{file="pam_integrity"} offset 5m
for: 1m
labels: { severity: critical }
annotations: { summary: "Cambio detectado en ficheros PAM en {{ $labels.instance }}" }
```
---
## Capa 4: Visualizacion (Grafana)
### Dashboards recomendados
| Dashboard | Fuente | Uso |
|-----------|--------|-----|
| **Panorama general** | VictoriaMetrics | Mapa de todos los servidores, estado global, alertas activas |
| **Nodo Proxmox** | pve_exporter | VMs corriendo, CPU/RAM/storage por nodo, estado del cluster |
| **ZFS por pool** | node_exporter | Espacio, health, scrub status, IO, ARC hit rate |
| **PBS por servidor** | pbs-exporter (natrontech) + script jobs | Datastores, ocupacion vs quota, jobs GC/verify/sync |
| **Cliente individual** | Custom exporter | Vista para un cliente: espacio usado, ultimo backup, tendencia de crecimiento |
| **Capacidad global** | VictoriaMetrics | Tendencias de crecimiento, prediccion de cuando se llena cada pool, planificacion de compras |
### Grafana alerting (alternativa simple a vmalert)
- Grafana 10+ tiene alerting integrado potente
- Si no quereis gestionar vmalert + Alertmanager por separado, Grafana puede evaluar alertas directamente y enviar a Telegram/email
- Mas simple, menos potente en routing, pero suficiente para empezar
---
## Uptime Kuma: donde encaja
Uptime Kuma NO reemplaza al stack de metricas. Es complementario:
| Stack metricas (VictoriaMetrics) | Uptime Kuma |
|----------------------------------|-------------|
| Metricas continuas (CPU al 73.4%) | Vivo o muerto (si/no) |
| Alertas por umbral (disco > 80%) | Alerta si no responde |
| Historico de rendimiento | Historico de disponibilidad (uptime %) |
| Requiere exporter en cada servidor | No requiere nada en el servidor |
| Complejo | Muy simple, 5 minutos |
**Donde usar Uptime Kuma**:
- Check externo de que PBS:8007 responde desde fuera
- Check de que el DNS (VM 135241) resuelve correctamente
- Check de que los paneles web (Proxmox GUI, PowerDNS Admin) estan accesibles
- Check de certificados SSL (avisa X dias antes de expirar)
- Pagina de status publica para clientes (opcional)
**Donde NO usar Uptime Kuma**:
- Para metricas de rendimiento (eso es VictoriaMetrics)
- Para alertas de disco/ZFS/jobs (eso es vmalert/Grafana)
- Como monitoring principal (es complementario)
---
## Zabbix: por que no lo recomiendo para vuestro caso
Zabbix es muy bueno, pero:
| Zabbix | Stack propuesto |
|--------|----------------|
| Todo en uno (metricas + alertas + dashboards + discovery) | Componentes separados especializados |
| UI propia (potente pero anticuada) | Grafana (moderna, extensible, estandar) |
| Lenguaje de templates propio | PromQL/MetricsQL (estandar de la industria) |
| Agente propio | Exporters de Prometheus (ecosistema enorme) |
| Base de datos relacional (PostgreSQL/MySQL) | TSDB optimizada (VictoriaMetrics) |
| Comunidad Proxmox: templates disponibles | Comunidad Proxmox: exporters maduros |
| Bueno si ya lo conoces | Mejor inversion de aprendizaje a futuro |
Zabbix funciona bien si el equipo ya lo domina. Si estais empezando de cero, invertir en aprender el ecosistema Prometheus/VictoriaMetrics os da mas flexibilidad y es el estandar hacia el que se mueve toda la industria.
Si el equipo no tiene experiencia con ninguno y quiere algo rapido, Zabbix es mas facil de poner a funcionar el primer dia. Pero a medio plazo, el stack propuesto es mas potente y consume menos recursos.
---
## Resumen del punto 1.2 revisado
| Componente | Herramienta | Funcion |
|-----------|-------------|---------|
| **Metricas** | VictoriaMetrics (single-node) | Almacen de todas las metricas, retencion 1 año |
| **Scraping** | vmagent | Recolecta de todos los exporters |
| **Exporters** | node_exporter + pve_exporter + pbs-exporter (natrontech) + script jobs | Generan metricas en cada servidor |
| **Alertas** | Grafana alerting (fase 1) o vmalert + Alertmanager (fase 2) | Notificaciones Telegram/email |
| **Dashboards** | Grafana | Visualizacion de todo |
| **Disponibilidad** | Uptime Kuma | Checks binarios externos (vivo/muerto) |
### Recursos totales estimados
- VM VictoriaMetrics + vmagent + Grafana: 4 vCPU, 8GB RAM, 200GB disco
- VM Uptime Kuma: 1 vCPU, 512MB RAM, 10GB disco (o contenedor Docker en VM existente)
- node_exporter por servidor: 5MB RAM, impacto nulo
- pve_exporter por cluster: 50MB RAM
Reference in a new issue View git blame Copy permalink