Skip to content

Telemetría de caché y diagnóstico UPS NAS — 2026-10-19

Autorización: aplicar mejoras del homelab con agentes simultáneos. Este trabajo conserva la caché writethrough; no ejecuta scrub, benchmark, escaneo de datos, mensajes dmsetup ni cambios UPS/servicios de apagado.

Telemetría aplicada sin nueva programación

Se incorpora /usr/local/bin/cache-metrics.py al final del colector existente /usr/local/bin/nfsd-dstate-collect.sh. La tarea original /etc/cron.d/nfsd-dstate-collect sigue siendo la única: cada minuto como monxas. Se ha conservado íntegramente el contenido anterior del colector y añadido la invocación Python. No se ha creado cron, daemon ni plataforma.

Fuentes versionadas:

  • scripts/nas/nfsd-dstate-collect.sh
  • scripts/nas/cache-metrics.py
  • scripts/nas/tests/test_cache_metrics.py

El helper solo consulta dmsetup status/table --target cache y archivos /sys/dev/block/<major:minor>/stat. Publica atómicamente en /var/lib/node_exporter/textfile/nas_cache.prom con permisos 0644:

  • Contadores de hits/misses de lecturas y escrituras, promociones y expulsiones.
  • Bloques usados/totales, tamaño, bloques/bytes dirty, modo/política, metadatos read-only y needs_check.
  • Bytes/operaciones/tiempos acumulados por capa lógica: origen, caché y metadatos.
  • Timestamp de muestra, éxito y duración. Error de consulta/parsing publica success=0, sin disfrazarlo de caché limpia; ausencia de caché publica present=0.

Estas capas no equivalen a peticiones de archivos ni a latencia percibida por las aplicaciones. Los tiempos pueden solaparse y las promociones añaden E/S. Node exporter ya recoge los discos físicos; combinar ambos datos en consultas. Los contadores se reinician con el dispositivo/arranque: usar rate/increase.

Validación y muestra

  • Ocho pruebas pasan: status real, default writeback/needs_check, target Fail, sectores siempre de 512 bytes, roles de la tabla, escritura atómica, error de consulta y distinción caché ausente/consulta fallida.
  • Compilación Python y sintaxis Bash correctas en el NAS.
  • promtool check metrics dentro del Prometheus existente de CT217: salida 0.
  • Scrape real de http://192.168.0.XXX:9100/metrics: nas_cache_collect_success 1, node_textfile_scrape_error 0, nfsd_threads_dstate 0, modo writethrough/smq, dirty=0.
  • La tarea cron existente actualizó el timestamp después de la ejecución inicial.
  • La API Prometheus, una vez recuperado pmx-51, devuelve success y nas_cache_collect_success=1 para host=tnas, instance=nas.lan:9100, job=tnas-f4423. Ingestión central acreditada. Durante el arranque había respondido HTTP503 temporalmente; esa condición ya no persistía al verificar.

Muestra: read hits 34.794 y misses 19.808 (~63,7 % por operaciones desde el reinicio del contador). El porcentaje difiere del 82,7 % de la revisión previa: la carga cambia. Ninguno representa un porcentaje de aceleración ni un A/B. No se cambió el modo ni se retiró la caché para medir.

Consultas útiles, con carga normal y una ventana representativa:

rate(nas_cache_read_hits_total[15m])
/
(rate(nas_cache_read_hits_total[15m]) + rate(nas_cache_read_misses_total[15m]))

rate(nas_cache_layer_read_bytes_total{role="origin"}[15m])
rate(nas_cache_layer_busy_seconds_total{role="origin"}[15m])

1000 * rate(nas_cache_layer_read_seconds_total{role="origin"}[15m])
/ rate(nas_cache_layer_read_operations_total{role="origin"}[15m])

time() - nas_cache_collect_timestamp_seconds
nas_cache_collect_success
nas_cache_dirty_bytes

Una ventana sin lecturas puede dar NaN en ratios: no representa fallo ni 0 % de eficacia. La tercera consulta calcula tiempo medio por petición de esa capa, no un percentil ni latencia de usuario. No decidir retirada por un ratio aislado. Formato de status y semántica: documentación dm-cache del kernel.

Rollback: restaurar /usr/local/bin/nfsd-dstate-collect.sh.pre-cache-metrics-20261019 sobre el colector. Si se retira el helper, retirar también nas_cache.prom para no dejar datos obsoletos expuestos. No precisa reinicio y el cron existente se conserva.

UPS: diagnóstico nativo, sin activación

La conectividad NUT hacia UPS@192.168.0.XXX funciona según la revisión central; eso no demuestra que exista monitor de apagado activo ni que el NAS esté físicamente alimentado por el SAI.

Verificado en NAS:

  • /etc/ups_v2.config: enabled=false, type=0, server_addr vacío, enabled_listen=false; time_conf time_mode=0/secs=0.
  • ups-monitor.service está masked; no se ha desmascarado ni arrancado.
  • La configuración NUT histórica MODE=netserver no acredita un servicio activo.
  • ter_ups -h acepta -event y -arg. Se resolvió su dispatcher de lectura: ter_ups -event get_ups -arg '{}' devuelve ups_connected=false, is_usb_device=false y los flags anteriores. No se mostraron secretos.
  • La UI instalada consume GET /ups/ y POST /ups/set. Expone tipos USB=1, SNMP=2 y servidor TNAS=3; permite espera 1/5/10/30 minutos, batería baja y sincronización con servidor.
  • El campo servidor TNAS valida en frontend una URL HTTP(S) con puerto, con ejemplo :8181. Por ello no está validado que type3 acepte directamente un NUT genérico en pmx-50; revisar protocolo y autenticación antes de activarlo.
  • En el ejecutable nativo, el setter recorre Enable/Disable y SaveConf; la ruta enableServer resetea firewall/schedule/upsd/upsmon antes de configurar y reiniciar componentes. No usarlo como si solo guardara un JSON inocuo.

No se ejecutó set_ups ni se cambió /etc/ups_v2.config, NUT, máscaras o apagados. Antes de completar esta mejora: confirmar físicamente NAS y equipos de red necesarios en el SAI, acordar orden de apagado respecto a invitados/NFS y servidor UPS50, validar persistencia TOS/credenciales y compatibilidad del mecanismo. Solo después activar monitor apropiado y verificar conexión/registro sin simular batería agotada ni provocar apagados. La mera respuesta de upsc no cierra esta tarea.