Mise en garde

Cet article a été écrit par des débutants Linux. Cet article ne doit être utilisé qu'à titre de référence, car des données importantes peuvent être perdues.

environnement

CentOS7 / Apache2.4 / PHP5.4 / MariaDB5.5 / Zabbix Server4.4.6 / VPS 1G de Sakura

Début

Normalement, la surveillance des serveurs est mon travail principal, Dans le cadre de mes études, j'ai personnellement mis en place un serveur Zabbix.

Une alerte comme celle-ci de ce serveur Zabbix ...

Problem started at hh：mm：ss on yyyy.mm.dd Problem name: /: Disk space is critically low (used > 90%) Host: Zabbix server Severity: Average

Certaines informations sont masquées

Comme vous pouvez le voir à la lecture, il semble que l'utilisation du disque du serveur Zabbix qui a été laissé sans surveillance a dépassé 90%.

En fait, une alerte a été émise lorsqu'elle a dépassé 80%, mais je l'ai complètement laissée.

C'est pourquoi je vais vérifier le graphique pour le moment.

Certes, le disque est serré, donc je vais me connecter au serveur et enquêter.

Enquête

[root@hostname user]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda4        45G   40G  2.7G  94% /
devtmpfs        484M     0  484M   0% /dev
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           496M   51M  446M  11% /run
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/vda2       477M  103M  345M  23% /boot
tmpfs           100M     0  100M   0% /run/user/1000

Vérifiez l'espace disque disponible avec la commande df Ajustez l'unité avec l'option -h

Pour le moment, il ne semble pas y avoir d'espace libre dans /.

[root@hostname user]# du -sh /*
0       /bin
101M    /boot
0       /dev
34M     /etc
84K     /home
0       /lib
0       /lib64
16K     /lost+found
4.0K    /media
4.0K    /mnt
8.0K    /opt
0       /proc
68K     /root
51M     /run
0       /sbin
4.0K    /srv
0       /sys
48K     /tmp
1.6G    /usr
24G     /var

Vérifiez l'espace disque utilisé par le répertoire de fichiers avec la commande du Afficher uniquement la pièce requise avec l'option -s Ajusté pour une visualisation facile avec l'option -h

Pour le moment, il semble que la cause soit / var, qui est la plus utilisée.

[root@hostname user]# du -sh /var/*
4.0K    /var/account
4.0K    /var/adm
120M    /var/cache
4.0K    /var/crash
20K     /var/db
8.0K    /var/empty
4.0K    /var/games
4.0K    /var/gopher
12K     /var/kerberos
311M    /var/lib
4.0K    /var/local
0       /var/lock
27G     /var/log
0       /var/mail
4.0K    /var/nis
4.0K    /var/opt
4.0K    /var/preserve
0       /var/run
116K    /var/spool
32K     /var/tmp
12K     /var/www
4.0K    /var/yp

J'utilise la commande du de la même manière, mais cette fois j'ai enquêté sur / var, et par conséquent, il semble que la cause soit / var / log.

[root@hostname user]# du -sh /var/log/*
4.0K    /var/log/anaconda
39M     /var/log/audit
0       /var/log/boot.log
12K     /var/log/boot.log-20200427
137M    /var/log/btmp
222M    /var/log/btmp-20200501
4.0K    /var/log/chrony
128K    /var/log/cron
164K    /var/log/cron-20200419
160K    /var/log/cron-20200426
160K    /var/log/cron-20200503
160K    /var/log/cron-20200510
36K     /var/log/dmesg
2.7M    /var/log/httpd
40K     /var/log/lastlog
0       /var/log/maillog
0       /var/log/maillog-20200426
4.0K    /var/log/maillog-20200503
0       /var/log/maillog-20200510
20K     /var/log/mariadb
236K    /var/log/messages
276K    /var/log/messages-20200419
272K    /var/log/messages-20200426
344K    /var/log/messages-20200503
280K    /var/log/messages-20200510
4.0K    /var/log/qemu-ga
4.0K    /var/log/rhsm
22M     /var/log/sa
55M     /var/log/secure
59M     /var/log/secure-20200419
44M     /var/log/secure-20200426
64M     /var/log/secure-20200503
63M     /var/log/secure-20200510
0       /var/log/spooler
0       /var/log/spooler-20200426
0       /var/log/spooler-20200503
0       /var/log/spooler-20200510
20K     /var/log/tuned
48K     /var/log/wtmp
4.0K    /var/log/yum.log
23G     /var/log/zabbix

Examinez la hiérarchie suivante, la cause semble être / var / log / zabbix (serveur Zabbix en premier lieu). La capacité utilisée est clairement différente.

Contre-mesures

Maintenant que nous connaissons la cause, nous allons envisager des contre-mesures. Après enquête, il semble que la commande tmpwatch puisse être utilisée.

[root@hostname user]# yum -y install tmpwatch

Pour le moment, installez la commande tmpwatch avec la commande yum.

[root@hostname user]# tmpwatch -d -m 720 /var/log/zabbix

Supprimer les anciens fichiers avec la commande tmpwatch Exclure la direction avec l'option -d Spécifiez l'heure avec -m

S'il n'est pas mal identifié, il devrait supprimer les fichiers qui n'ont pas été mis à jour depuis plus de 720 heures.

Allez à nouveau vérifier le graphique.

Pour le moment, il semble que la capacité du disque se soit un peu améliorée. Après avoir exécuté la commande, j'ai également confirmé une alerte indiquant que l'utilisation du disque à 90% était inférieure à 90%, donc pour le moment c'était un succès ... (Bien que pas moins de 80%)

Postscript

J'ai oublié l'important, mais je n'ai pas redémarré. Cliquez ici pour le résultat du redémarrage

Il semble que l'ancien fichier journal a été supprimé correctement.

Pour le moment, c'est un soulagement