ある 11 月の昼下がり。田町の職場から外出し、新橋駅を降りてカンファレンスイベント会場に向かっていた。虎ノ門に通じる大道路をひたすらまっすぐ進んだちょうど真ん中あたりまで到達した頃、ふとスマホの Slack を見ると、「社内のネットワークが切れた」という連絡が入っていた。イベント会場の建物がまっすぐ先に見えるその場で踵を返し、社に戻った。

路上で見た Slack の連絡の内容から、オフィス内のネットワークハブのカスケードの頂点に位置する L2 スイッチが落ちていると予想していた。その L2 スイッチは壁際にあり、OA 床からの配線に余裕がないために無理な姿勢で設置されていたのが秘かに気になっていた。

帰社後、L2 スイッチを確認した。電源ケーブルが本体から外れかかっていた。ケーブル抜け止めのためのクリップが引っ掛かってはいるが、端子が外れているので、見かけ上は「抜けかかっている」、実態は「抜けている」。電源ケーブルを挿し直した。奥までしっかり挿し込んだ。すぐに社内ネットワークは復旧した。

再度イベント会場に向けて出発した。数日にわたるイベントの中でもっとも聞きたかった発表は、復旧のために帰社する間に終わっていた。前年のカンファレンスイベントでは、発表後すぐに公式 YouTube に動画が公開されていたので、聞きそこねた発表はそれで視聴すればいいだろうと割り切った。ところが今年はなぜかいつまで経っても YouTube に配信されなかった。一方的に損をした気分になった……。

外出中に会社に引き戻される悲劇

弊社のような小規模所帯の企業でも、なんだかんだでネットワーク機器の数はそれなりにあります。データを回す以外何もしないという意味での通称「バカ HUB」だけでもけっこうな数です。Web ブラウザーで IP アドレスを叩いて管理画面を出すようなインテリジェントな機器だけでも、両手の指では足りないくらいの数です。

管理画面で管理できるからといって、四六時中その管理画面を見て機器の状況をモニタリングするほどヒマではありません。正常に動いてくれているならよいのですが、問題は機器が「落ちている」ときであって、それは予告なく起きる不測の事態です。そのときタイミングよく機器の管理画面を眺めているはずがありません。だからと言って無策でいると……前述のような悲劇に見舞われるのですよ。

イベント会場に向かうワタシを呼び戻した張本人の L2スイッチですが、電源ケーブルの差し込み口が通路に向くように配置されていました。誰かが足を引っ掛けてもおかしくない配置です。ケーブルクリップで固定されていても、虫の居所が悪い誰かが足をケーブルに引っかけたらその勢いでケーブルが抜けてしまいそうです。そして、ケーブルクリップで固定されていたケーブルがひとりでに抜けるなんてまずありえませんから、ひょっとするとどこぞの誰かが……。

と、ここで犯人捜しをしても得られるものはまったくありませんし、そもそも通路に向いているのがいかんということで、配置の見直しを余儀なくされるのでした。OA 床の下の配線に余裕がないのでこのような配置になっていたのですが、それでもナントカ機器の向きを変え、電源端子を奥に向けてひとまずの解決としました。また呼び戻されたらたまったものではありません。

電源が落ちた直接の原因はそれでクリアしたと思いますが、機器が落ちてしまうのは足トラップだけとは限りません。不足の事態に備えて、機器を監視する仕組みを構築してこそ真の情シスというものです……「情シス名乗っておきながら、今まで監視とか全然していなかったのか？」という盛大なツッコミが聞こえるような気分ですが、遅まきながら監視ツールのひとつでも導入しようとボンヤリ検討しはじめました。

悲劇を回避するための死活監視

ネットワーク機器の監視ツールは、クラウド・オンプレ、有償・無償を含め多々あります。有償ツールを使うにしても、無償ツールでイロイロ試してからいずれ有償ツールに移行するという段階を踏んだアプローチこそ有効にして有益というモノです。クラウドの SaaS はもれなく有償ですから、オンプレの OSS でよさげな監視ツールを使うのが現実的。そうなってくると、Linux サーバーが必要になります。

幸いにも、Windows 11 への入れ換えの煽りで、「ただただ Windows 11 非対応というだけで、比較的新しいしスペックだって充分」な PC がひとつふたつみっつよっつ景気よく放出されていました。Linux サーバーとして余生を送ってもらうにはうってつけです。そんな余剰放出機に Ubuntu Server を突っ込んで、社内ナレッジを構築した話は、さりげなく過去の記事において言及しています。

