背景と目的：『ダッシュボード・ルーレット』に終止符を打つ
半年前、私たちのインフラ監視は断片化され、混乱した状態にありました。LinuxサーバーにはZabbix、古くなったCiscoスイッチには老朽化したMRTGインスタンス、そしてエッジルーターには壊れやすいPythonスクリプトの集まりを使い分けていました。 サービスに不具合が生じるたびに、チームはまず原因を特定するために「ダッシュボード・ルーレット」を10分間も行わなければなりませんでした。私たちが必要としていたのは、レガシーシステムのような手作業のオーバーヘッドなしに、SNMPとエージェントベースのメトリクスの両方を処理できる、すべてを統括する一つのツールでした。
そこで、スタック全体をCheckmkに移行することにしました。本番環境で半年運用してみた結果、その差は歴然です。CheckmkはOpen Monitoring Distribution（OMD）をベースに構築されています。これは、コアエンジン、モダンなWeb UI、そしてグラフ作成ツールを一つのパッケージにまとめたものです。午前3時の緊急呼び出しに疲弊しているシステム管理者にとって、OMDを使いこなすことはキャリアの転換点になるでしょう。ラックがダウンする前に故障しそうな電源ユニットを察知するために必要な可視性を提供してくれます。
私たちはCheckmk Raw Edition（CRE）を選択しました。これは完全にオープンソースであり、現在は250以上のノードを難なく管理しています。最大の強みは「ルールベースの設定」ににある。CPUチェックを追加するために各ホストを一つずつ手動でクリックする代わりに、フォルダに対して一つのルールを記述するだけで済みます。残りの作業はCheckmkが自動で行ってくれるため、毎月約5時間の設定作業を削減できています。
インストール：Ubuntu上に安定した基盤を構築する
最高の体験を得るためには、専用のUbuntu 24.04 LTSインスタンスを用意することをお勧めします。パッケージがほぼすべての依存関係を処理してくれるため、インストールは驚くほどスムーズです。
1. システムの準備
まずはクリーンな状態から始めます。バイナリを取得するためのwgetと、不足しているライブラリでローカルインストールが止まらないようにするためのgdebiが必要です。
sudo apt update && sudo apt upgrade -y
sudo apt install wget bash-completion gdebi-core -y2. Checkmkのダウンロードとインストール
本稿執筆時点では、バージョン2.3.0が安定した選択肢です。OMD環境が必要とする特定のApacheやPythonモジュールを自動的に取得してくれるため、私はgdebiを使用しています。
# 最新のRaw Editionをダウンロード
wget https://download.checkmk.com/checkmk/2.3.0p1/check-mk-raw-2.3.0p1_0.jammy_amd64.deb
# インストールと依存関係の解決
sudo gdebi check-mk-raw-2.3.0p1_0.jammy_amd64.deb3. 最初の監視サイトの立ち上げ
Checkmkは「サイト」という概念を使用して環境を分離します。同じハードウェア上で本番サイトとテストサイトを並行して実行することも可能です。今回はサイト名をitfromzeroとしました。
# インスタンスを作成
sudo omd create itfromzero
# サービスを起動
sudo omd start itfromzero生成された管理者パスワードをメモしておいてください。これでhttp://your-server-ip/itfromzeroからログインできるようになります。古くて使いにくいインターフェースに慣れていたチームにとって、最初のログインは常に「エウレカ（発見）」の瞬間となるはずです。
設定：サーバーとネットワーク機器の制御
エンジンが稼働したら、ワークフローを「コンピューティング用の軽量エージェント」と「ネットワーク用のSNMP」の2つのパスに分けます。
CheckmkエージェントによるLinuxサーバーの監視
Linuxの場合、SNMPのことは忘れてください。Checkmkはポート6556を使用する専用エージェントを使用します。これは非常に効率的です。SNMPは通信量が多くCPU負荷が高くなることがありますが、このエージェントはパーティションごとのIOPSや特定のプロセス状態など、詳細なメトリクスを最小限のオーバーヘッドで提供します。
Checkmkの「Setup」メニューから.debファイルをダウンロードし、対象のサーバーにインストールします。ローカルでの設定は不要です。
# 対象のLinux仮想マシン上で行う操作
sudo gdebi check-mk-agent_2.3.0p1-1_all.debWeb UIでホストのIPを追加し、”API integrations if configured, else Checkmk agent”を選択します。「Service Discovery」をクリックすると、Checkmkはそのマシンのすべての論理ボリュームとネットワークインターフェースを自動的にマッピングします。
SNMP経由でのスイッチとルーターの監視
Checkmkは、ほとんどのオープンソースツールが霞んでしまうほどの詳細レベルでネットワーク機器を処理します。48ポートのCisco Catalystであろうと、小さなMikroTikルーターであろうと、ワークフローは同じです。本番環境ではSNMPv3を推奨しますが、初期テストには標準のコミュニティ文字列でも十分です。
スイッチを追加する手順：
- Setup > Hosts > Add hostに移動します。
- ホスト名を入力します（例：Core-Switch-01）。
- Monitoring agentsの下にある「SNMP」にチェックを入れ、バージョンを選択します。
- SNMP credentialsにコミュニティ文字列を入力します。
- 保存してサービスディスカバリを実行します。
システムは即座にポートの状態、シャーシの温度、さらには電源ユニットのステータスまで取得します。自動生成されるトラフィックグラフは、帯域幅を占有している箇所をリアルタイムで特定するのに非常に役立ちます。
検証：半年使ってみた結論
今では「メインダッシュボード」がチームの朝のコックピットになっています。また、Telegramとも連携させました。コアルーターがBGPピアをドロップした場合、最初のユーザーチケットが作成される前に、私のスマホに通知が届くようになっています。
なぜサービスディスカバリが重要なのか
「フルスキャン」こそが秘伝のタレです。スイッチに新しいファイバーSFPを差し込んだり、サーバーに仮想ディスクを追加したりすると、Checkmkは次回のポーリング時にその変更を検知します。これらを「Vanished（消失）」または「New（新規）」サービスとしてフラグを立てます。これにより、ハードウェアの進化に合わせて監視を正確に保つことができます。
大規模環境向けの最適化
デバイスが200台を超えたあたりで、UIの動作が重くなることに気づきました。デフォルトでは、Checkmkは60秒ごとにポーリングを行います。重要度の低い開発用サーバーについては、これを5分に変更しました。この単純な調整だけで、監視サーバーのCPU負荷が65%から安定した20%まで低下しました。この設定は、Setup > Services > Normal check intervalから変更可能です。
まとめ
Checkmkへの移行は、今年私が行ったインフラ関連の決定の中で最高のものでした。断片化した混乱状態を、ネットワーク機器とサーバーを同等に扱うプロフェッショナルな統合プラットフォームに置き換えることができました。インストールは簡単で、エージェントはシステムパフォーマンスに影響を与えず、SNMPサポートはトップクラスです。ネットワークの健全性を推測するのをやめたいなら、今日からラボで試用を開始してみてください。その可視性は、セットアップにかかるすべての時間に値するものです。
