博士

やあ、ロボ子。今日は自宅ネットワーク監視ツールについての記事を見つけたのじゃ。

ロボ子

博士、こんにちは。自宅ネットワークの監視ですか、面白そうですね。どのような内容なのでしょうか？

博士

この記事では、シンプルで理解しやすい監視ツールを構築した話が書かれておる。重要な障害発生時などに通知が来るようにして、Wireguardメッシュネットワークも監視できるようにしたらしいぞ。

ロボ子

Wireguardの監視もできるんですね。具体的には、どのような設計になっているんですか？

博士

HTTPやDNSなどを定期的にチェックするプログラムを作って、ntfy.sh経由で通知するようにしたみたいじゃ。状態管理を避けて、可動部を少なくしているのがポイントじゃな。

ロボ子

ntfy.shですか。シンプルなPubSubソリューションですね。状態管理を避けるというのは、具体的にどういうことでしょうか？

博士

状態を保持しないってことじゃ。最後のプローブの成否とエラーメッセージだけを持つようにしているらしい。こうすることで、複雑さを減らしているのじゃ。

ロボ子

なるほど。たしかに、状態を持つと管理が大変になりますからね。記事では、どのようなプロ―バーを実装したと書かれていますか？

博士

`prober`インターフェースを定義して、HTTP、TCP、DNS、ドメイン有効期限などをチェックするプロ―バーを実装したそうじゃ。不安定な状態を考慮して、`retryProber`も使っているみたいじゃな。

ロボ子

ドメインの有効期限チェックは便利ですね。監視ツールはルーター上で動いているんですね。

博士

そうじゃ。ルーター上で`DynamicUser`デーモンとして実行しているらしい。そして、healthchecks.ioをデッドマンスイッチとして使って、プログラムのクラッシュを検知しているみたいじゃ。

ロボ子

healthchecks.ioをデッドマンスイッチとして使うのは良いアイデアですね。監視ツールが停止したことに気づけますね。

博士

この記事では、監視をしない、updown.io、Uptime Kuma、PrometheusとBlackbox exporterといった代替案も検討したみたいじゃな。それぞれに利点と欠点があるからの。

ロボ子

PrometheusとBlackbox exporterは高機能ですが、今回の用途には複雑すぎますね。シンプルな監視ツールを構築するという目的に合致していますね。

博士

じゃろ？ この監視ツールの利点は、プログラム全体を理解しやすいこと、Go標準ライブラリのみに依存していること、プロ―バーの追加が容易なことじゃな。

ロボ子

確かに、理解しやすいのは重要ですね。自分でメンテナンスすることを考えると、シンプルであることは大きな利点です。

博士

そういうことじゃ。ところでロボ子、もし私が監視ツールになったら、毎日「博士、今日も可愛いですね」って通知するぞ。

ロボ子

それは… 監視というより、ただの褒め言葉ですね。でも、毎日通知が来たら、ちょっと嬉しいかもしれません。