Saludos amigos, hoy os traigo una de esas entradas de troubleshooting que seguramente nos echemos las manos a la cabeza. Llevaban unas horas sin poder acceder a mi instancia de Grafana, el error que aparecía era “Error while signing in user”
Vamos ha comenzar con el troubleshooting de la incidencia. Lo primero que hacemos es comprobar si tenemos suficiente espacio en disco, algo muy común en instancias donde estamos mandando miles de métricas, en mi caso recordar que tengo todo en uno: InfluxDB, Loki, etc.
¿Cómo comprobar el espacio en disco en Linux?
Muy sencillo realmente, al menos el primer vistazo a todos nuestros puntos de montaje, usaremos el típico df -h:
df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1.2G 1.4M 1.2G 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 137G 133G 0 100% / tmpfs 5.9G 712K 5.9G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/nvme0n1p2 974M 251M 656M 28% /boot tmpfs 1.2G 4.0K 1.2G 1% /run/user/1000
Si queremos conocer un poco más en detalle sobre qué tiene cada directorio dentro de un punto de montaje en concreto, por ejemplo, mi /, usaremos el siguiente comando:
du -h / 2>/dev/null | grep '[0-9\.]\+G'
El resultado es el siguiente. Mirad que locura en algunas de las carpetas:
root@tig-monitor:/home/oper# du -h / 2>/dev/null | grep '[0-9\.]\+G' 1.6G /etc/pihole 1.6G /etc 2.5G /snap 18G /root 3.1G /usr/lib 4.6G /usr 1.3G /var/lib/snapd 46G /var/lib/influxdb 47G /var/lib 1.7G /var/log/journal 51G /var/log 98G /var 5.7G /tmp/loki/chunks 5.8G /tmp/loki 5.8G /tmp 136G /
Vamos a indagar por los ficheros más grandes, dentro de /var/log que tiene más de 50GB al final para saber qué sucede:
find /var/log -type f -exec du -h {} \; | sort -h
El resultado será algo tal que así:
106M /var/log/veeam_backup_and_replication.log 249M /var/log/runecast.log 365M /var/log/cloudflare.log 1.1G /var/log/veeamaws.log 1.2G /var/log/veeamazure.log 2.1G /var/log/wordpress-stats.log 2.3G /var/log/unifi.log 4.9G /var/log/veeamvbo.log 6.1G /var/log/veeamEM.log 6.7G /var/log/ontap.log 25G /var/log/syslog.1
Solución final
Ahora qué conocemos que carpetas, y que ficheros están ocupando tantísimo espacio, podemos proceder a hacer un rm de esos ficheros que no son tan importantes. Una vez borrados, miramos qué tal se ve ahora las particiones:
df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1.2G 1.4M 1.2G 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 137G 85G 46G 65% / tmpfs 5.9G 712K 5.9G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/nvme0n1p2 974M 251M 656M 28% /boot tmpfs 1.2G 4.0K 1.2G 1% /run/user/1000
Bueno, pues ¡ya estaría! Reiniciamos, y el problema de Grafana, así como muchos otros seguramente en InfluxDB, Loki, etc. quedan resueltos.
Es irónico que mi sistema de monitorización, no haya yo estado más atento sobre el espacio en disco sobre el mismo, algo importante a tener en cuenta para el futuro.
asasas
Leave a Reply