296 lines
13 KiB
Markdown
296 lines
13 KiB
Markdown
|
# 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
|