そのナレッジ用 Ubuntu Server もそうでしたが、OS に Docker をインストールし、ツールのコンテナをその Docker に突っこんで動かすのが 21 世紀の情シスのモダンなアプローチ。Docker さえあれば、好きなコンテナ放り込み放題。よい意味で遊んでみようと思っていましたので、ネットワーク機器の監視ツールはちょうどよい題材です。

花咲く森の道 Uptime Kuma さんに出会った

監視ツールでもっともメジャーなものは Zabbix でしょうか。その Zabbix は Docker 環境ができあがった直後くらいにはコンテナをインストールして、「とりあえず動く」ところまでは達成できていました。が、そもそもスケールが大きい Zabbix、ちまたでは「設定に沼る」と言われており、本格的過ぎて「ほったらかしてよいレベルまで設定を作り込む」には相当な知恵と労力と時間がかかるのでした。それではいつまで経っても監視環境は実現できません。

もっと手軽にすばやく監視環境を構築するのに都合がよろしいツールがないかと探してみたところ、Uptime Kuma という、死活監視だけをするシンプルなツールがあると知りました。英語の名前に見せかけて「Kuma」だけバリバリの日本語。ある日森の中で出会う、あのクマです。花咲く森の道で出会ったと謡われる、あのクマです。

思い立ったが吉日。Uptime Kuma さんをさっそく突っ込んでみよう……と思って docker-compose.yaml を記述して docker コマンド放ったら、アッサリと稼働。さっそく例の L2 スイッチを含め、いくつか監視対象として登録しました。ラック収納型ではない、いわば卓上型の NAS が何台も社内にあったので、そいつらもまとめて面倒見ましょう。

この Uptime Kuma、監視対象機器を登録するだけで設定は終わり、あとはダッシュボードを眺めるだけです。監視対象に ping を放ち、その応答があるかないかだけで「その監視対象が動いているか、それとも電源落ちているか」だけを確認するだけのツール。実に潔いというか男らしいツールではありませんか。

機器監視は通知してナンボ

ここで Uptime Kuma のダッシュボードを眺めるだけではおよそまっとうな監視とは呼べません。異常が発生したときに、何らかのかたちでワタシすなわちネットワーク管理者にプッシュ通知してくれてこそ真の監視です。当然、そんな機能が Uptime Kuma にはあります。なかったらそんなツールはモグリと言っても過言ではありません。一般的にはメール送信になるのでしょうが、チャットのチャンネルに飛ばす設定しました。異常が発生したときに、Slack の指定のチャンネルにアラートが飛びます。

通知によってどの機器に異常が発生しているかわかりますから、一般社員が自由に出入りできない部屋の機器でもない限り、誰でも機器を直に確認できます。足トラップで落ちてしまった L2 スイッチの電源を入れるくらいなら、ワタシがいなくても他の誰かが対処できます。これでココロおきなく外出できるというものです。

実は盛大な空振り

しかしながら、Uptime Kuma ダッシュボードに表示される、正常を示す緑のインジケーターだけをひたすら眺めて暮らすのもなんだかおもしろくありません。野良 NAS のひとつやふたつ、ファームウェアのアップデートを仕掛けたら何か通知が飛ぶ程度です。

ちょうどその頃、パセイジ東京本社が入居するビルの計画停電が実施される時期が近づいていました。社内の機器類はその停電実施前にすべて電源を落とします。当然、例の L2 スイッチも、です。せっかくですので全機器シャットダウン時の通知動作テストも兼ねてやろう……と、絶好の機会に内心ほくそえみました。そして計画停電実施前日、追って Slack のチャンネルに通知が飛ぶことを期待しながら、他のあまたの電子機器の電源を順に落とすその一環で L2 スイッチの電源ケーブルを抜きました。

……ところが、通知は来ませんでした。寝ても覚めても、いつまで経っても。

計画停電実施日の翌日、ウキウキ楽しい休日出勤をしてすべての機器の電源を入れて稼働再開したときに、ようやく Slack に通知がドドンと飛んできました。ほぼ同時期に電源入れましたからまとめて通知が来るのは当然ですが、落としたときに通知が飛ばないのでは、死活監視の意味がありません。はて？

気を取り直してハードウェア見直し

