Fuente efectiva de configuración Prometheus tras la migración¶
20 de octubre de 2026. Investigación selectiva sólo lectura en CT217,
revalidado como LXC ejecutándose en proxmox2. No se ha escrito configuración,
recargado, reiniciado o recreado un contenedor, ni consultado productos por HTTP.
Los YAML se compararon en memoria; no se imprimieron ni persistieron completos,
ni se mostraron autenticación, credenciales o valores de targets.
Hallazgo¶
La diferencia entre el fichero del home y el fichero visto dentro del contenedor
no demuestra un bind mount obsoleto. Son dos fuentes distintas. El montaje
real de /etc/prometheus/prometheus.yml usa /opt/observa/conf/prometheus.yml;
esa fuente y el fichero del contenedor tienen el mismo hash, inode, tamaño y
mtime. El fichero del home no es la fuente montada actualmente.
| Fichero | SHA256 | Inode | Tamaño | mtime UTC |
|---|---|---|---|---|
CT217 /home/monxas/appdata/prometheus/prometheus.yml |
<REDACTED> |
1029711 | 6109 B | 2026-09-25 17:18:53 |
CT217 /opt/observa/conf/prometheus.yml |
<REDACTED> |
1107915 | 6060 B | 2026-10-19 11:09:17 |
Contenedor /etc/prometheus/prometheus.yml |
<REDACTED> |
1107915 | 6060 B | 2026-10-19 11:09:17 |
Los mtimes acreditan la antigüedad registrada de esos ficheros; no demuestran quién realizó los cambios ni que se hayan mantenido sin modificación desde esa fecha. El hash efectivo coincide con el baseline registrado en el despliegue selectivo de alertas de las 00:54 CEST.
Docker declara ambos montajes como bind de sólo lectura, propagación rprivate:
| Destino en Prometheus | Fuente CT217 |
|---|---|
/etc/prometheus/prometheus.yml |
/opt/observa/conf/prometheus.yml |
/etc/prometheus/alerts.yml |
/home/monxas/appdata/prometheus/alerts.yml |
Las etiquetas selectivas de Compose identifican /opt/observa/compose.yaml y
working directory /opt/observa. Ese Compose, SHA256
<REDACTED>,
declara exactamente las dos fuentes anteriores. No se inspeccionaron entornos
completos ni otras etiquetas del contenedor.
Diferencias semánticas acotadas¶
El fichero del home y el efectivo contienen los mismos 26 nombres de jobs.
No hay diferencias semánticas en los demás bloques superiores. Cambian sólo
static_configs de estos siete jobs:
node: targets y labels.blackbox-http-internal: targets.asus-router: targets y label instance.openclaw-vm-node: targets y label instance.openclaw-vm-process: targets y label instance.rchat: targets.jev-gateway: targets y label instance.
No se publican los valores de esos campos. Las diferencias son compatibles con la migración previa, sin atribuir su autoría ni fecha exacta por inferencia.
Estado de la fuente declarativa¶
En la lectura inicial, el template ansible/roles/observability_collector/templates/prometheus.yml.j2
tenía 23 jobs, frente a26 efectivos. Faltaban en esa versión
blackbox-dns, blackbox-wallet y blackbox-wallet-local. Entre sus jobs comunes
también difieren los static_configs de los siete jobs anteriores. Para comparar
la estructura se sustituyó únicamente la variable de token HA por un placeholder
local; no se resolvió SOPS ni se imprimieron valores de autenticación.
La play Prometheus config (VM 208) de ansible/playbook.yml:464 sigue dirigida
a docker_hubs —inventario actual: media-208— y fija
prometheus_dir: /home/monxas/appdata/prometheus. Mantiene un swap que reinicia
Prometheus antes de validar su configuración efectiva. Por tanto, no describe
el propietario CT217 ni su fuente de configuración actual y no se considera un
procedimiento acreditado para aplicar cambios a este runtime migrado.
En homelab-stacks, infra/compose.migrado.yaml conserva el montaje antiguo del
home. Su cabecera declara que queda fuera del glob activo y está destinado a la
vuelta atrás de ADR-0027; infra/compose.yaml activo ya no contiene Prometheus.
No se localizó en las fuentes inspeccionadas una definición versionada del
Compose vivo de /opt/observa. ADR-0027, apartado de pendientes, ya identifica
la codificación de /opt/observa en Ansible como trabajo pendiente.
Riesgo y siguiente cambio revisable¶
Recrear con el Compose vivo inspeccionado, sin cambiarlo, seguiría montando
/opt/observa/conf/prometheus.yml; la discrepancia observada no requiere un
recreate para resolverse. Utilizar el Compose archivado, reemplazar la fuente
efectiva por el fichero antiguo del home o aplicar el template incompleto podría
recuperar targets anteriores o perder tres jobs. No se ha realizado ninguna de
esas acciones.
La siguiente fase debe versionar la declaración de CT217 y sus dos fuentes distintas, reconciliar los 26 jobs en memoria sin exponer secretos y añadir guardas de propietario, mounts y hashes antes de cualquier aplicación. La validación candidata debe preceder a la activación; no se necesita introducir un reinicio como respuesta a este hallazgo. Este informe no autoriza ni ejecuta esa reconciliación.
El coordinador informó por separado del despliegue de la regla número 87 en el fichero de alertas, preservando su inode y sin cambiar ninguna de las dos configuraciones aquí contrastadas. Esta investigación no valida de nuevo esa regla ni altera su evidencia de despliegue.
Colección efectiva y probes ya recogidos: 02:53–02:56 CEST¶
Dos lecturas posteriores, cada una explícitamente autorizada y realizada mediante
una sola conexión SSH pmx2 → pct exec 217, distinguen configuración, scrapes y
resultado de probes. Se consultó únicamente la API local existente de Prometheus
en 127.0.0.1:9090: inventario de targets activos y, después, una query instantánea
agregada de probe_success y ALERTS. No se forzó ningún scrape o probe, ni se
hicieron GET a productos/Home Assistant, POST, cambios o acciones sobre apps.
Cada respuesta tuvo cap de 2 MiB, timeout y alarma de diez segundos, y rechazo
de redirects. Los datos se procesaron sólo en RAM; las salidas omiten URLs,
instances, labels privados, credenciales y errores crudos.
Scrapes observados a las 02:53:34.023174 CEST¶
La muestra de 00:53:34.023174 UTC registra 26 jobs y 44 targets activos, todos health=up, sin errores de scrape registrados. La clasificación agregada dio 44 sin error y cero auth401403, timeout, refused, dns u otros.
Las edades del último scrape fueron de 0,272 a 49,062 segundos, sin timestamps desconocidos. Las máximas fueron jev-gateway 49,062 s, rchat 44,541 s y tnas-f4423 28,157 s; sus intervalos declarados son respectivamente 60, 60 y 30 segundos. Los demás targets tenían edades no superiores a 16,541 s.
Esto acredita la recogida de métricas en ese instante, no continuidad ni salud funcional completa. Un scrape correcto del exporter blackbox no demuestra el resultado del probe; un scrape correcto de Pushgateway no acredita frescura o éxito de sus jobs.
Probes y alertas observados a las 02:56:59.213242 CEST¶
La query de 00:56:59.213242 UTC se resolvió primero contra las fuentes locales:
seis jobs con metrics_path /probe, 22 targets declarados y 87 nombres de alertas
permitidos. Una sola consulta instantánea agregada contó resultados de probes y
series de alertas, sin incluir sus etiquetas de identidad.
| Job | Targets declarados | Series probe_success=1 | =0 / otros valores |
|---|---|---|---|
| blackbox-dns | 1 | 1 | 0 / 0 |
| blackbox-http-internal | 8 | 8 | 0 / 0 |
| blackbox-https-external | 6 | 6 | 0 / 0 |
| blackbox-icmp | 3 | 3 | 0 / 0 |
| blackbox-wallet | 1 | 1 | 0 / 0 |
| blackbox-wallet-local | 3 | 3 | 0 / 0 |
Las cuentas coinciden por job: 22 series con probe_success=1. No hubo warnings de query ni filas con jobs o nombres de alerta desconocidos. La coincidencia agregada no publica ni compara identidades individuales de los targets.
| Estado de alerta | Nombre permitido | Series |
|---|---|---|
| firing | ArrSaludWarning | 3 |
| firing | ProxmoxCPUThrottling | 1 |
| firing | RemotePulseHostDown | 1 |
| pending | JevDependabotPendientesEstancados | 1 |
Las cuatro reglas declaran severity warning. La fuente describe avisos persistentes
de arr durante una hora, tasa de throttling superior a 0,1 eventos/s calculada
en cinco minutos y sostenida diez minutos, falta de
heartbeat de Remote-Pulse durante diez minutos y una cola de Dependabot con
for: 3d, respectivamente. Son reglas sobre métricas ya recogidas: no se probaron
indexers, APIs de producto, notificaciones ni receptores como parte de esta consulta.
Como contexto histórico, la revisión anterior del runtime había asociado tres avisos Arr al mismo indexer MySpleen y documentado un RemotePulseHostDown de un equipo de Carmelo, fuera de alcance. Esta consulta agregada no ha revalidado esas causas ni las identidades actuales: no se atribuyen automáticamente las series observadas ahora a esos mismos orígenes y no se interviene en equipos ajenos.
Cinco series firing no equivalen necesariamente a cinco servicios distintos. La agregación omite el nodo/host/app; en particular, no asigna el throttling a un nodo ni demuestra su causa física. Un exporter accesible y probes correctos pueden coexistir con avisos internos de aplicaciones o heartbeats ausentes.
Los probes proceden de métricas ya retenidas por Prometheus, sujetas a su lookback; no son nuevas comprobaciones de red realizadas a esa hora por el agente. Las dos muestras no certifican disponibilidad continua, cierre de la causa del watchdog, salud completa del homelab, frescura de copias ni entrega real de alertas.
Barrera de fuente para el procedimiento legado¶
La play conserva tags:[never]: el ansible-pull ordinario no la ejecuta. Para impedir un despliegue manual con fuentes y propietario obsoletos, se añadió como primera tarea de prometheus_config_swap un fail explícito, antes del primer render/copy/restart de esa play. Remite a este informe y al procedimiento nuevo que aún debe prepararse; no contiene override. El tag de render conserva sólo candidatos/diff y no aplica configuración. Los comentarios ya identifican swap como bloqueado, en vez de ofrecerlo como procedimiento válido para CT217.
Revisión independiente: YAML válido; al retirar exactamente esa tarea del árbol parseado, las20plays completas coinciden con el baseline anterior. Tagsnever, render y demás tareas intactos. Sin ejecutar Ansible, resolverSOPS ni modificar runtime. Esto bloquea la operación antigua; no reconcilia los26jobs ni versiona por sí mismo el Compose efectivo de /opt/observa.
Reconciliación de fuentes posterior, sin aplicar runtime¶
La plantilla se reconcilió posteriormente con26jobs y los siete bloques static_configs, manteniendo una única variable HA/SOPS y los demás campos; ver paridad redactada. Esto no habilita el swap antiguo: propietario, rutas y mecanismo siguen obsoletos.
También se añadieron barreras iniciales a alertmanager_config y grafana_config: la primera play escribía/HUP en VM208 y la segunda llamaba su API3030 con operaciones de sobrescritura. Ambas conservan never; no se ejecutan por autopull ordinario. Los fails preceden copy/HUP/API, sin consultar productos ni resolver secretos. Se corrigió el comentario de Alertmanager que negaba el reload aunque la tarea sí enviabaHUP. No se ha aplicado ningún procedimiento de sustitución.
Estado registrado de alertas: 16:23–16:27 CEST¶
Estas muestras posteriores leen sólo las APIs existentes de Prometheus en CT217, tras revalidar propietario proxmox2, tipo LXC y estado running. No ejecutan probes, scrapes nuevos, colectores, jobs, APIs de producto, notificaciones ni contactos con clientes RemotePulse. El JSON completo de reglas y las anotaciones quedaron sólo en RAM; se conservaron proyecciones privadas 0600.
Reglas y frescura PVE a las 16:23:26,309759¶
La muestra 14:23:26,309759 UTC registra 92 reglas con health=ok, pero 5 reglas firing, 4 pending y 83 inactive: salud de evaluación no significa homelab sano. OriginalsCopyFailed está firing y PBSDataReserveLow pending. Las cuatro reglas de publicación —OriginalsDumpPublicationFailed, Stale, ConfigurationUnknown y Required— están inactive, health=ok y sin lastError. La compuerta de Required 16:30 CEST más diez minutos de persistencia todavía era futura; su estado no acredita una publicación correcta ni una primera copia del dump.
PVEReplicationCollectorUnhealthy está inactive. Ambos nodos exponen
pvesr_collection_success=1, con último intento 16:20:00 CEST y edad 206,31 s.
La consulta directa timestamp(metric) registra muestras del colector a las
16:23:14,666 para pmx51 y 16:23:15,323 para pmx50, edades 11,64 y 10,99 s.
Son timestamps de muestras existentes, distintos de la hora de evaluación de
una query instantánea; no son fechas de una réplica o backup completados.
Identidades de reglas activas a las 16:24:54,731145¶
Una consulta adicional autorizada de 14:24:54,731145 UTC, motivada por las identidades no retenidas en la primera proyección, conserva sólo metadatos permitidos. Registra92 reglas health=ok, 5 reglas firing y 2 pending, con 85 inactive. El cambio de conteo desde las 16:23 no identifica por sí solo su causa.
| Estado | Regla | Identidad permitida | Instancias activas | ActiveAt, CEST |
|---|---|---|---|---|
| firing | ArrSaludWarning | vm208 | 3 | 18oct19:23:40; 20oct01:22:10,299; 18oct17:13:25 |
| firing | OriginalsCopyFailed | pmx51 | 1 | 20oct16:00:24,061 |
| firing | nas_nfsd_dstate_degraded | nas.lan:9100 | 1 | 20oct15:00:15,069 |
| firing | ProxmoxCPUThrottling | pmx51 | 1 | 19oct23:07:07,509 |
| firing | RemotePulseHostDown | exportador lxc280 / service remote-pulse | 2 | 20oct15:56:00,042, ambas |
| pending | JevDependabotPendientesEstancados | service jev-gateway | 1 | 18oct17:54:02,421 |
| pending | PBSDataReserveLow | pmx50 | 1 | 20oct15:55:18,013 |
Las cinco reglas firing contienen ocho instancias con ese subconjunto de etiquetas. No son ocho servicios distintos acreditados. Todas las reglas de la tabla tienen health=ok y clase de lastError=none; no se publicaron anotaciones, URLs, consultas ni etiquetas privadas. No se revalidan las causas históricas de Arr ni el contenido del backlog Dependabot. ActiveAt es estado de Prometheus, no observación directa del comienzo físico de una avería.
Ámbito RemotePulse a las 16:27:57,461765¶
La consulta instantánea de 14:27:57,461765 UTC sobre métricas ya recogidas
identifica dos series rp_host_up == 0: una fuera de alcance, de Carmelo, y
otra de ámbito desconocido. No se publican ni conservan nombres externos
crudos. LXC280 es el exportador; no se lo confunde con el cliente marcado como
caído. La serie desconocida no se asigna por inferencia al inventario propio.
Ambas muestras tienen timestamp directo 16:27:28,154 CEST, edad 29,31 s y valor 0. Eso acredita lo registrado por el exporter, no una conexión nueva ni la causa de faltar el heartbeat. No se contactó a los clientes ni se actuó sobre ellos; se conserva la exclusión de equipos ajenos y el estado desconocido.
Contexto nativo separado y evidencia¶
La lectura nativa retenida de 16:22:53,212126 CEST mantiene boot 248d8d61 y btime 15:55:04, con uptime 1669,2 s. La unidad Ansible muestra una ejecución natural 16:17:30–16:18:19, inactive/dead, Result=success y rc0; el timer está active/waiting. Es sólo metadato de unidad: esta lectura no aporta un recap de 71 tareas ni un status Git nuevo. No resuelve la causa de los resets ni acredita estabilidad posterior, salud de aplicaciones o eficacia de fsync, que no se ha aplicado.
| Proyección privada | SHA256 |
|---|---|
| prometheus-postboot-20261020/projection-current-142326.json | <REDACTED> |
| prometheus-postboot-20261020/active-rules-142454.json | <REDACTED> |
| prometheus-postboot-20261020/remote-pulse-scope-142757.json | <REDACTED> |
| git-workingtree-restore-20261020-m9hyfrod/currentboot-check-142253.json | <REDACTED> |
Rutas relativas a ~/.local/state/. Cada lectura Prometheus rechazó redirects,
limitó la respuesta a 2 MiB y usó timeout 10 s, sin guardar JSON crudo. Las muestras
son puntuales y no certifican disponibilidad continua ni entrega de alertas.
Requisito de publicación ya vencido: 16:41:38 CEST¶
Una única observación autorizada posterior a las 16:41, con propietario de CT217 revalidado, registra 16:41:38,756300 CEST / 14:41:38,756300 UTC. No se deduce el instante exacto de transición a firing a partir de la hora teórica16:40: se conserva el estado realmente evaluado por Prometheus.
| Regla seleccionada | Estado | ActiveAt, CEST | Última evaluación, CEST |
|---|---|---|---|
| OriginalsDumpPublicationRequired | firing | 16:30:09,060896 | 16:41:24,065278 |
| OriginalsDumpPublicationFailed | inactive | Sin instancia activa | 16:41:24,064821 |
| OriginalsDumpPublicationStale | inactive | Sin instancia activa | 16:41:24,064956 |
| OriginalsDumpPublicationConfigurationUnknown | inactive | Sin instancia activa | 16:41:24,065115 |
| OriginalsCopyFailed | firing | 16:00:24,060896 | 16:41:24,063874 |
| PBSDataReserveLow | firing | 15:55:18,012622 | 16:41:33,014003 |
Las seis reglas tienen health=ok y lastError ausente. Eso acredita evaluación sin error, no éxito de copias ni reserva suficiente. ActiveAt señala cuándo Prometheus mantiene activa la condición; no es por sí mismo el instante exacto de pasar de pending a firing. No se modificó la compuerta16:30 ni su for10m.
Las series existentes, seleccionadas para pmx51/job proxmox-nodes, registran:
| Métrica originals_dump_publication_* | Valor |
|---|---|
| configuration_known | 1 |
| configured_enabled | 1 |
| enabled, historial del último intento | 0 |
| failed | 0 |
| last_success_timestamp_seconds | 0 |
La configuración observada es conocida y habilitada; el campo histórico enabled no acredita que el flag actual esté apagado. Un last_success cero significa que no consta una publicación exitosa, no una fecha desde la que calcular su edad. No se consultó una edad del dump de origen: no había una métrica fuente conocida para ello en esta lectura. Failed/Stale inactivas tampoco acreditan cobertura: la regla independiente Required hace visible la ausencia de primer éxito.
Proyección privada 0600
~/.local/state/prometheus-postboot-20261020/publication-after-deadline-144138.json,
SHA256 <REDACTED>.
Sólo se leyó Prometheus existente, sin ejecutar backend, publicación, copia,
colector, scrape, probe, API de producto ni POST. No se guardó JSON crudo ni
se enviaron notificaciones de prueba. Registrar la alerta no corrige el fallo;
su resolución sigue pendiente y no se declara el homelab sano.
Reserva PBS registrada: 16:52:57 CEST¶
La consulta limitada de 16:52:57,716826 CEST / 14:52:57,716826 UTC, tras revalidar CT217 en proxmox2, sólo lee las cuatro familias de capacidad ya almacenadas en Prometheus. No consulta PBS ni NAS directamente.
| Datastore | Disponible, bytes | Tamaño, bytes | Disponible, GiB | Porcentaje disponible |
|---|---|---|---|---|
| archive | 200095346688 | 1622233501696 | 186,3533 | 12,33456% |
| main | 166913376256 | 510548377600 | 155,4502 | 32,69296% |
La regla exige al menos 64 GiB y 15%: archive supera 64 GiB, pero incumple 15%. Esto cuantifica la condición de reserva baja registrada como firing a las 16:41; no demuestra agotamiento inmediato ni autoriza prune, borrado o cambio de retención. Main supera ambos umbrales en esta muestra. No se interpreta la capacidad disponible como prueba de integridad o recuperabilidad de las copias.
pbs_capacity_collection_success=1; el contenido fue observado a las
16:50:01 CEST, edad 176,72 s. La consulta directa timestamp(metric) sitúa
las muestras de las cuatro familias a las 16:52:45,323 CEST, edad 12,39 s.
La frescura del scrape y la fecha del contenido se distinguen de la hora de
evaluación de la consulta. No son timestamps de backups completados.
Proyección privada 0600
~/.local/state/prometheus-postboot-20261020/pbs-capacity-145257.json, SHA256
<REDACTED>.
Sin jobs, colectores forzados, probes, POST ni operaciones de almacenamiento.
La siguiente acción es revisar la política de reserva y sus opciones con esta
evidencia; no se ha aplicado limpieza ni se resuelve el fallo de originales.
Déficit para recuperar el 15% y opciones, sin aplicar cambios¶
Sobre la muestra de las 16:52, alcanzar 15% requiere al menos 243335025255 bytes disponibles. Frente a 200095346688 bytes, faltan 43239678567 bytes = 40,27009 GiB de disponibilidad real. No se rebaja el umbral ni se cuenta como utilizable la diferencia entre f_bfree y f_bavail.
Una ampliación también aumenta el denominador: con uso constante y cada byte
nuevo íntegramente utilizable, (disponible+d)/(tamaño+d) >= 0,15 exige al menos
50870210079 bytes = 47,37658 GiB adicionales. Es un mínimo matemático,
no un plan de resize: crecimiento, reserva ext4, tamaño del loop, capacidad NAS
y viabilidad de la operación no están acreditados. No se ha ampliado nada.
La política observada a las 13:15 conserva archive daily7/weekly8/monthly12, distinta de main daily2/weekly1 y de los keep por job PVE. No se sustituye la política de archive por la corta de main. Antes de reducir historia, la siguiente evidencia útil es el último resultado retenido de GC/prune, estado y bytes retirados o pendientes, sin iniciar tareas ni listar snapshots en esta fase.
La documentación oficial de mantenimiento PBS distingue la poda de metadatos de la recuperación de chunks por GC. Chunks compartidos y el periodo de gracia impiden convertir número o tamaño aparente de snapshots en bytes recuperables garantizados. Un GC/prune correcto del 19oct no acredita cuánto se recuperaría hoy. Si no se acredita disponibilidad recuperable suficiente, corresponde preparar capacidad adicional o migración revisada, conservando retención y sin atribuir independencia offsite al loop NAS.
No se fijó una nueva política ni se ejecutaron prune, GC, borrados, ampliaciones o consultas al datastore. La alerta sigue siendo evidencia de reserva baja, no permiso de limpieza ni prueba de agotamiento inmediato.
Historial GC/prune local de archive: lectura 17:59 CEST¶
La fase de las 17:59:40,544827 CEST / 15:59:40,544827 UTC revalidó CT186
running en proxmox y acreditó su rootfs ZFS no compartido: la cadena de dos
dispositivos termina en NVMe con transporte PCIe, no en un archivo, loop ni
transporte de red. El directorio de tareas se abrió por componentes NOFOLLOW,
en el mismo dispositivo y montaje ZFS raíz del CT. Sólo después se leyeron
metadatos de tareas locales; no se abrió NAS, datastore, .gc-status, contenido
de copias ni listas de snapshots. No se invocó una tarea ni una API que actualice
el índice de workers.
Es una nueva selección, no identidad demostrada con la primera lectura parcial de las 17:53. El tail del índice archive abarca 262144 de 443432 bytes, con 48 candidatos GC/prune de archive y cero filas malformadas en ese alcance. El índice active estaba vacío. Ambos índices y los dos logs seleccionados conservaron identidad y stat antes/después. No se afirma inventario histórico exhaustivo ni ausencia global de actividad fuera de esos archivos.
| Tarea seleccionada | Inicio por metadatos, CEST | Fin del índice, CEST | Resultado acreditado |
|---|---|---|---|
| archive prune | 20oct00:00:00 | 20oct00:00:01 | Índice OK y terminal ISO con TASK OK exacto, concordantes |
| archive GC | 20oct00:00:00 | 20oct00:02:31 | UNKNOWN en índice; sin terminal de éxito corroborable en el log |
El log GC estaba estable y completo dentro del presupuesto, 8747 bytes, UTF8, con fecha ISO y zona en la última línea, sin ANSI ni token TASK. Esa morfología no permite convertirlo en OK ni afirmar una terminación correcta. El valor de fin del índice no se presenta como finalización exitosa. El log prune estable, 29918 bytes, sí conserva el terminal exacto y el mismo endtime. El presupuesto de dos logs se consumió; no se abrió un tercer GC anterior.
Bytes retirados y pendientes de GC desconocidos, sin sustituirlos por cero. Prune OK no demuestra 40,27 GiB recuperables ni que GC haya liberado espacio. La proximidad horaria del registro GC al primer reset no acredita causalidad, ni se atribuye a la tarea el watchdog o la reserva baja. No se ejecutaron prune, GC, verify, restore, cambios de retención ni controles del servicio.
La fuente local del diseño de mantenimiento
registra archive GC y prune como daily, a partir de una lectura de las 23:52–23:58
del 19oct. Eso es evidencia histórica del horario declarado, no revalidación de
la configuración runtime a las 17:59 ni garantía del próximo disparo. Los
metadatos de inicio de estas dos tareas son compatibles con medianoche; no se
cambia el horario ni se fuerza una ejecución para obtener un resultado.
La evidencia privada 0600 está en
~/.local/state/pbs-local-gc-prune-reselected-20261020-86wid2i2/projection-private.json,
SHA256 <REDACTED>.
Conserva ID privado, inode, tamaño, hash y stat antes/después; no líneas crudas.
La primera proyección parcial ec38 se conserva intacta: su flag exterior
logs_read=false era inicial y queda corregido a true mediante
~/.local/state/pbs-local-gc-prune-20261020-x5pl104g/projection-correction.json,
SHA256 <REDACTED>.
No se publican identificadores de tareas ni nombres de snapshots.
Seguimiento sobre métricas almacenadas: 20 octubre, 19:23 CEST¶
La consulta acotada de Prometheus local en CT217 a las 19:23:14 CEST, tras revalidar propietario PVE proxmox2/running19:23:12, sólo lee series ya almacenadas. Datos originals19:20:02 y capacidad19:20:01, muestras scrape con edades de unos14s. No se ejecutaron colectores, jobs o POST, ni se contactó el NAS directamente.
Persisten cuatro alertas firing seleccionadas: OriginalsCopyFailed para documents, OriginalsDumpPublicationRequired, PBSDataReserveLow para archive y nas_nfsd_dstate_degraded. No es el número global de alertas. Ningún grupo originals declara copia activa; documentsfailed1 y los otros tres0. Dump configurado enabled1, in_progress0, last_success0; no hay primera publicación acreditada por estas métricas.
Archive conserva186,353GiB disponibles,12,3346%; main155,528GiB,32,7039%. NAS reporta1 de16 nfsd en D-state en muestra de scrape de hace8,3s; no equivale a diagnóstico del origen del bloqueo o a prueba de recuperación. Synccheck mantiene éxito1/fallos0 y push histórico07:00:32; su gauge antiguo redondeado 06:20 no es un nuevo job ni sustituye el fin real06:38:28 acreditado antes. No se cambian retención, umbral, compuertas o estado para conseguir un verde.
Privado0700/0600: ~/.local/state/backup-cached-followup-20261020-649ge92b/.
projection.json SHA256
<REDACTED>;
summary.json SHA256
<REDACTED>.