Saltar a contenido

ADR 0007 — Retirada de InfluxDB y recorder de Home Assistant a PostgreSQL

  • Estado: aceptado
  • Fecha: 2026-10-31

Contexto

Tras la parada de la monitorización legacy (2026-10-29, ADR 0005), InfluxDB quedó como único servicio vivo del stack monitoring en lebron, porque Home Assistant y Telegraf seguían escribiendo en él.

Datos medidos antes de decidir (2026-10-31):

Elemento Valor
Volumen de InfluxDB 43 GB (/opt/hass/influxdb)
Escritores HA (influxdb: sin include/exclude, tags_attributes: [friendly_name]) y Telegraf
Lectores ninguno: la Grafana del clúster solo tiene Prometheus y Loki, no hay dashboards de Influx y la Grafana legacy está parada
hass_db.statistics (largo plazo) 9,1 M filas / 686 MB, desde 2022-05-17
hass_db.statistics_meta 5.322 series
hass_db.states (10 días) 10,5 M filas / 1,17 GB
Entidades registradas 7.056 en total, 5.324 son sensor

Es decir: el histórico largo que interesa (temperatura, energía, potencia, humedad…) ya está en las long-term statistics del recorder, que nunca se purgan, para prácticamente todos los sensores. InfluxDB aportaba únicamente el detalle sub-horario y los dominios no-sensor, sin ningún consumidor desde el 29-oct.

Contexto externo: el add-on de InfluxDB del repositorio de la comunidad de HA fue archivado el 2026-08-28 (se basaba en InfluxDB 1.x, EOL) y su reemplazo oficial es VictoriaMetrics. HA documenta que las estadísticas de largo plazo no se purgan y que cambiar el motor del recorder no soporta migración de datos.

Decisión

  1. Retirar InfluxDB como servicio (2026-10-31): desactivar la integración influxdb de Home Assistant, parar el contenedor y conservar el volumen (43 GB) como archivo, sin migrar sus datos. Al comentar el servicio en el stack, el redeploy de Portainer desde Git elimina el contenedor.
  2. Retirar Telegraf (2026-10-31): su único destino era InfluxDB y sus métricas ya las cubren node-exporter/Alloy en el clúster. Mismo efecto: servicio comentado y contenedor eliminado en el redeploy.
  3. Usar las long-term statistics del recorder como histórico de largo plazo (agregado horario, nunca purgado), sin desplegar un TSDB nuevo.
  4. Migrar el recorder a PostgreSQL en CloudNativePG cuando Home Assistant pase al clúster (Fase 4), preservando las tablas de estadísticas (statistics, statistics_meta, statistics_runs) y el resto del esquema con ha-db-universal-migrator, en un Job dentro del clúster.
  5. Retirar influxdb.gorkarevilla.com de Cloudflare IaC (proxied_hosts), en un PR aparte (hecho el 2026-10-31; el túnel Lebron no tiene regla por host).

El diseño completo, la investigación de métodos de migración y sus evidencias están en docs/specs/2026-10-31-ha-recorder-postgres-design.md; el procedimiento paso a paso, en docs/plans/2026-10-31-ha-recorder-postgres.md.

Consecuencias

  • Se pierde el detalle sub-horario anterior al 2026-10-31 y los estados de dominios no-sensor (switches, luces, binarios, device_tracker, atributos). No se pierde ninguna serie horaria de sensores con state_class.
  • Home Assistant deja de duplicar escrituras: menos CPU, RAM y disco en lebron (que estaba falto de recursos).
  • El histórico deja de depender de un servicio sin lectores y de una versión (InfluxDB 2.x) cuyo ecosistema está migrando a InfluxDB 3.
  • Los 43 GB del volumen siguen ocupando disco hasta que se decida borrarlo; es el plan B si más adelante hace falta el detalle fino (se podría importar en VictoriaMetrics desde ahí).
  • La migración del recorder no puede hacerse antes de mover HA al clúster sin abrir un agujero en el firewall: lebron está en la zona Internal y el clúster en Servidores, y Internal → Servidores solo permite Traefik y DNS. Servidores → Internal sí está permitido, así que el Job del clúster sí puede leer MariaDB en lebron:3306.
  • Rollback de la retirada de InfluxDB: descomentar el servicio en portainer-compose y redeployar el stack (Portainer lo recrea), descomentar el !include en configuration.yaml de HA y reiniciar HA. El volumen está intacto.

Alternativas descartadas

  • Migrar InfluxDB a InfluxDB 2.9 en k3s: conserva el detalle, pero mantiene un servicio pesado y sin lectores, y no resuelve nada del problema real.
  • Migrar a VictoriaMetrics: opción correcta si se necesitara resolución fina de forma indefinida o cruzar HA con métricas de infraestructura. Hoy no hay ningún consumidor de esos datos; supondría un servicio nuevo y convertir 43 GB.
  • Recorder en TimescaleDB: mantendría el histórico dentro de la UI de HA con compresión, pero exige imagen custom en CNPG y HA no lo soporta oficialmente.
  • Solo long-term statistics sin tocar el recorder: no es viable porque MariaDB se va (Fase 3/4) y las estadísticas viven en el mismo motor.
  • Seguir con InfluxDB: add-on archivado, EOL de la generación 1.x, sin lectores y 43 GB de datos que ya no se consultan.