🚨

Raspberry PiのSD容量がヤバくなったらNew RelicからSlackで通知をもらう

2021/03/22に公開

Slack

New Relic

tech

前回までのあらすじ

RPiでUbuntu Serverを動かしてNew Relic Infrastructureを入れた
メトリクス見れて楽しかった

今回の目標は監視→アラートという観点で実装を進めてみたいと思います

何が実現できるのか

Ubuntu Serverで動いているRaspberry Piで

昔ながらのインフラ監視項目をNew Relicで入れてみる
です

前提とか

ハードウェアとかアカウントとか

前回と同じです
すでにやってみた方はNew RelicアカウントとSSHできる環境があれば大丈夫です

今回は通知先にSlackを利用するので適当にSlackアカウントを作成しておきましょう
そして通知先のチャンネルを作成しておきます、 #newrelic_alertsとしておきましょう

New Relicによる監視 = Alerts おさらい

Policyを制すものはNew Relic Alertsを制す

New Relicからアラートを飛ばすために避けて通れないのがPoliciesですが理解すべき順番は監視すべきメトリクスからもっとも遠い、つまり行動を起こす人の軸から考える必要があります
「誰が行動を起こすべきか」 - Notification (誰に)
「どう通知されるべきか」 - Notification (Channel)
「何を通知すれば解決行動に結びつくか」 - Alert Policy　←今回のキモ
「どうすれば問題の通知を発生させられるか」 - Conditions 通知すべき単位
「どういう事象がその問題に結びつくか」 - Conditions 監視メトリクス
の順です。

Notification : 誰が行動を起こすべきか - どう通知されるべきか

New RelicのUIにアクセスできる人が基本になります
「E-MailやSlack, PagerDutyで通知を受け取る」可能性があります
開発チームなのかインフラチームなのかその塊を想定しておきましょう（今回は私一人なので私です）
どんな通知がその「行動を起こす人にベスト」かを考えてまずはNotification channelsを設定します
その人たちがアクセス可能なチャネルが「どう通知されるべきか」に結びつくので共通しているツールとして今回は（私一人なので）Slackを選択します（ひとりSlackです。ひとりSlack）

Slack AppにNew Relic Alertsを追加し、投稿先を先ほど作成した #newrelic_alertsにします

Webhook URLが出ますのでコピーしておきます

次はNew Relic UI上の作業です
[Alerts&AI]から[Notification channels]を選び、通知チャネルを作ります
Slackが用意されているので選択します

（New Relic上の）チャンネル名を設定し先ほどコピーしたWebhookのURLをペーストします

[Send a test notification]できちんとSlackに通知が飛ぶか確認しておきましょう

ツッタカタとSlackに通知されればバッチリです

Alert Policy : 何を通知すれば解決行動に結びつくか

これで通知先ができあがったので今度はポリシーです
ポリシーとは、先ほど設定した「通知されるべき行動を起こす人たちに、通知を送る単位」ですので「適切な通知ポリシー設計をする」ことが肝心です

ここでは試しにRPiの最大のトラブルポイントであるディスクUsageを通知条件にしてみましょう
この通知がくるということはこれ以上ログ吐けない！とか止まる！とか起こってしまうので対応が必要になりますから
前回の記事では4GBのSDで稼働させているので実にカツカツですので丁度良いです

[Policies]画面で[+ New Alert Policy]から新しいポリシーを作成します
名前は、ついている事が大切だそうですの適当な名前をつけましょう

Incident Preferenceの設定は通知されインシデントが作成されるタイミングを設定するものです
本格的に運用される際は公式ドキュメントを参考にしましょう

生まれたてのポリシーにはConditionが存在しませんので設定しましょう
その前に先ほど作ったNotification ChannelsをSlackにしておきましょう

Notification Channels タブから[Add notification channels]、[Slack]を選ぶと先ほど作成した設定が出てくるので選択します

[Update Policy]で更新します

Conditions :「どうすれば問題の通知を発生させられるか - どういう事象がその問題に結びつくか

「RPiのSD残容量がヤバくなったら交換するので通知したい」が今回の目的でした

[Infrastructure] - [Hosts] で目的のメトリクスを探しましょう
Storageが怪しいので見てみると既に94％でした

丁度いいですね、これを指標にしましょう
[…]からCreate Alertを選択します

Conditionの名前をつけます、名前は、ついている事が大切ですから
詳細にはこのインシデントを見た人（もしかしたら5年後の娘かもしれませんし）が行動をおこせるような詳細を書いてあげましょう
アラートタイプはあらかじめ設定されているので対象とすべきホストのフィルタ条件を決めます
仮にRPiが100台とかになってもhostnameをrpi_XXXとかネーミングにしておけばここでまとめて通知できそうです

あとは　MountPointあたりをディスクの指定に設定し閾値の設定です

ここでは5%未満になったらアラートをあげ、[Add a warning threshold] でワーニングを10%未満としました

Alert policyのドロップダウンには先ほど作成したアラートポリシーが出てきますので選択します
RunbookにはこのConditionに至った時にとるべき行動の遺言を残せますのでちゃんと入れておきます

Alerts & AIのPolicyを見ればちゃんと作成されてますね

ためしてみましょう

さっきの感じだとあと数百MBも容量を圧迫すれば大丈夫そうです
とか書いている間にもう検知しました、WarningなのでUI上に出ますね

確認しておきましょう

ubuntu@ubuntu:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            407M     0  407M   0% /dev
tmpfs            91M  3.9M   87M   5% /run
/dev/mmcblk0p2  3.3G  3.0G  191M  94% /
・
・
・

とりあえず100MB詰め込んでみます

ubuntu@ubuntu:~$ dd if=/dev/zero of=100mb.file bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.751759 s, 139 MB/s

2分以上この状態が継続したら通知、という条件にしているのでお茶でも飲んでます

ツッタカタ

きました！

Go to Runbookをクリックすればちゃんと解決策のページも出てきます。

[View Incident]を押せばIncidentsページの当該インシデントに飛びます
あとは「しゃあないな、ぼくが対応しよう」と思った人がNR上のAchnowledge ボタンを押せばまた通知が飛びます

さて、かわいそうなので消してあげましょう
rm ./100mb.file

2分ほどお茶をのんで待ちましょう