BTRFSファイルシステムRAIDのエラーを監視する方法は？

さまざまなBTRFSイベントのプログラム/スクリプトを実行できるデーモンに関するドキュメントをいくつか見ましたが、もう見つかりません。

BTRFS raid1アレイのドライブ障害時にスクリプト/プログラムを実行するにはどうすればよいですか？エラーが発生した場合にスクリプトを実行して、潜在的に障害が発生しているドライブの早期警告として機能させたいのですが、実際のドライブ障害が最も重要です。その時点でファイルシステムのマウントを解除し（それがBTRFSで実行されない場合）、アラームを設定します。

通常のロギングシステムに加えて、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を作成できます。

MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

これにより、1時間ごとに正のエラー数がチェックされ、メールが送信されます。明らかに、このようなシナリオをテストして（たとえば、破損を引き起こしたり、grepを削除したりして）、電子メール通知が機能することを確認します。

さらに、BTRFS（チェックサム機能付き）などの高度なファイルシステムでは、不良ドライブによるサイレント破損を検出するために、数週間ごとにスクラブをスケジュールすることをお勧めします。

@monthly /sbin/btrfs scrub start -Bq /data

この-Bオプションはスクラブをフォアグラウンドで維持するため、cronが送信するメールで結果を確認できます。それ以外の場合は、バックグラウンドで実行され、結果は電子メールには含まれないため、手動で結果を確認する必要があります。

更新：MichaelKjörlingによって提案されたgrepの改善、ありがとうございます。

Update 2：スクラブと通常の読み取り操作に関する追加の注意事項（これはBTRFSのみに適用されるわけではありません）：
Ioanによって指摘されたように、スクラブは、アレイのサイズとタイプ（およびその他の要因）によっては、場合によっては1日以上かかることもあります。これはアクティブスキャンであり、将来のエラーを検出しません。スクラブの目的は、その時点でドライブ上のエラーを見つけて修正することです。ただし、他のRAIDシステムと同様に、定期的なスクラブをスケジュールすることをお勧めします。ファイルの読み取りなどの一般的な入出力操作は、読み取られたデータが実際に正しいかどうかをチェックすることは事実です。しかし、単純なミラーを検討してください。ファイルの最初のコピーが破損する可能性があるドライブによって破損している可能性がありますが、2番目のコピーは実際にはBTRFSによって読み取られ、BTRFSは破損があることを認識しません。ドライブの1つ。これは単に、要求されたデータが受信されたためです。つまり、1つのドライブで破損していることがわかっているファイルを具体的に読み取っても、この読み取り操作によって破損が検出される保証はありません。
ここで、BTRFSが正常なドライブからのみ読み取ると想定し、不良ドライブの損傷を検出するスクラブは実行されず、正常なドライブも不良になる-その結果、データが失われます（少なくともBTRFSは知っています）どのファイルがまだ正しく、それらを引き続き読み取ることができます）。もちろん、これは簡単な例です。実際には、BTRFSは常に1つのドライブから読み取り、他のドライブを無視するわけではありません。
ただし、ポイントは定期的なスクラブが重要であることです。定期的なスクラブは、通常の読み取り操作では必ずしも検出されないエラーを検出（および修正）するためです。

障害のあるドライブ：この質問は非常に人気があるため、この「監視ソリューション」は、可能性のある不良ドライブの問題を検出するためのものであることを指摘したいと思います（たとえば、ドライブの故障によりエラーが発生するがアクセス可能）。

一方、ドライブが突然なくなった場合（切断されたり、完全に停止したりするのではなく、エラーが発生してエラーが発生することはありません）、ドライブに障害が発生します（ZFSはそのようなドライブを障害としてマークします）。残念ながら、BTRFSは、2015年9月のこのメーリングリストエントリで指摘されているように、ファイルシステムのマウント中にドライブがなくなったことを認識しない場合があります（パッチが適用されている可能性があります）。

違いは、マウント時に存在しないデバイスを検出するためのコードがあり、マウントされたファイルシステムにドロップすることを検出するためのコードが（まだ）ないことです。デバイスが消えたことを適切に検出することが優先事項ではないように思われるのはなぜですか、私にはわかりませんが、それはマウント動作とは別の問題です。

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/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

ユーザー処理のためにBTRFSイベントを公式に報告するデーモンまたはユーティリティはないようです。最も近い代替手段は、BTRFSからのメッセージについてシステムログを監視し、それに応じて対応することです。

http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html

上記のリンクは、BTRFSに関する予期しないログメッセージに対処するための汎用ログモニタリング用に設計されたスクリプト（secDebianまたはSECのパッケージ）を構成するための詳細を提供します。また、ビット腐敗をチェックし、予防措置としてログエントリを発行するために、定期的にスケジュールされたファイルシステムのスクラブに依存しています。以下は、SECスクリプトに固有の抜粋です。

BTRFSファイルシステムのエラーまたは警告を報告するように秒、イベント相関関係子を構成する方法

sec.plをインストールした後（debianまたはhttp://simple-evcorr.sourceforge.net/に apt-get install sec ）、以下の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

システム監視のタスクのように聞こえます。NagiosプラグインAPIを実装するチェックが存在します：check_btrfs。ソースコードからわかるように、この関数check_dev_statsには、デバイスの統計情報をチェックする関数があり、値がゼロ以外の場合にクリティカルになります。また、割り当ての問題もチェックします。不明な点は、1つのディスクが存在しないか、オフラインになった場合のチェックの動作です。

PS：プラグインはDebianにパッケージ化されています：monitoring-plugins-btrfs