La aplicación devuelve 500. SSH todavía funciona. df -h muestra 100% en /. El reflejo: rm -rf /var/log/*.log. Eso libera 200 MB; luego el disco se llena en dos horas porque nadie vio que el binlog de MySQL o los registros de Docker se tragaron 40 GB.
Un disco lleno es un síntoma, no un diagnóstico.
Lectura rápida df/du
df -hT: tipo de sistema de archivos, inodos (df -i). du -xh / --max- Depth=1 en el punto de montaje.
Compare df vs total - brecha = archivos abiertos eliminados o montaje oculto.
Culpables frecuentes
| Fuente | Dónde mirar |
|---|---|
| diario | journalctl --uso-disco |
| acoplador | sistema acoplable df -v |
| Registro binario de MySQL | /var/lib/mysql |
| Aplicaciones | /var/log, almacenamiento/registros |
| Núcleos | /var/crash, volcados de núcleo |
| Copias de seguridad locales | /copia de seguridad, /tmp |
Línea de tiempo: find /var -mtime -1 -size +100M.
Eliminado pero abierto
lsof +L1 | grep eliminado: clásico después de una rotación fallida o un registro grande eliminado sin HUP.
Solución: recargar la aplicación, reiniciar php-fpm/mysql, no solo rm.
Acciones de emergencia ordenadas
- Identifique los 3 archivos principales.
- Registro de vacío si > 500 MB.
- Truncar el registro conocido (copiar truncar) frente a eliminar.
- Docker plum después de la lista de volúmenes.
- Amplíe el volumen de la nube si es posible antes de la cirugía.
##Prevención sostenible
Monitoreo de inodo + espacio. Logrotate probado. SystemMaxUse= diario. Docker --log-opt tamaño máximo = 10 m. Runbook de alerta vinculado al montaje correcto.
Runbook 15 minutos
Minuto 0–3: df -hT + df -i + du -xh / --max-profundidad=1.
Minuto 3 a 6: journalctl --disk-usage, docker system df si corresponde.
Minuto 6–9: lsof +L1 | head si df/du brecha.
Minuto 9 a 12: acción específica (aspirar, truncar log roté, podar los volúmenes de Docker enumerados).
Minuto 12-15: verificación df + alerta de confirmación de monitoreo + ticket de causa raíz.
Prohibido: rm -rf sin los 3 directorios principales identificados. Obligatorio: nota post-mortem si el impacto de la picana es >80%.
Post-mortem típico
Cronograma: alerta 80% ignorada → 95% → 100% → interrupción. Causa raíz: el registro de depuración de la aplicación se activó el viernes sin rotación. Acción: producción de nivel de registro + alerta 85 % + runbook.
Capacidad: el crecimiento previsto registra MB/día × retención.
Disco de escalado automático en la nube, si está disponible: script de crecimiento del sistema de archivos después del cambio de tamaño.
Instantáneas automáticas diarias en la nube sin ciclo de vida: acumulación de instantáneas = disco principal lleno indirectamente: revisión de instantáneas de políticas.
Cola postfix/exim de correo bloqueada, disco lleno: enorme trabajo pendiente para recuperar: monitorear la métrica de longitud de la cola.
Crecimiento predecible
Registros de acceso ×10 durante la promoción: rotación previa al aprovisionamiento temporal cada hora o actualización del disco antes de la campaña.
Caducidad del binlog de MySQL: expire_logs_days o max_binlog_size - binlog olvidado = disco lleno garantizado en condiciones de escritura intensa.
Las instantáneas ZFS/btrfs cuentan el espacio; no realice instantáneas de un disco que ya esté lleno en un bucle.
Resumen operativo
El disco completo en la producción de Linux casi siempre es predecible con alertas 80/90, rotación de registros probada y conocimiento del consumidor (diario, Docker, binlog, copias de seguridad locales). En emergencia: diagnosticar con df, du, lsof antes de rm.
Nube: expandir el volumen es más seguro que una purga ciega si el crecimiento es legítimo. Autopsia obligatoria si hay impacto en el cliente: a menudo se activa el registro de depuración olvidado.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Post-mortem
Registro de depuración el viernes sin rotación. El almacenamiento efímero de K8 mata los pods antes de que el nodo se llene.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Decide y avanza sin puntos ciegos
- Runbook 15 minutos —
df -hT,df -i,dunivel superior, journalctl --disk-usage, docker system df. - Buscar archivos eliminados abiertos —
lsof +L1si hay diferencia df/du. - Acción específica: aspirar el registro, truncar el registro roto, podar los volúmenes de Docker enumerados; nunca rm -rf sin los 3 directorios principales.
- Alerta sobre el derivado: crecimiento de GB/día, no solo un umbral del 90%.
- Autopsia si hay impacto en el producto: causa raíz documentada la misma semana.
Supervise el disco y el inodo en VPS a través del comparador y el directorio.
Preguntas frecuentes
¿df dice 100% pero no encuentra nada?
Los archivos eliminados aún están abiertos por un proceso (eliminados pero abiertos). lsof +L1 o reinicie el servicio en cuestión.
¿Qué purgar primero en caso de emergencia?
journalctl --vacuum, registros viejos y podridos, /tmp: nunca /var/lib sin identificarse (DB, Docker).
Docker a menudo llena ¿dónde?
/var/lib/docker/overlay2, registros de archivos json no limitados, volúmenes huérfanos.
¿Cómo prevenir?
Alertas del 80/90%, logrotate, límite de diario, el registro de Docker opta por el tamaño máximo.
Siguiente disco 100%: ejecute du y lsof +L1 antes de cualquier rm; su futuro se lo agradecerá.