Cuando el disco empieza a trabajar sin descanso, averiguar qué proceso está detrás puede obligar a encadenar herramientas como iostat, iotop, lsof, df, smartctl o lsblk. Diskwatch intenta concentrar ese diagnóstico en una única interfaz de terminal escrita en Rust, leyendo directamente la información que ya expone el sistema operativo y relacionando actividad de archivos, tasas de entrada/salida y descriptores abiertos para señalar qué procesos podrían estar detrás del problema. No instala agentes en segundo plano, no mantiene una base de datos y no envía telemetría a un servicio externo.
Las claves de Diskwatch en 30 segundos
- Diskwatch es una TUI de diagnóstico de almacenamiento para Linux y macOS escrita en Rust.
- Combina métricas del kernel, actividad de archivos y descriptores abiertos para localizar procesos relacionados con escrituras intensivas.
- Puede funcionar en una vista Lite de 80×24 pensada para SSH y paneles de tmux.
- No utiliza daemon, no persiste métricas y trabaja en modo de solo lectura.
- Incluye información sobre discos, volúmenes, latencia, SMART, capacidad y archivos más activos.
La idea parte de una situación habitual para administradores de sistemas: el indicador de actividad del disco no para, la carga aumenta o un volumen empieza a responder lentamente, pero todavía no está claro si el responsable es una base de datos, un proceso de logs, una copia de seguridad, un compilador o alguna tarea inesperada.
Diskwatch se presenta precisamente como la herramienta que se abre antes de empezar a recorrer varias utilidades independientes.
El proyecto es hermano de NetWatch y SysWatch y mantiene una interfaz y atajos similares. Su enfoque es local: analiza una única máquina y no pretende sustituir sistemas de observabilidad de flotas ni plataformas de monitorización persistente.
Une /proc, inotify y descriptores abiertos para buscar al responsable
Una de las funciones más interesantes aparece en la vista Hot Files.
En Linux, Diskwatch utiliza inotify para detectar archivos con actividad y combina esa información con datos procedentes de /proc. Para conocer qué procesos están realizando entrada y salida puede consultar /proc/<pid>/io, mientras que /proc/<pid>/fd permite observar qué archivos mantiene abiertos cada proceso.
El programa cruza ambas fuentes.
Esto es importante porque inotify por sí mismo no proporciona directamente el PID del proceso responsable de cada evento. Diskwatch no puede afirmar que un determinado proceso ejecutó exactamente una escritura concreta basándose únicamente en ese evento.
En su lugar hace una inferencia.
Si un archivo está registrando mucha actividad y un proceso que muestra una tasa elevada de escritura mantiene ese archivo abierto, Diskwatch puede asociarlos y mostrar ese proceso como probable responsable.
El propio proyecto explica esta limitación de forma explícita. La atribución es un join entre información de actividad y archivos abiertos, no una medición directa por evento.
Eso introduce dos límites importantes.
El muestreo se realiza cada dos segundos, por lo que un proceso que abra un archivo, escriba y lo cierre entre dos muestras puede pasar inadvertido. Compiladores, operaciones rápidas de Git o algunos gestores de paquetes son ejemplos especialmente difíciles.
Además, sin privilegios elevados el programa solo puede leer toda la información disponible para el usuario que lo ejecuta. Si otros procesos pertenecen a usuarios diferentes, parte de esa atribución puede quedar incompleta.
Para obtener un PID exacto asociado a cada evento harían falta mecanismos como fanotify con FAN_REPORT_PID o trazado mediante eBPF, normalmente con mayores privilegios. Diskwatch ha elegido no depender de ellos para su funcionamiento básico.
Ese compromiso encaja con su filosofía: diagnóstico rápido sin convertir la herramienta en un agente privilegiado permanente.
Una vista Lite que cabe en 80×24
Aunque Diskwatch dispone de varias pantallas, uno de sus modos más prácticos para administradores remotos es Lite:
diskwatch --liteEstá diseñado para funcionar en un terminal de 80 columnas por 24 líneas, un tamaño que sigue siendo habitual en sesiones SSH, consolas reducidas y divisiones de tmux.
La vista resume las métricas esenciales: lectura y escritura, capacidad y archivos con mayor actividad.
Al seleccionar un archivo y pulsar Enter, puede abrirse un bloque adicional donde aparece el proceso que lo mantiene abierto. Si la terminal supera las 99 columnas, esa información pasa directamente a una columna PROCESS.
Para quien necesite más información existe también el modo Dense:
diskwatch --denseEn este caso se muestran seis bloques simultáneamente:
| Bloque | Información |
|---|---|
| IO | Lectura, escritura, IOPS, utilización, latencia y percentiles |
| Devices | Actividad y características por dispositivo |
| Latency | Histograma de latencias |
| Volumes | Capacidad y proyección de tiempo hasta llenado |
| SMART | Salud, desgaste, temperatura y escrituras |
| Files | Archivos más activos y procesos asociados |
La interfaz completa añade ocho pestañas para separar información sobre dispositivos, volúmenes, sistemas de archivos, entrada/salida, SMART, archivos activos e incidencias detectadas.
En la práctica Diskwatch intenta reunir datos que normalmente obligarían a consultar varias herramientas distintas.
No todos los percentiles son realmente percentiles de cada operación
El proyecto también hace algo poco frecuente en herramientas pequeñas de terminal: documenta qué métricas son exactas y cuáles son aproximaciones.
Por ejemplo, muestra p50 y p99 de latencia, pero en Linux no obtiene la latencia individual de cada operación de bloque mediante eBPF.
En su lugar utiliza muestras periódicas.
Cada intervalo de 200 milisegundos calcula una latencia media y coloca el número de operaciones de ese intervalo dentro de uno de los siete grupos del histograma. Esto permite detectar periodos sostenidos de lentitud, pero no equivale a medir un p99 real de todas las operaciones individuales.
El proyecto lo reconoce expresamente.
Para obtener un percentil real por operación en Linux haría falta una herramienta de trazado como biolatency basada en eBPF. En macOS existirían también limitaciones relacionadas con las interfaces que expone IOKit.
Algo similar sucede con la utilización de dispositivos.
Linux puede calcularla mediante /proc/diskstats, pero macOS no expone directamente un contador equivalente de tiempo ocupado. En ese sistema Diskwatch muestra otras métricas y evita inventar el dato.
Este tipo de diferencias importa especialmente cuando se utiliza una TUI como herramienta de diagnóstico. Una cifra visualmente precisa puede dar una falsa sensación de exactitud si en realidad deriva de una aproximación.
Diskwatch opta por mostrar -- cuando una métrica no puede medirse en una plataforma determinada.
También vigila capacidad, RAID y SMART
La herramienta no se limita a descubrir quién está escribiendo.
En Linux obtiene estadísticas de dispositivos mediante /proc/diskstats, información de hardware desde /sys/block, datos de RAID mediante /proc/mdstat y estado de los sistemas de archivos montados.
Puede mostrar modelos, números de serie, firmware, tasas de lectura y escritura, operaciones por segundo, solicitudes en curso y utilización.
Para SMART utiliza smartctl cuando está instalado. Sin esta dependencia todavía puede ofrecer información más básica, pero no toda la tabla de atributos.
En macOS recurre a utilidades disponibles en el sistema como ioreg, diskutil y system_profiler.
Diskwatch añade además una estimación de cuánto tiempo falta para llenar un volumen. Para ello observa el crecimiento durante una ventana de diez minutos y proyecta la tendencia. Si el volumen está estable o reduciendo su uso, la herramienta no muestra una estimación artificial.
No pretende convertirse en un sistema de predicción de capacidad a largo plazo. La cifra está pensada como ayuda inmediata: detectar que un proceso está generando datos con suficiente velocidad como para llenar una partición en horas puede ser más útil durante una incidencia que conocer únicamente el porcentaje ocupado.
Sin daemon, base de datos ni backend
Diskwatch define claramente varios objetivos que quedan fuera del proyecto.
No es una solución para monitorizar múltiples servidores.
No es un daemon.
No almacena métricas en una base de datos.
No elimina archivos.
No crea copias de seguridad.
Y tampoco pretende funcionar como benchmark.
La herramienta observa el estado actual del sistema y desaparece cuando el usuario cierra el programa.
Ese planteamiento puede resultar atractivo en servidores donde instalar un agente de observabilidad completo no compensa o donde simplemente se necesita responder rápidamente a una pregunta concreta.
También reduce la superficie operativa: no existe un servicio permanente que mantener, un backend que desplegar ni credenciales para enviar datos a una plataforma externa.
La contrapartida es evidente. Cuando Diskwatch no está ejecutándose, no existe histórico al que volver.
Si el problema ocurrió durante la madrugada y terminó antes de que alguien se conectara al servidor, la herramienta no podrá reconstruirlo.
Instalación con Homebrew, Cargo, Nix o Arch
El proyecto ofrece varias formas de instalación:
brew install diskwatchPara usuarios de Rust:
cargo install diskwatchTambién dispone de paquetes para Nix y Arch Linux, además de binarios precompilados para Linux y macOS en arquitecturas x86_64 y ARM64.
En Linux existen además versiones estáticas basadas en musl, pensadas para reducir dependencias en el sistema destino.
La configuración es opcional. Diskwatch puede ejecutarse sin ningún archivo adicional, aunque permite generar uno con:
diskwatch --write-configDesde ahí pueden definirse el tema visual, la vista inicial, intervalos de SMART, columnas y rutas observadas.
Para limitar la monitorización de archivos a una ubicación concreta puede utilizarse:
diskwatch --watch ~/srco añadir una ruta manteniendo las predeterminadas:
diskwatch --watch-add /srv/dataEn Linux cada directorio observado recursivamente consume una entrada de inotify, por lo que apuntar la herramienta hacia árboles con una gran cantidad de directorios puede alcanzar fs.inotify.max_user_watches. Diskwatch detecta esta situación y muestra un mensaje específico en lugar del genérico No space left on device, que podría hacer pensar equivocadamente en un problema de almacenamiento.
Diskwatch está publicado bajo licencia MIT y su código se encuentra disponible en GitHub.
Su interés no está tanto en sustituir individualmente a iostat, iotop, lsof o smartctl, que siguen ofreciendo información mucho más específica, como en reducir los primeros minutos de diagnóstico.
Cuando un servidor empieza a escribir sin parar, la primera pregunta rara vez necesita una plataforma completa de observabilidad.
Muchas veces es bastante más sencilla: qué archivo está recibiendo escrituras y qué proceso podría tenerlo abierto.
Diskwatch intenta responderla desde una sola terminal.
