scrutiny で SSD の寿命を見える化、障害発生時に通知が受けられるようにする。
いつだったか、DiamondHands💎🙌のテレグラムでikuradonさんが紹介してくれていた、umbrel のSSD の S.M.A.R.T情報をモニタリングしてくれて、やばくなったら通知してくれるscrutinyというのを入れてみた。
インストール先は、ラズパイのumbrelと、今実験中のubuntuに構築したumbrel。どちらも出来ました。忘備録として共有します。
1.インストール
dockerでインストール。上記サイトに書かれているインストール方法は以下。
docker run -it --rm -p 8080:8080 -p 8086:8086 \
-v `pwd`/scrutiny:/opt/scrutiny/config \
-v `pwd`/influxdb2:/opt/scrutiny/influxdb \
-v /run/udev:/run/udev:ro \
--cap-add SYS_RAWIO \
--device=/dev/sda \
--device=/dev/sdb \
--name scrutiny \
ghcr.io/analogj/scrutiny:master-omnibus- umbrel pc の場合、sudo をつけて実行する(ラズパイのumbrelでは不要)
- /dev/sdb (二つ目のSSD)は無いのでこの行を削除
- ポート8080は他でも使うだろうから、48080に変更
- docker コマンドを実行したフォルダに、influxdb2/ と scrutiny/ のフォルダが作成されるので、先に scrutiny フォルダを作成し、そこに移動しておく。ラズパイのumbrelの場合は、SDカード上ではなくSSD上が望ましい。
(charge-lnd の時は、/mnt/data/upgrades/ でしたね。)
mkdir scrutinycd scrutiny
実行するdockerコマンドは以下。
sudo docker run -it --rm -p 48080:8080 -p 8086:8086 \
-v `pwd`/scrutiny:/opt/scrutiny/config \
-v `pwd`/influxdb2:/opt/scrutiny/influxdb \
-v /run/udev:/run/udev:ro \
--cap-add SYS_RAWIO \
--device=/dev/sda \
--name scrutiny \
ghcr.io/analogj/scrutiny:master-omnibus
ずらずらと表示されて、ここまでくれば、SSDの状態が見られるようになる。
2.SSDの状況を確認
ブラウザから、http://umbrel.local:48080 を開く。
どうやらうちのSSDはまだ大丈夫のようです。
S.M.A.R.Tの詳細情報もここから見られるので、興味のある方は見てください。
3.通知を設定
毎日のチェックを日課にしてもよいかもしれませんが、scrutinyには、異常を検出すると通知する機能があります。
まず、scrutinyセットアップ時にdockerを実行したフォルダのさらに下にscrutinyフォルダが出来ているので、そこに設定ファイル scrutiny.yaml を作成します。
sudo vi scrutiny.yaml
以下の設定をexample.scrutiny.yamlからコピペ。(以下からコピペしてもOK)
# Notification "urls" look like the following. For more information about service specific configuration see
# Shoutrrr's documentation: https://containrrr.dev/shoutrrr/services/overview/
#notify:
# urls:
# - "discord://token@channel"
# - "telegram://token@telegram?channels=channel-1[,channel-2,...]"
# - "pushover://shoutrrr:apiToken@userKey/?priority=1&devices=device1[,device2, ...]"
# - "slack://[botname@]token-a/token-b/token-c"
# - "smtp://username:password@host:port/?fromAddress=fromAddress&toAddresses=recipient1[,recipient2,...]"
# - "teams://token-a/token-b/token-c"
# - "gotify://gotify-host/token"
# - "pushbullet://api-token[/device/#channel/email]"
# - "ifttt://key/?events=event1[,event2,...]&value1=value1&value2=value2&value3=value3"
# - "mattermost://[username@]mattermost-host/token[/channel]"
# - "ntfy://username:password@host:port/topic"
# - "hangouts://chat.googleapis.com/v1/spaces/FOO/messages?key=bar&token=baz"
# - "zulip://bot-mail:bot-key@zulip-domain/?stream=name-or-id&topic=name"
# - "join://shoutrrr:api-key@join/?devices=device1[,device2, ...][&icon=icon][&title=title]"
# - "script:///file/path/on/disk"
# - "https://www.example.com/path"色々な通知方法が使えるようだけど、今回はtelegramを使う。
notify:
urls:
- "telegram://token@telegram?channels=channel-1[,channel-2,...]"上記3行の「#」を消して、有効にする。
telegram の BotFather で新しいトークンを取得(詳細は省略)
今回取得したトークン(一部伏字)は、610*******:AA**********Q9ghuT6sTAfzY7BkDaCIu_k
telegramのパブリックチャネルのチャネル名が必要なので、telegramで各自作成。例えば、@umbrelsample
最終的に設定するtelegramの行は、こんな感じ。
- "telegram://610*******:AA**********Q9ghuT6sTAfzY7BkDaCIu_k@telegram?channels=@umbrelsample"
scrutinyを再起動(又はCtrl+Cで終了させて、改めてdockerで実行)して、設定を反映。
以下で通知のテストをコマンドラインから実行
curl -X POST http://umbrel.local:48080/api/health/notify
telegramに通知が飛んできた！
設定に失敗すると、こんなのが返ってくる。この場合は設定を見直そう。
{"errors":["Bad Request: chat not found"],"success":false}
docker から起動したscrutiny は、そのままだとログアウトすると止まってしまうので、コンソールからCtrl+p,Ctrl-qを連続で押して、コンテナから抜けておきましょう。
4.終わりに
ライトニングノードは基本的に稼働し続ける必要がある。適当なタイミングでファイルを丸ごとバックアップして、SSDが壊れたらバックアップから戻すというのはできない。
つまりSSDが故障して止まりましたというのを避けなくてはいけない。
scrutinyを知る前は、RAID1を構成していつ来るかもしれない故障に備えないといけないかなぁと考えていたけれど、scrutinyの通知を受けて即座に動けばリスクはかなり小さくなるのではないかなと思ってる。
SSDでRAID1とかやっても、もしかしたら2台のSSDが同時に壊れるかもしれないしね。だいたい同じ回数書き込みされているわけで。
というわけで、scrutinyお勧めします。自分の強運を信用できない方は是非。
