「監視ツール、何がいいですか」
新しい案件で監視を組むとき、必ず出てくる話です。
調べると、比較表がたくさん出てきます。機能が丸とバツで並んでいて、料金が書いてある。でも、それを見ても決められない。
なぜなら、機能の差より先に見るべきものがあるからです。
正直に告白します。私が主に使ってきたのはZabbixです。他のツールを本格的に運用した経験はありません。
だから今回は、Zabbixを長く使ってきた立場から見えたことを軸に書きます。他ツールについては一般的な特徴として整理しますが、使ったことがないものを「良い」「悪い」とは書きません。
そのうえで、選定で本当に見るべき判断軸を整理します。ここは、どのツールを使うにしても共通する話です。
Zabbixを使ってきて、良かったこと
まず、実感から書きます。
①ライセンス費用がかからない
これが一番大きい。オープンソースなので、監視対象が増えても費用が上がりません。
顧客に提案するとき、この点は強いです。
「サーバーが10台増えたら監視費用も増えます」という説明が不要になる。予算の話が単純になります。
②何でも監視できる
やろうと思えば、たいていのものは監視できます。
- 標準的なOS・ミドルウェアの項目
- 独自のスクリプトを実行した結果
- ログの中の特定文字列
- 外部コマンドの戻り値
「この項目、監視できますか」に対して、ほぼ「できます」と答えられる。 これは運用上、地味に助かります。
③情報が多い
長く広く使われているので、困ったときに情報が見つかります。
日本語の資料も豊富で、詰まったときに調べれば大抵たどり着けます。
Zabbixで大変だったこと
良い面ばかりではありません。正直に書きます。
①構築と維持に手間がかかる
サーバーを立てて、DBを用意して、設定して、というのは自分たちでやることになります。
そして、そのZabbixサーバー自体も運用対象です。
- ディスクが溜まる
- DBのメンテナンスが必要
- バージョンアップの検討
- Zabbix自体の障害対応
監視するために、監視するものが増える。 これはオープンソース型を選んだときの宿命です。
②設定の自由度が高すぎる
何でもできる反面、決まった型がありません。
テンプレートの作り方、トリガーの条件、アクションの設定——人によって組み方が変わります。
その結果、担当者が変わると何がどう設定されているかわからないという状態になりがちです。
私も過去に、前任者が作った複雑なトリガー設定を解読するのに苦労しました。
③初期の学習コストが高い
概念を理解するまでが少し重いです。
ホスト、アイテム、トリガー、アクション、テンプレート——用語と構造を把握しないと設定できません。
新しく入ったメンバーが、すぐには触れない。 これは属人化の原因にもなります。
他のツールの一般的な特徴
ここからは、私が本格運用したことがないツールについてです。使った感想は書けないので、公開されている情報から整理します。
Mackerel
- SaaS型（サーバーを自前で用意しない）
- エージェントを入れると自動で監視が始まる
- 監視ホスト数による従量課金
- 日本製でドキュメントが日本語
構築の手間を減らしたい場合の選択肢とされています。
Datadog
- SaaS型
- クラウドやコンテナ環境との連携が豊富
- 監視だけでなくログやAPMも統合できる
- 機能が広く、料金体系も複数ある
クラウドネイティブな環境での利用が多いようです。
その他
- Nagios：古くからあるオープンソース。シンプル
- Prometheus：コンテナ・Kubernetes環境で広く使われる
- Hinemos：日本製のオープンソース。ジョブ管理も統合
どれが良いかは、環境と体制によります。 一般論として優劣はつけられません。
選定で本当に見るべき5つの軸
ここが本題です。ツールの機能比較より先に、これを確認したほうがいいと思っています。
①誰が構築・維持するのか
一番重要です。
オープンソース型は費用が安い代わりに、構築と維持を自分たちでやります。その工数を確保できるか。
- 構築できる人がいるか
- 継続してメンテナンスする体制があるか
- その人が抜けたらどうなるか
人がいないのに自前構築を選ぶと、後で必ず苦しくなります。
SaaS型は費用がかかりますが、その分の手間を買っていると考えるとわかりやすいです。
②監視対象の規模と増減
台数が固定なら、費用は読みやすい。
でも、今後増える見込みがあるなら注意が必要です。
- 従量課金だと、増えた分だけ費用が上がる
- オープンソースなら台数が増えても費用は変わらない（ただしサーバー負荷は上がる）
3年後の台数を想定して計算すると、判断が変わることがあります。
③環境の種類
オンプレのサーバー中心なのか、クラウドなのか、コンテナなのか。
環境によって、得意なツールが違います。
クラウドやコンテナが中心なら、それに対応した機能を持つツールのほうが楽です。逆に、オンプレの物理サーバー中心なら、従来型のツールで十分なことも多い。
④顧客・社内の要件
意外と見落とされるのがこれです。
- 監視データを外部に出していいか（SaaS型の場合、データは外部に保存される）
- 閉域網から使えるか
- 監査要件を満たすか
セキュリティポリシー上、SaaS型が使えないケースは実際にあります。
技術的に良いツールでも、要件を満たさなければ選べません。選定の初期段階で確認しておくべきです。
⑤運用する人のスキルと人数
これも現実的な話です。
高機能なツールを入れても、使いこなせなければ意味がありません。
- 運用メンバーが何人いるか
- 学習にかけられる時間があるか
- 引き継ぎしやすいか
シンプルなツールで確実に運用するほうが、高機能なツールを持て余すよりずっといい。
「乗り換えたほうがいいですか」と聞かれたら
既存の環境で監視ツールを使っていて、他に移すべきか迷う場合。
私の答えは、**「困っていないなら、そのままでいい」**です。
監視ツールの移行は、思っている以上に大変です。
- 全ホストの設定を作り直す
- しきい値を再検討する
- アラートの飛び先を設定し直す
- 運用手順書を書き換える
- メンバーが新しいツールを覚える
この工数に見合うメリットがあるか。 ここを冷静に見たほうがいいです。
移行を検討すべきなのは、こういうケースです。
- 環境が大きく変わる（オンプレからクラウドへ全面移行など）
- 現ツールのサポートが終了する
- 台数増加で費用構造が破綻している
- 明確に実現できない要件が出てきた
「新しいツールのほうが良さそうだから」だけでは、移行の理由として弱いと思っています。
まとめ
監視ツールの選び方をまとめます。
Zabbixを使ってきた実感
良かった点
- ライセンス費用がかからない
- 何でも監視できる
- 情報が多い
大変だった点
- 構築と維持に手間がかかる（Zabbix自体も運用対象になる）
- 設定の自由度が高く、属人化しやすい
- 初期の学習コストが高い
選定で見るべき5つの軸
- 誰が構築・維持するのか — 体制がないのに自前構築を選ばない
- 監視対象の規模と増減 — 3年後を想定して計算する
- 環境の種類 — オンプレ、クラウド、コンテナで適性が違う
- 顧客・社内の要件 — SaaS型が使えないケースがある
- 運用する人のスキルと人数 — 使いこなせないツールは意味がない
乗り換えについて
困っていないなら、そのままでいい。移行の工数に見合うメリットがあるかを冷静に見る
監視ツールは、機能比較表だけでは選べません。
**大事なのは「その環境で、その体制で、続けられるか」**です。
自分の現場に合ったものを選んでください。高機能である必要は、必ずしもありません。
コメント