Promtail → Alloy: plan de equivalencia, 20 octubre de 2026

Sólo fuente y documentación; sin despliegue, instalación o lectura remota. Promtail llegó a EOL el 2 de marzo de 2026 según Grafana. La propuesta sustituye el agente de logs existente, sin añadir plataforma, receptor, scraping de productos ni cambios de watchdog. La incidencia de pmx50 sigue abierta; no se propone cambiar su colector durante una ventana inestable.

Qué acredita la fuente

Base revisada 405b429. El role Promtail declara binario 3.6.10, usuario root, unidad propia, configuración en /etc/promtail/config.yml y posiciones en /var/lib/promtail/positions.yaml. La play tiene tags promtail,never: no converge mediante el pull ordinario. Aplicar ese role instala/arranca/reinicia y consulta /ready; no usarlo para inspección ni como dry-run de esta propuesta.

Render local StrictUndefined + YAML, sin SOPS ni Ansible: pmx50 declara 10 jobs (6 LXC) y pmx51 declara 22 (18 LXC). Los hashes del render son <REDACTED> y <REDACTED>. Son contratos de fuente, no inventario de agentes ni journals accesibles hoy. El README del role conserva listas LXC antiguas; prevalecen template y host_vars.

Flujo fuente	Contrato que debe conservar Alloy
Journal de host	/var/log/journal, max_age 12h; job=systemd-journal; host proxmox-50 o proxmox2-51; unit, syslog_identifier y priority derivados de los campos journal actuales
Journal LXC	Ruta ZFS por CT, max_age 24h; job=lxc, host=lxc-ID, ct_name; unit y priority, sin añadir syslog_identifier por defecto
varlogs	Los seis patrones existentes syslog/kern/auth/daemon/messages/user; job/host y el mismo regex→label syslog_identifier
vzdump / pveproxy	Los globs actuales, job/host y etiquetas filename equivalentes; sin nuevo parser
Salida	http://observa.lan:3101/loki/api/v1/push; ningún campo auth declarado en el cliente fuente; no inferir por ello auth runtime ausente

El perfil CT217 sitúa Observa en proxmox2; la lectura Loki 17:56 revalidó ese propietario y puerto 3101, pero no permisos de push, DNS de los emisores ni configuración de Promtail. El inventario de septiembre que apunta a VM208 no se toma como runtime actual.

Conversión y estado: decisiones obligatorias

Usar el conversor oficial sólo sobre copias privadas de configuraciones acreditadas, con binario/release y SHA fijados en la futura implementación. Revisar todas las advertencias y validar el candidato; no activar --config.bypass-conversion-errors ni usar conversión transparente en producción como sustituto de revisión.

• Journal: loki.source.journal con path y 12h/24h explícitos, más reglas de metadatos; no adoptar su valor por defecto 7h. Su documentación advierte de un job basado en el nombre del componente: fijar el job histórico en un relabel final posterior al source y comprobar el evento emitido, no sólo el HCL. Mantener MESSAGE, sin envolverlo en JSON ni convertir todos los campos en labels.
• Cursor journal: evaluar legacy_position { file=..., name=... } con copia privada de posiciones. name es el job_name Promtail: journal para host, lxc-ID-ct_name para cada CT; no el label systemd-journal/lxc. La importación sólo ocurre si no existe estado nuevo. Mantener nombres de componentes y storage.path estables después. Referencia journal.
• Ficheros: local.file_match→loki.source.file y el proceso regex existente. Usar legacy_positions_file según su formato soportado, conservando paths y labels; no compartir un fichero de posiciones mutable entre agentes. El estado Alloy pertenece a su storage.path/componente; retirarlo o renombrar componentes puede causar replay. Posiciones desconocidas/corruptas bloquean el cambio; no elegir silenciosamente inicio o fin del archivo. Referencia file.
• Tiempo: la fuente no declara stage.timestamp. No añadir uno para “corregir” la falta de cobertura PRE observada en Loki. Exigir fixtures journal con tiempo de evento conocido y llegada diferida, y ficheros con fechas en el texto: comparar timestamp enviado, precisión, zona y cuerpo entre agentes. La falta de ese cotejo deja equivalencia temporal pendiente.

Alcance LXC y secuencia operativa futura

ADR27 §4.5 propone journal-upload por CT y journal-remote central en Observa, para seguir al CT tras HA. La fuente actual sigue leyendo subvolúmenes por nodo; esa centralización no está acreditada. No mezclarla con el reemplazo del agente: primero levantar un contrato de cada ruta realmente usada, propietario PVE y journal local frente a réplica pasiva. No copiar a ciegas las 24 entradas LXC, leer ambas réplicas, perder flujos silenciosamente ni declarar HA resuelto por cambiar Promtail a Alloy. Si fuente y runtime difieren, bloquear y reconciliar antes de diseñar el cambio desplegable.

1. Preflight futuro, acotado y de lectura: propietario, versión/hash/argv de unidad, configuración efectiva y archivos/cursores con permisos e identidad; credenciales sólo en RAM. Acreditar también recursos y destino existente.
2. Probar fuera del homelab con journals exportados sintéticos y archivos temporales, receptor HTTP local de fixture, sin Loki de producción. Casos: labels exactos, mensaje sin cambios, tiempos anteriores al arranque del lector, importación de posiciones, reinicio, rotación, cursor ausente/corrupto y auth error. Medir RAM/CPU, duplicados, omisiones y cola; no asumirlos cero.
3. Antes de un canario autorizado, conservar binario, unidad, config y estado Promtail. Un único escritor por flujo: parar ordenadamente el agente anterior, acreditar su cola/errores y snapshot final de posiciones, importar la copia e iniciar Alloy sin compartir estado. No ejecutar ambos hacia los mismos streams ni hacerlo en ambos nodos a la vez. Verificar límites del lote y cola en el corte: cursor leído no demuestra entrega confirmada; no se promete exactly-once.
4. Aceptar sólo con etiquetas históricas comprobadas en salida y recepción, progreso de cursor/lectura y envío, cero errores no explicados y continuidad tras reinicio sintético y rotación. /ready o componente healthy no bastan: la documentación advierte que falta de acceso al journal puede dejarlo sin entradas aunque arranque. Adaptar métricas/consultas del agente, no las reglas de salud de productos, y observar el canario antes del segundo nodo.
5. Rollback preparado antes del corte: detener sólo Alloy del canario, conservar su estado y pendientes, restaurar unidad/config/estado Promtail acreditados y revisar replay/gap limitado. No trasplantar offsets Alloy al fichero legacy, eliminar cursores ni declarar ausencia de duplicados sin cotejo. Sin rollback automático ante corte o resultado desconocido.

Entrega siguiente: un role de sustitución con never, pin verificable, render y fixtures anteriores en CI; sin auto-start por publicar fuente. Este plan no descarga Alloy, no ejecuta convert, no modifica roles o servicios y no acredita una migración realizada. La arquitectura journal-upload central queda en otra fase.