Comment surveiller BTRFS FileSystem RAID pour des erreurs?
J'ai vu une certaine documentation sur un démon pouvant exécuter un programme/script pour divers événements BTRFS, mais je ne le trouve plus.
Comment puis-je avoir un script/programme être exécuté sur une panne de lecteur pour un tableau BTRFS RAID1? Je souhaite exécuter un script sur toute erreur d'agir comme un avertissement précoce pour un lecteur potentiellement défaillant, mais la défaillance réelle du lecteur est la plus importante. Je voudrais démonter le système de fichiers à ce moment-là (si ce n'est pas ce que BTRFS fait de toute façon) et définir une alarme.
Il ne semble pas y avoir de démon ou d'utilité qui rapporte officiellement les événements BTRFS pour la manipulation de l'utilisateur. L'alternative la plus proche consiste à surveiller le journal du système pour les messages de BTRFS et à réagir en conséquence.
Le lien ci-dessus fournit plus de détails pour la configuration d'un script (sec package sur Debian ou SEC ) Conçu pour la surveillance du journal à usage général pour agir sur Messages de journal inattendus concernant BTRFS. Cela dépend également d'avoir un gommage régulier du système de fichiers pour vérifier pour la pourriture de bit et émettre des entrées de journal comme une mesure préventive. Vous trouverez ci-dessous un extrait spécifique au script sec:
Comment configurer Sec, corrélateur d'événement pour signaler les erreurs de système de fichiers BTRFS ou les avertissements
Après avoir installé sec.pl (apt-get Installer sec sur Debian ou http://simple-evcorr.sourceforge.net/ ), installez les 2 fichiers de configuration ci-dessous.
Ce n'est pas infaillible, il s'appuie sur une regex de messages connus qui conviennent et signale tous les inconnus. Vous pouvez étendre le regex négatif à la recherche directe au besoin.
polgara:~\# cat /etc/default/sec \#Defaults for sec RUN_DAEMON="yes" DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/syslog -pid=/var/run/sec.pid -detach -log=/var/log/sec.log" polgara:~# cat /etc/sec.conf \# http://simple-evcorr.sourceforge.net/man.html \# http://sixshooter.v6.thrupoint.net/SEC-examples/article.html \# http://sixshooter.v6.thrupoint.net/SEC-examples/article-part2.html type=SingleWithSuppress ptype=RegExp pattern=(?i)kernel.*btrfs: (?!disk space caching is enabled|use ssd allocation|use .* compression|unlinked .* orphans|turning on discard|device label .* devid .* transid|detected SSD devices, enabling SSD mode|has skinny extents|device label|creating UUID tree|checking UUID tree|setting .* feature flag|bdev.* flush 0, corrupt 0, gen 0) window=60 desc=Btrfs unexpected log action=pipe '%t: $0' /usr/bin/mail -s "sec: %s" root
En plus du système de journalisation régulier, BTRFS a une commande Stats , qui conserve une trace des erreurs (y compris les erreurs de lecture, d'écriture et de corruption/de contrôle) par conduire:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
Donc, vous pourriez créer une racine simple cronjob:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Cela vérifiera les erreurs positive compte toutes les heures et vous enverra un email. Évidemment, vous testez un tel scénario (par exemple en causant la corruption ou en supprimant le GREP) pour vérifier que la notification par courrier électronique fonctionne.
De plus, avec des systèmes de fichiers avancés tels que BTRFS (qui ont des checksumming), il est souvent recommandé de planifier un gommage toutes les deux semaines pour détecter une corruption silencieuse causée par un mauvais entraînement.
@monthly /sbin/btrfs scrub start -Bq /data
Le -B L'option gardera le gommage au premier plan, de sorte que vous verrez les résultats dans l'e-mail Cron vous envoie. Sinon, cela va courir dans l'arrière-plan et vous devrez vous rappeler de vérifier les résultats manuellement car ils ne seraient pas dans l'e-mail.
Mise à jour : Amélioration de la GREP comme suggéré par Michael Kjörling, merci.
Mise à jour 2 : Remarques supplémentaires sur le nettoyage et les opérations de lecture régulières (ceci ne s'applique pas uniquement à BTRFS uniquement):
[.____] Comme indiqué par Ioan, un gommage peut prendre plusieurs heures, en fonction de la taille et du type de la matrice (et d'autres facteurs), encore plus d'une journée dans certains cas. Et c'est une analyse active, il ne détectera pas les erreurs futures - l'objectif d'un gommage est de trouver et de résoudre des erreurs sur vos lecteurs à ce moment-là. Mais comme avec d'autres systèmes RAID, il est recommandé de planifier des gommages périodiques. Il est vrai qu'une opération typique d'E/S, comme la lecture d'un fichier, vérifie si les données qui ont été lues sont réellement correctes. Mais envisagez un simple miroir - si la première copie du fichier est endommagée, peut-être par un lecteur qui est sur le point de mourir, mais la deuxième copie, qui est correcte, est en fait lu par BTRFS, puis Btrfs ne saura pas qu'il y a une corruption sur l'un des lecteurs. Ceci est simplement parce que les données demandées ont été reçues, il correspond à la checksum BTRFS stockée pour ce fichier. Il n'y a donc pas besoin de BTRFS de lire l'autre copie. Cela signifie que même si vous lisez spécifiquement un fichier que vous connaissez est corrompu sur un lecteur, rien ne garantit que la corruption sera détectée par cette opération de lecture.
[.____] Maintenant, supposons que BTRFS ne se lit que de la bonne conduite, aucun gommage n'est exécuté qui détecterait les dommages causés sur le mauvais lecteur, puis le bon entraînement va également mal - le résultat serait une perte de données ( Au moins, BTRFS saurait quels fichiers sont toujours corrects et vous permettront toujours de lire celles). Bien sûr, ceci est un exemple simplifié; En réalité, BTRFS ne lira pas toujours d'un lecteur et ignorez l'autre.
[.____] Mais le point est que les gommages périodiques sont importants car ils trouveront des erreurs (et fixez) les opérations de lecture régulières ne détecteront pas nécessairement.
Disques défaillants : Étant donné que cette question est assez populaire, j'aimerais souligner que cette "solution de surveillance" est de détecter des problèmes avec des variateurs éventuellement ( Par exemple, un lecteur mourant causant des erreurs mais toujours accessibles).
D'autre part, si un lecteur est soudainement parti (déconnecté ou complètement mort plutôt que de mourir et de produire des erreurs), ce serait un lecteur défaillant (ZFS marquerait un tel lecteur comme défaut). Malheureusement, BTRFS peut ne pas se rendre compte qu'un lecteur est parti alors que le système de fichiers est monté, comme indiqué dans cette entrée de liste de diffusion du 09/2015 (il est possible que cela ait été corrigé):
La différence est que nous avons du code pour détecter un périphérique n'étant pas présent au mont, nous n'avons pas de code (encore) pour la détecter la chute sur un système de fichiers monté. Pourquoi avoir une détection adéquate pour une disparition d'un appareil ne semble pas être une priorité, je n'ai aucune idée, mais c'est un problème distinct du comportement du mont.
https://www.mail-archive.com/[email protected]/msg46598.html
Il y aurait des tonnes de messages d'erreur dans DMESG à ce moment-là, donc Grepping DMESG pourrait ne pas être fiable.
[.____] Pour un serveur utilisant BTRFS, il est peut-être une idée d'avoir une vérification personnalisée (travail cron) qui envoie une alerte si au moins l'un des lecteurs du tableau RAID est parti, c'est-à-dire non accessible .. .
Selon les statistiques de BTRFS-PROGS V4.11.1, l'option --CHECK qui retournera non nulle si l'une des valeurs ne sont pas nulles, en supprimant la nécessité de la regex.
statistiques de périphérique -C /
Je ne voudrais pas compter sur la commande Statists pour la notification d'erreur, car cette commande ne renvoie aucune erreur si un lecteur s'en va soudainement. Vous pouvez le tester en déconnectant un câble SATA ou en tirant un lecteur - non recommandé avec un système de fichiers important.
btrfs device stats /
Après un redémarrage, BTRFS affiche les entraînements manquants, mais cela peut être trop tard.
btrfs fi show
Cela ressemble à une tâche pour la surveillance du système. Il existe un chèque qui implémente l'API de Nagios Plugin appelé: Check_btrfs . Comme vous pouvez le constater dans le code source, il a une fonction appelée check_dev_stats qui vérifie les statistiques de périphérique et passera à la critique si l'une des valeurs est non nulle. Il vérifie également les problèmes d'attribution. Ce qui reste incertain est comment le chèque se comporte si un disque est absent ou s'éteint hors ligne .
PS: le plugin est emballé dans Debian: surveillance-plugins-btrfs