Pourquoi l'espace n'est-il pas libéré après la suppression d'un fichier ?

Avez-vous déjà rencontré une situation où des fichiers ont été supprimés mais l'espace n'a pas été libéré dans un environnement Linux ? Ce court article présentera un scénario de ce problème et la solution correspondante.

L'un de nos serveurs d'applications, le système d'exploitation est Red Hat Linux, l'alarme de surveillance, l'utilisation du système de fichiers /opt/applog dépasse le seuil, la capacité globale est de 50 Go, mais la capacité réelle du fichier est de 20 Go, quel est l'espace restant de 30 Go ?

Nous savons que dans l'environnement Linux, tout existe sous la forme d'un fichier. Le système attribue un descripteur de fichier à chaque application en arrière-plan. Il fournit un descripteur de fichier pour l'interaction entre l'application et le système d'exploitation. interface est un fichier, il prendra de la place. À ce stade, vous pouvez utiliser la commande lsof, qui peut lister les fichiers actuellement ouverts par le système.

>lsof
COMMAND      PID      USER   FD      TYPE    DEVICE  SIZE/OFF      NODE NAME
...
filebeat  111442   app  1r      REG     253,3 209715229   1040407 /opt/applog/E.20171016.info.012.log
filebeat  111442   app  2r      REG     253,3 209715254    385080 /opt/applog/E.20171015.info.001.log (deleted)
...

La signification de chaque champ dans l'en-tête est la suivante :

COMMANDE : le nom du processus
PID : identifiant du processus
UTILISATEUR : propriétaire du processus
FD : Descripteur de fichier, l'application identifie le fichier grâce au descripteur de fichier. Tels que cwd, txt, etc.
TYPE : type de fichier, tel que DIR, REG, etc.
DEVICE : Précisez le nom du disque
TAILLE : La taille du fichier
NODE : nœud d'index (identification du fichier sur le disque)
NOM : Le nom exact du fichier ouvert

On peut voir que dans certaines lignes, NOM est marqué (supprimé)

/opt/applog/E.20171015.info.001.log (supprimé)

Cela signifie que le fichier a été supprimé, mais que le handle du fichier ouvert n'a pas été fermé. Regardez le nom de la COMMANDE est filebeat et le propriétaire du processus USER est app. Il s'agit de notre processus de collecte de journaux. a activé le processus filebeat.

Présentation de la plateforme de collecte de logs

La plateforme de journalisation open source traditionnelle, ELK, se compose de trois outils open source : ElasticSearch, Logstash et Kiabana, parmi lesquels :

• Elasticsearch est un moteur de recherche distribué open source, distribué, sans configuration, découverte automatique, partage d'index automatique, mécanisme de copie d'index, interface de style reposant, sources de données multiples, chargement de recherche automatique, etc.
• Logstash est un outil de collecte open source qui peut collecter, filtrer les journaux et les stocker pour une utilisation ultérieure.
• Kibana est un outil Web graphique open source qui fournit une interface Web conviviale pour l'analyse des journaux pour Logstash et ElasticSearch, et peut regrouper, analyser et rechercher des journaux de données importants.

Schéma de déploiement commun, comme indiqué ci-dessous

Qu'est-ce que filebeat mentionné ci-dessus ? Quel est le lien avec ELK ?

Il y a une introduction du grand expert Rao Chenlin (auteur de "ELKstack Authoritative Guide") sur Zhihu, qui est très perspicace et citée sur https://www.zhihu.com/question/54058964/answer/137882919

Étant donné que logstash est géré par jvm et consomme beaucoup de ressources, l'auteur a ensuite utilisé golang pour écrire un transitaire de logstash léger avec moins de fonctions mais une faible consommation de ressources. Cependant, l'auteur n'est qu'une seule personne. Après avoir rejoint

En termes simples, filebeat est l'agent de processus pour la collecte des journaux, responsable de la collecte des fichiers journaux des applications.

Pour mon problème ci-dessus, la raison pour laquelle il existe un grand nombre de descripteurs de fichiers (supprimés) et non publiés est que, comme l'espace disque est très limité, une tâche a été temporairement ajoutée pour supprimer les journaux il y a 12 heures toutes les heures. En d'autres termes, la tâche planifiée supprimera automatiquement certains fichiers que filebeat ouvre à ce moment-là, de sorte que ces fichiers deviennent des fichiers non publiés, donc les fichiers réels sont supprimés, mais l'espace n'est pas libéré.

Solution 1 :

Afin de libérer rapidement l'espace occupé, la méthode la plus directe consiste à tuer le processus -9 filebeat, moment auquel l'espace sera libéré. Mais ce n'est pas une solution fondamentale. Les tâches planifiées supprimeront également ces fichiers ouverts par filebeat, provoquant ainsi une saturation de l'espace.

Solution 2 :
Le fichier de configuration de Filebeat, filebeat.yml, a en fait deux paramètres :

• close_older : 1h
  Description : Close old ferme le gestionnaire de fichiers pour lequel n'a pas été modifié depuis plus longtemps que close_older. Des chaînes de temps telles que 2h (2 heures), 5m (5 minutes) peuvent être utilisées.

Autrement dit, si un fichier n'a pas été mis à jour dans un certain laps de temps, le descripteur de fichier surveillé sera fermé. La valeur par défaut est d'une heure.

• force_close_files : faux
  Remarque : Cette option ferme un fichier dès que le nom du fichier change. Cette option de configuration est recommandée sous Windows uniquement. Filebeat garde les fichiers qu'il lit ouverts. Cela peut entraîner des problèmes lorsque le fichier est supprimé, car le fichier ne le sera pas. être complètement supprimé jusqu'à ce que Filebeat ferme également la lecture. Filebeat ferme le gestionnaire de fichiers après ignore_older. Pendant ce temps, aucun nouveau fichier portant le même nom ne peut être créé. L'activation de cette fonctionnalité peut en revanche entraîner une perte de données lors de la rotation des fichiers. Il peut arriver qu'après la rotation du fichier, le début du nouveau fichier soit ignoré, car la lecture commence à la fin. Nous vous recommandons de laisser cette option sur false mais de réduire la valeur ignore_older pour libérer les fichiers plus rapidement.

C'est-à-dire que lorsque le nom du fichier change, y compris le changement de nom et la suppression, un fichier sera automatiquement fermé.

En combinant ces deux paramètres, selon les exigences de l'application, si un fichier n'est pas mis à jour dans les 30 minutes, le handle doit être fermé. Si le fichier est renommé ou supprimé, le handle doit être fermé

.

close_older : 30 m
force_close_files : vrai

Il peut répondre aux exigences de base de la collecte des journaux filebeat et de la suppression régulière des fichiers historiques.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!