盛大な空振りもいいところですが、うまくいっていない事実をリアルに体感すると、人は否応なくその原因を真面目に考えます。ちょっと考えて、実はネットワーク上の Uptime Kuma 搭載機の位置に問題があったことに気づきました。Uptime Kuma はオフィス内 L2 スイッチの下位に存在します。 L2 スイッチの電源を切ってしまったら、Uptime Kuma はオフィス内に閉じ込められ、通知を飛ばしてもインターネットには届きません。

オフィス内の L2 スイッチサーバーラック内の L2 スイッチに直結しており、そのラック内のルーターを経由してインターネットに接続されています。この構成では、サーバーラック内に死活監視ツールが存在しないといけないのでした。わかってみればなんてことはない、秘孔を突っついてもナンともない聖帝サウザーの体のヒミツと同じです (← 古い)。

なので、サーバーラック内に Uptime Kuma を置かないといけないのですが、そこはラックですから、何でもかんでも置けるわけではありません。Uptime Kuma が動く Ubuntu Server PC は、SFF クラスの筐体の PC ですので小型といえば小型ですが、ラック内には置けません。かと言ってラック収納型機器を追加するかというと……予算組まないといけないくらいエクスペンシブですし、カネもさることながら時間かかりすぎます (ラック収納型の Zabbix アプライアンスが市販されている理由がわかったような気にはなりましたが)。

どうしたものかと自席でボンヤリしていたら、実験・検証用に入手した Raspberry pi が机の上に転がっているのが視界に入りました。確か、ラズパイ用 OS を入れてちょっと遊んだ後、ずっと放置していた……コレですよコレ！

思い立ったが吉日アゲイン。その Raspberry pi にスチャッと Docker を突っ込み、前回と同じように docker-compose.yaml を書いて Uptime Kuma コンテナを起動、あとは前の Uptime Kuma と同じようにせっせと監視対象機器を登録して、晴れてクマさんがもう 1 匹増えました。

お世辞にも高スペックとは言えない Raspberry pi、久しぶりに起動して恒例の apt update と apt upgrade のコマンドコンボを打ち込んだときに、ストレージが microSD であることの現実をイヤというほど思い知らされましたが (つまり、終わるまでたいそう待たされた)、Uptime Kuma 程度の軽量ツールひとつ動かすには必要にして充分です。あとはこいつをサーバーラックに放り込んで、いっちょうあがり。

便りがないのはよい便り

こういう監視ツールは、ひとたび仕込みを済ませてしまうと、「何事もない日常」に慣れ親しんでしまうという、一種の「過信」に陥りがちです。だからこそ通知の仕組みが大事になります。もっとも、Uptime Kuma は「ping 放つだけ」という単純な「死活監視」だけを備えたツールですから、そもそも安心して過信できるほどのものではありません。計画停電のタイミングで配置ミスに気づいたのはよい経験でした。単純なことほど気づきにくいものかもしれません。

そして、世の監視ツールには、ヘルスチェックなどと呼ばれるもっと高度な監視機能を備えたものもあるのでしょうが、今のワタシにはコレが精一杯。ほどほどにしておかないと沼にハマっていつまで経っても監視できない、そこそこの施策で済ませるというバランス感覚が重要……のハズ。

その後、例の L2 スイッチは「足トラップ」対策が功を奏したのか、今では急に息絶えることなくずっと平常運転です。Uptime Kuma のダッシュボードは、登録されている機器たちが普通に動いていることを示しています。機器の稼働時間の大半は「普通に動いている」状態に収まりますし、そうそう電源が勝手に落ちたりもしません。何事も起きないまま毎日が過ぎていきます。いいのです、それでよいのです。便りがないのはよい便り……今回はここまでにしとうございます。

追伸

この記事を公開する2026年7月31日は、ちょうど7月の最終金曜日にあたります。その7月の最終金曜日は「システム管理者の日」なのだそうです。

たったひとり (か、限りなくそれに近い人数規模) で職場の IT 機器を一切合切面倒見てくれるシステム管理者に、この日だけはみんなで感謝の意を表明し、その証としてピザとかアイスとか紙吹雪みたいな「ココロがシアワセになる」ステキな贈り物を送りましょう……みたいな日ですって。ならばワタシも、世の中の情シス・システム管理者のみなさまに最大級のリスペクトを表しながら、自分で自分にごちそうでもしようかな……ちょうど日本ではプレミアムフライデーだしー。