BTRFSファイルシステムRAIDのエラーを監視する方法は？
さまざまなBTRFSイベントのプログラム/スクリプトを実行できるデーモンに関するドキュメントをいくつか見ましたが、もう見つかりません。
BTRFS raid1アレイのドライブ障害時にスクリプト/プログラムを実行するにはどうすればよいですか？エラーが発生した場合にスクリプトを実行して、潜在的に障害が発生しているドライブの早期警告として機能させたいのですが、実際のドライブ障害が最も重要です。その時点でファイルシステムのマウントを解除し（それがBTRFSで実行されない場合）、アラームを設定します。
ユーザー処理のためにBTRFSイベントを公式に報告するデーモンまたはユーティリティはないようです。最も近い方法は、システムログでBTRFSからのメッセージを監視し、それに応じて対応することです。
上記のリンクは、スクリプトを構成するための詳細情報を提供します（Debianのsecパッケージまたは [〜＃〜] sec [〜＃〜] ）。 BTRFSに関する予期しないログメッセージ。また、ビット腐敗をチェックし、予防措置としてログエントリを発行するために、定期的にスケジュールされたファイルシステムのスクラブがあるかどうかにも依存します。以下は、SECスクリプトに固有の抜粋です。
BTRFSファイルシステムのエラーまたは警告を報告するように秒、イベント相関関係子を構成する方法
Sec.pl（debianまたはapt-get install sec on http://simple-evcorr.sourceforge.net/ ）をインストールした後、以下の2つの設定ファイルをインストールします。
これは絶対に確実なことではなく、問題のない既知のメッセージの正規表現に依存し、すべての未知のメッセージを報告します。必要に応じて、前向きの否定的な正規表現を拡張できます。
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
通常のロギングシステムに加えて、BTRFSにはstatsコマンドがあり、エラー（読み取り、書き込み、破損/チェックサムエラーを含む）を追跡します。ドライブ：
# 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
したがって、単純なルートcronjobを作成できます。
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
これにより、1時間ごとに正のエラー数がチェックされ、メールが送信されます。明らかに、このようなシナリオをテストして（たとえば、破損を引き起こしたり、grepを削除したりして）、電子メール通知が機能することを確認します。
さらに、BTRFS（チェックサム機能付き）などの高度なファイルシステムでは、不良ドライブによって引き起こされるサイレント破損を検出するために、数週間ごとにスクラブをスケジュールすることがしばしば推奨されます。
@monthly /sbin/btrfs scrub start -Bq /data
-Bオプションはスクラブをフォアグラウンドで維持するため、cronが送信するメールで結果を確認できます。それ以外の場合は、バックグラウンドで実行され、結果は電子メールに含まれないため、手動で結果を確認する必要があります。
Update：MichaelKjörlingによって提案されたgrepの改善、ありがとうございます。
更新2：スクラブと通常の読み取り操作に関する追加の注意事項（これはBTRFSのみに適用されるわけではありません）：
Ioanによって指摘されたように、スクラブは、アレイのサイズとタイプ（およびその他の要因）によっては、場合によっては1日よりも長い時間かかることがあります。これはアクティブスキャンであり、将来のエラーを検出しません。スクラブの目的は、その時点でドライブ上のエラーを見つけて修正することです。ただし、他のRAIDシステムと同様に、定期的なスクラブをスケジュールすることをお勧めします。ファイルの読み取りなどの一般的な入出力操作は、読み取られたデータが実際に正しいかどうかをチェックすることは事実です。ただし、単純なミラーを検討してください。ファイルの最初のコピーが破損する可能性があるドライブによって破損している可能性がありますが、2番目のコピーは実際にはBTRFSによって読み取られますが、BTRFSは破損があることを認識しません。ドライブの1つ。これは、要求されたデータが受信されたため、BTRFSがこのファイル用に保存したチェックサムと一致するため、BTRFSが他のコピーを読み取る必要はありません。 これは、あるドライブで破損していることがわかっているファイルを具体的に読み取っても、この読み取り操作によって破損が検出される保証はないことを意味します。
ここで、BTRFSは正常なドライブからのみ読み取ると想定し、不良ドライブの損傷を検出するスクラブは実行されず、正常なドライブも不良になる-その結果、データが失われます（少なくともBTRFSは、どのファイルがまだ正しいかを認識し、それらを引き続き読み取ることができます）。もちろん、これは簡単な例です。実際には、BTRFSは常に1つのドライブから読み取り、他のドライブを無視するわけではありません。
しかし、定期的なスクラブは、通常の読み取り操作では必ずしも検出されないエラーを検出（および修正）するため、定期的なスクラブが重要であることが重要です。
障害のあるドライブ：この質問は非常に人気があるため、この「監視ソリューション」は不良ドライブの問題を検出するためのものであることを指摘しておきます（たとえば、エラーが発生しているがまだアクセス可能なドライブが死んでいる）。
一方、ドライブが突然なくなった場合（切断されたり、完全に停止したりするのではなく、故障してエラーが発生した場合）は、ドライブに障害が発生しています（ZFSはそのようなドライブに障害とマークを付けます）。残念ながら、BTRFSは、2015年9月のこのメーリングリストエントリで指摘されているように、ファイルシステムがマウントされているときにドライブがなくなったことを認識しない場合があります（パッチが適用されている可能性があります）。
違いは、マウント時に存在しないデバイスを検出するためのコードがあり、マウントされたファイルシステムにドロップすることを検出するためのコードが（まだ）ないことです。デバイスが消えたことを適切に検出することが優先事項ではないように思われるのはなぜですか、私にはわかりませんが、それはマウント動作とは別の問題です。
https://www.mail-archive.com/[email protected]/msg46598.html
その時までにdmesgには大量のエラーメッセージがあるため、dmesgをgrepすることは信頼できない可能性があります。
BTRFSを使用するサーバーの場合、RAIDアレイのドライブの少なくとも1つがなくなった場合、つまりアクセスできなくなった場合にアラートを送信するカスタムチェック（cronジョブ）を用意することをお勧めします。 。
Btrfs-progs v4.11.1以降、statsには--checkオプションがあり、いずれかの値がゼロでない場合にゼロ以外を返すため、正規表現の必要がなくなります。
デバイス統計-c /
エラー通知はstatsコマンドに依存しません。ドライブが突然停止しても、このコマンドはエラーを返さないからです。 SATAケーブルを外すか、ドライブを引くことでテストできます。重要なファイルシステムでは推奨されません。
btrfs device stats /
再起動後、btrfsは不足しているドライブを表示しますが、それは遅すぎるかもしれません。
btrfs fi show
システム監視のタスクのように聞こえます。 check_btrfs と呼ばれるNagiosプラグインAPIを実装するチェックが存在します。ソースコードを見るとわかるように、これにはcheck_dev_statsという関数があり、デバイスの統計情報をチェックし、値のいずれかがゼロ以外の場合にクリティカルになります。また、割り当ての問題もチェックします。不明な点は 1つのディスクがないか、オフラインになった場合のチェックの動作 です。
PS：プラグインはDebianにパッケージ化されています： monitoring-plugins-btrfs