# 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