scrutiny で SSD の寿命を見える化、障害発生時に通知が受けられるようにする。

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 scrutiny
cd 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お勧めします。自分の強運を信用できない方は是非。

Remaining : 0 characters / 0 images
100

Sign up / Continue after login

Related stories

Writer

katana🗡 Lightning Node 運用中。03328dba4e263835416d35b14a2f0298f567c6bb5dad7e3d33d671de30d542b4c1

Share

Popular stories

charge-lnd で fee や max_htlc を自動設定[umbrel 0.5.0以降対応]

854

Lightning node の運用まとめ

446

Raspberry Pi 用の UPS(無停電電源装置) で umbrel の瞬停対策

434