Inventario de cobertura de monitoreo¶

Fuente de verdad del epic Monitoreo de aplicaciones V1 (Taiga #256, historia #506). Lista qué corre en cada VM y qué cobertura tiene hoy desde el stack de observabilidad, para estimar el trabajo pendiente de monitoreo. Foco actual: GCP. Oficina y SAP on-premise quedan relevados al final como referencia. No cubre seguridad ni infraestructura: eso va en otro proyecto.

Cómo se relevó¶

Fuente	Qué aportó	Fecha
`gcloud compute instances list` + SSH por IAP a las 6 VMs encendidas (`scripts/relevamiento-gcp.sh` y una segunda pasada dirigida)	Contenedores, servicios systemd, puertos, exporters instalados, agentes, reinicios y consumo	2026-09-03
API de Prometheus de producción (`targets`, `up`, `probe_success`, `node_*`, `rules`, `status/tsdb`)	Qué llega realmente, alertas activas, cardinalidad	2026-09-03
API de Loki (`labels`)	Qué logs llegan realmente	2026-09-03
Configs del repo y de los agentes remotos	Qué se pretende recolectar vs. qué llega	2026-09-03
`docker ps` en el servidor Docker de oficina	Contenedores de oficina	2026-09-03

Leyenda: ✅ existe y funciona · ⚠️ existe pero no llega o está roto · ❌ no existe · ➖ no aplica · ❓ a confirmar.

Resumen ejecutivo (GCP)¶

Estado al 2026-09-08, tras el sprint 37. El relevamiento original es del 2026-09-03; las tablas de más abajo conservan lo encontrado entonces con las columnas de cobertura actualizadas.

Proyecto wordpress-bitnami-218212, zona southamerica-east1-a: 7 VMs, 6 encendidas. Prometheus scrapea las 6: node_exporter en todas, cAdvisor en las 3 con Docker, exporters de Postgres, PgBouncer, Redis (3 instancias), Kafka y n8n.
41 targets, todos UP; 53 reglas en 9 grupos, cada una con test en tests/alertas_test.yml; 22 tableros provisionados desde el repo.
Ecommerce cubierto de punta a punta: probes públicos e internos de storefront, CMS, Medusa y n8n; Kafka con lag por consumer group y DLQ; Redis; base en postgres-db-vm; contenedores. Vista de operación: tablero ecommerce-stack.
devops-vm corre el stack y 43 contenedores de apps internas; monitoreada como host, sus contenedores por cAdvisor y el stack se automonitorea. Sin Watchdog por decisión (ADR-0005).
wp-server-1 en retiro: MySQLDown permanente documentado y no corregido. Retirar sus targets al apagarla.
Sin cobertura todavía: bases en contenedores de devops-vm (#567), probes de las apps internas (#272), ResourceSpace (#289), logs de contenedores (#556, con Ops Agent de Google ya mandando syslog a Cloud Logging en 4 VMs), probes SAP que dejaron de llegar (#171).
Fuera de este proyecto: /metrics de n8n y la API de kafka-ui responden públicos sin autenticación (anotado en el epic de hardening).

VMs de GCP¶

VM	Tipo	SO	IP interna	Estado	Rol
devops-vm	c3-standard-4 (4 vCPU, 15 GB)	Debian 12	10.158.0.22	RUNNING	Stack de observabilidad + apps internas + túnel Cloudflare
ecommerce-srv	e2-custom-4-6144 (4 vCPU, 6 GB)	Debian 12	10.158.0.19	RUNNING	Tienda: Medusa, storefront, Payload CMS, Kafka
integrador	c3-highcpu-4 (4 vCPU, 8 GB)	Debian 11	10.158.0.3	RUNNING	Integrador Laravel + MariaDB + PC Manager, crm, dba
postgres-db-vm	n2d-custom-2-4096 (2 vCPU, 4 GB)	Debian 12	10.158.0.24 (sin IP pública)	RUNNING	PostgreSQL 16 + PgBouncer centralizado
redis-srv-vm	e2-small (2 vCPU, 2 GB)	Debian 13	10.158.0.23	RUNNING	Redis 7 en contenedor
wp-server-1	e2-standard-4 (4 vCPU, 16 GB)	Debian 12	10.158.0.21	RUNNING	WordPress público (`www`), Apache + MariaDB nativos
wordpress-dev-vm	e2-standard-2	Debian 12	10.158.0.20	TERMINATED	Apagada, fuera de alcance

Cobertura por VM¶

VM	node_exporter	Scrape en Prometheus	Contenedores	Exporters de servicio	Probes	Logs	Ops Agent GCP	Alertas
devops-vm	✅ (:9100, basic auth)	✅	48, ✅ cAdvisor	✅ job `stack`: Alertmanager, Loki, Grafana, Blackbox	ICMP ✅, HTTP a Alertmanager ✅	❌ (json-file local)	✅ default	✅ `servidor_alertas` + `stack_alertas`
ecommerce-srv	✅	✅	8, ✅ cAdvisor	✅ redis_exporter (medusa_redis), ✅ kafka_exporter	TCP :9000 ✅, HTTP público a shop, cms y medusa ✅, HTTP interno a los 3 ✅, ICMP ✅	❌	✅ default	✅ servidor + redis + contenedores + probes
integrador	✅	✅	➖ sin Docker	✅ mysqld_exporter. ❌ redis-server local, php-fpm, apache	HTTP `integrador` ✅, `pcm` ✅, ICMP ✅. ❌ `crm`, `dba`	✅ Laravel → Loki por Alloy (general, channels, jobs, horizon)	✅ default	✅ servidor + mysql
postgres-db-vm	✅ (:9100, sin auth)	✅	➖	✅ postgres_exporter :9187 scrapeado. ⚠️ pgbouncer_exporter :9127 bloqueado por `ufw` de la VM. Textfile `pgbackrest.prom` disponible (backups)	❌	❌	❌	✅ `servidor_alertas` + `postgres_alertas`
redis-srv-vm	✅ (:9100, basic auth)	✅	1 (redis), ✅ cAdvisor	✅ redis_exporter :9121	ICMP ✅	❌	❌	✅ servidor + redis + contenedores
wp-server-1 (en retiro)	✅	✅	➖ sin Docker	⚠️ mysqld_exporter `UP` pero `mysql_up = 0`: `Error 1130: Host '::1' is not allowed`. No se corrige	HTTP `www` ✅, ICMP ✅	❌	✅ default	✅ servidor + mysql (`MySQLDown` disparada de forma permanente)

Estado de recursos al momento del relevamiento:

VM	RAM usada	Disco `/`
devops-vm	9,4 de 15 GB	52 % de 99 GB
ecommerce-srv	3,0 de 5,8 GB	51 % de 49 GB
integrador	4,1 de 7,8 GB	70 % de 79 GB
postgres-db-vm	1,6 de 3,8 GB	20 % de 30 GB
redis-srv-vm	0,5 de 1,9 GB	36 % de 9,7 GB
wp-server-1	6,1 de 15 GB	56 % de 99 GB

devops-vm: contenedores por proyecto compose¶

Todos con log driver json-file, sin límite de memoria salvo donde se indica.

Proyecto (`/opt/...`)	Contenedores	Imágenes	Salud / reinicios	Público
observability-stack	prometheus, alertmanager, grafana, loki, blackbox_exporter	latest / loki 3.0.0	sin healthcheck, 0 reinicios	`prometheus`, `grafana`, `loki`
taiga	gateway (nginx :9900), front, back, async, events, protected, custom-admin, db, 2 rabbitmq	taiga latest, postgres 12.3, rabbitmq 3.8	solo db con healthcheck	`proyectos`
novu (`/opt/novu`)	api :3300, dashboard :4000, worker, ws :3302, mongodb, redis	novu 3.18.0, mongo 8.0.17	healthy	`novu`, `novu-ws`
resourcespace	web :8085, cron, db	resourcespace 11.0, mariadb 11.4	web sin healthcheck	❓ hostname no encontrado
frappe	frontend :8080, backend, scheduler, websocket, 2 queues, db, 2 redis	frappe-docker v16.26.1, mariadb 10.6	solo db con healthcheck	`hr`
planka	planka :1337, planka-db	planka 2.1.1, postgres 16 (límite 3 GB / 512 MB)	healthy	❓
n8n-production	n8n :5678, worker, redis	n8n 2.26.3 (límites 1 GB / 2 GB)	healthy. Base en postgres-db-vm. Monitoreado: job `cloud-n8n`, redis_exporter, probes, `n8n_alertas`, tablero `n8n`	`n8n`
openwebui-production	open-webui :8090	open-webui 0.10.2 (límite 2 GB, usa 1 GB)	healthy. Base en postgres-db-vm	`chat`
chatwoot	rails :3050, sidekiq	chatwoot v4.14.0	sin healthcheck. Base ❓ (no hay postgres local ni en postgres-db-vm)	`chatwoot`
tracar	app :8082 + :5001/:5023 GPS, postgres	traccar latest, postgres 16	app sin healthcheck	❓
outline	outline :3000, postgres, redis	outline latest	healthy	`wiki` ❓
sap-bridge, sap-kafka-enrichment-worker	1 + 1	ghcr.io/compulandiati	enrichment-worker con 43 reinicios en 3 días, sin healthcheck	➖

El túnel de Cloudflare corre en devops-vm con configuración remota (token): el mapeo hostname a servicio se administra en el panel de Cloudflare, no hay archivo local.

ecommerce-srv: contenedores¶

Contenedor	Imagen	Puerto	Salud / reinicios	Notas
medusa_backend	ecommercev2backend v1.0.1	:9000	sin healthcheck, 7 reinicios	`/health` responde 200
medusa_storefront	ecommercev2frontend v0.1.1	:8000	healthy
medusa_redis	redis 7	:6379	sin healthcheck
payload-cms	payload-cms v1.0.0	:3000	unhealthy hace 3 días: `wget: can't connect`	`cms` responde 200 por el edge, verificar qué sirve
kafka	apache/kafka 4.2.0	:9092, :9094	healthy	1,27 de 1,95 GB de límite, sin JMX expuesto
kafka-ui	provectuslabs	:8080	sin healthcheck	277 de 500 MB de límite

Postgres de Medusa y Payload ya migró a postgres-db-vm (epic #255).

postgres-db-vm: bases¶

Base	Tamaño	Consumidor
n8n	1,3 GB	devops-vm / n8n-production
medusa	199 MB	ecommerce-srv
openwebui	18 MB	devops-vm
payload	15 MB	ecommerce-srv
outline, planka, traccar	7,5 MB c/u	devops-vm (los contenedores locales `*-postgres` siguen corriendo: confirmar cuál usa cada app)

PgBouncer en 10.158.0.24:6432 para las 7 bases. Sin Ops Agent. Sin métricas de backup.

integrador¶

Sin Docker. Apache 2 con vhosts integrador, pcm, crm, dba (con certificados Let's Encrypt), PHP-FPM 8.3, MariaDB 10.5.29, redis-server local, servicio integrador-kafka-consumer (artisan sap:consume-enriched-items) y Alloy que scrapea el host y envía 4 grupos de logs Laravel a Loki.

wp-server-1 (en retiro)¶

Sin Docker. WordPress en /var/www/html/wordpress, Apache 2 con certbot, MariaDB, fail2ban, ufw. La observabilidad de MySQL no funciona: el mysqld_exporter falla por grant IPv6 y MySQLDown queda activa de forma permanente. Decisión del 2026-09-03: WordPress se reemplaza por el ecommerce nuevo, así que no se invierte en corregirlo. Cuando la VM se apague hay que retirar sus targets de prometheus.yml para que no queden ServidorCaido y MySQLDown colgadas.

Stack de observabilidad¶

Componente	Estado relevado	Cobertura propia
Prometheus	21.312 series, 17 targets directos + 14 jobs por remote_write, retención 30 d	✅ se scrapea. Sin alerta de targets caídos globales ni de ausencia de datos remotos
Alertmanager	Receptor único de correo; ruta `critical` igual a la default; receptor Slack sin ruta	HTTP probe ✅. Sin alerta de notificaciones fallidas ni Watchdog
Grafana 12.4.1	6 tableros, `uid` duplicado entre los dos del Integrador	❌ sin scrape
Loki 3.0	Un solo origen (`job=laravel`). `/ready` da 503 desde afuera pero `ready` en local: es el edge o Access, no Loki	❌ sin scrape
Blackbox	5 módulos, 11 targets, todos `probe_success = 1`	❌ sin scrape. Grupo `blackbox` comentado
Reglas	18 alertas en 3 grupos	Activas: `MySQLDown` wp-server-1, `ServidorCaido` staging oficina

Huecos GCP y estimación¶

Solo monitoreo y observabilidad. Tamaño: S ≤ 1 día, M 2 a 3 días, L 4 a 6 días, incluyendo reglas, tablero, prueba de alerta y runbook. Historias del epic #256.

#	Hueco	Alcance concreto	Historia	Tamaño
1	Exporters instalados y no scrapeados	En curso (2026-09-03): devops-vm y postgres-db-vm en `cloud-nodes`, jobs `cloud-postgres`, `cloud-pgbouncer` y `stack`, reglas `postgres_alertas` y `stack_alertas`, tablero `postgres-db`. Desplegado: devops-vm, postgres-db-vm (:9100, :9187) y el job `stack` en `UP`. Bloqueo restante: `ufw` en postgres-db-vm permite 9100 y 9187 desde devops-vm pero no 9127, así que `cloud-pgbouncer` queda `down` hasta que se agregue esa regla (la regla GCP `deny-internal-to-postgres` no resultó ser el impedimento)	#544 (devops), #562 (postgres)	S + S
2	`MySQLDown` permanente en wp-server-1	Sin acción (VM en retiro). Al apagar la VM, retirar sus targets de `prometheus.yml`	#506	➖
3	Probes sin alertas	Hecho (2026-09-04): `blackbox_alertas` con severity por target, ICMP ampliado a postgres-db-vm y redis-srv-vm, tablero Blackbox exportado al repo	#539	S
4	Automonitoreo del stack	Hecho (2026-09-04): job `stack`, `stack_alertas` con `absent()` por job remoto y disco, tablero `stack-observabilidad`, prueba en vivo con blackbox_exporter. Sin Watchdog por decisión: riesgo aceptado hasta tener un receptor externo	#544	M
5	Cero métricas de contenedores	Desplegado (2026-09-03): cAdvisor 0.55.1 en devops-vm, ecommerce-srv y redis-srv-vm, job `cadvisor`, reglas `contenedores_alertas`, tablero `contenedores`. cAdvisor no expone el estado unhealthy del healthcheck de Docker: Payload unhealthy sigue sin alerta hasta el probe HTTP (7)	#550	M
6	Redis sin exporter	Hecho (2026-09-04): redis_exporter en redis-srv-vm y ecommerce-srv, node_exporter en redis-srv-vm, `redis_alertas`, tablero `redis`. Kafka pasó a #579	#170	M
7	Apps internas sin probe	Probe HTTP a `proyectos`, `hr`, `novu`, `novu-ws`, `n8n`, `chat`, `chatwoot`, `wiki`, `kafka-ui`, `crm`, `dba`, `docs`, más Planka, Traccar y ResourceSpace cuando se confirme hostname. Un job, tablero `apps-internas`. Los del ecommerce (`shop`, `cms`, `medusa`) ya están (#572)	#272	M
8	ResourceSpace	Probe HTTP, mysqld_exporter contra `resourcespace-db-1` (mariadb 11.4), disco del volumen de archivos	#289	S
9	Bases de datos en contenedores sin exporter	En devops-vm: postgres de taiga (12.3), traccar, outline, planka; mariadb de frappe y resourcespace; mongo de novu; 6 redis; 2 rabbitmq. Primero confirmar cuáles siguen en uso tras la migración a postgres-db-vm	nueva historia	L
10	Logs de contenedores	Fase 1: decidir por app entre Loki (Alloy con `loki.source.docker`), Cloud Logging (Ops Agent ya instalado, solo falta el receiver de Docker) o nada. Fase 2 proporcional	#556	M + M/L
11	Ops Agent sin criterio	4 VMs mandan a Cloud Monitoring y Cloud Logging con config default. Decidir si se mantiene como segundo canal o se apaga para no duplicar costo	#556	S
12	Healthchecks ausentes	20 contenedores en devops-vm sin healthcheck (Taiga, Frappe, Chatwoot, Traccar, ResourceSpace, el propio stack). Sin healthcheck, cAdvisor solo puede ver reinicios y consumo	#550 (documentar) / repos de cada app	S por app
13	Deuda de tableros	`uid` duplicado del Integrador; tablero `network-health-check` alineado a alertas	#494	S

Foco: ecommerce-srv (Medusa, storefront, Payload, Kafka, Redis)¶

Vista de operación: tablero Ecommerce — Stack completo (ecommerce-stack).

El ecommerce nuevo es la prioridad de la V1. Lo que tiene y lo que falta:

Pieza	Hoy	Falta
Host	node_exporter ✅, `servidor_alertas` ✅, ICMP ✅	➖
Medusa backend (:9000, v1.0.1)	probes TCP y HTTP público e interno ✅ con alertas, contenedor ✅	sin `/metrics` propio (404): métricas de aplicación quedan como pendiente del repo de Medusa; logs (10)
Storefront (:8000, v0.1.1)	probe HTTP a `shop.compulandia.com.py/api/health` e interno ✅, contenedor ✅	al migrar a `www`, cambiar el target y reetiquetar el de WordPress. `/` redirige en bucle a `/py` para clientes sin cookie
Payload CMS (:3000)	probe HTTP a `cms.compulandia.com.py/api/health` e interno ✅, contenedor ✅	el unhealthy de Docker es un bug del healthcheck (`localhost` → `::1`), corregir en el repo de payload-cms
Kafka 4.2 (:9092)	kafka_exporter ✅, `kafka_alertas` ✅ (lag por grupo, DLQ, consumidores críticos), tablero ✅	sin JMX: métricas de JVM del broker pendientes de `jmx_exporter` si hacen falta
Redis (medusa_redis y redis-srv-vm)	redis_exporter ✅, `redis_alertas` ✅, tablero ✅	ninguno tiene `maxmemory`: definirlo en cada `redis.conf`
Postgres de Medusa y Payload	✅ postgres-db-vm scrapeado, `postgres_alertas`	➖

Orden sugerido: 1 (postgres-db-vm y devops-vm, casi inmediato), 3 y 4 (confianza en alertas), 5 y 6 (contenedores, Kafka, Redis del ecommerce), 7 (probes de storefront y Payload junto con las apps internas). 9, 10 y 11 necesitan decisión previa. wp-server-1 no recibe trabajo.

Pendientes de confirmar¶

Hostnames públicos de Planka, Traccar, ResourceSpace y Outline (se probó wiki, responde 200 pero no se confirmó que sea Outline).
Base de datos que usa Chatwoot.
Si los contenedores outline-postgres-1, tracar-postgres, planka-db siguen en uso o quedaron tras la migración a postgres-db-vm.
Qué sirve cms.compulandia.com.py mientras el contenedor de Payload está unhealthy.
Qué consume redis-srv-vm.
Identidad de vm-01 (manda node_exporter por Grafana Agent; no coincide con ninguna VM de GCP: 8 vCPU, 7,7 GB, Debian 12).

Referencia: oficina y SAP on-premise¶

Fuera del foco actual. Relevado el 2026-09-03 desde Prometheus y el propio servidor Docker de oficina.

Host	Cobertura	Pendiente
dkr-srv 192.168.0.201 (Debian 11, 6 vCPU, 23 GB, disco al 84 %)	node_exporter vía Grafana Agent de dev. 52 contenedores en 18 proyectos (staging de Medusa, Payload, n8n, OpenWebUI, Novu, Typesense; Frappe HR, Planka, Chatwoot, ResourceSpace, Glitchtip, Kafka local, sap-bridge; compose `monitoring-network` con Alloy, mktxp, smokeping, snmp-exporter, speedtest)	Sin métricas de contenedores ni logs. speedtest-exporter unhealthy y sin datos en Prometheus. Payload staging unhealthy
dev 192.168.0.220	node + mysqld vía Grafana Agent	➖
staging 192.168.0.250	Servidor dado de baja (2026-09-04). Job `staging_node` retirado del config de referencia del Grafana Agent; aplicar en el agente de dev (192.168.0.220)	➖
MikroTik 192.168.0.1	snmp, mktxp, smokeping	Sin reglas de red
sap-linux 10.100.102.10 (SLES 15 SP4, 40 vCPU, 113 GB)	node (+ textfile `sap_backup_*`), sap_host_exporter, hanadb	Probes TCP a HANA y Service Layer definidos en `config.alloy`: dejaron de llegar hace pocos días (hay muestras en la ventana de 7 días al 2026-09-04, ninguna reciente). Solo `sap_backup_full_*` con muestras recientes
WIN-IATHEPGGQIU 10.100.102.20 (Windows Server 2022)	windows_exporter (3.900 series de servicios, mayor cardinalidad del sistema)	Sin reglas. Probe RDP no llega
OMS 10.100.0.245	❌	Probes HTTP y logs PM2 definidos y no llegan. Tablero OMS con datos ausentes