Datadog と Zabbix の比較 - 移行を考えるときに見る 5 つの差

Zabbix と Datadog は世代と守備範囲が違う

Zabbix はオープンソースの監視ソフトウェアで、自分のサーバーにインストールして使います。Datadog は SaaS で、Agent を入れるかクラウドアカウントを連携するとデータが Datadog 側に集まります。同じ「監視ツール」でも、生まれた世代と守備範囲が違うため、機能の一覧で優劣を付ける比較は噛み合いません。

結論を先に言うと、監視対象がオンプレのサーバーと機器で固定的、担当者が Zabbix を熟知している、データを社外に出せない、という組織は Zabbix に残す方が合理的です。逆に、監視対象がクラウドとコンテナで増減し、障害調査がメトリクスだけで終わらずログやトレースへ降りる必要があり、監視基盤の維持に人を割けない組織では、Datadog のホスト単価は基盤運用を外部に預ける対価として採算が合います。本記事はこの分岐を費用構造、運用要件、そして移行で実際に直面する 5 つの差から確かめます。本記事は課金の仕組みを解説するものです。具体的な単価や料金は各社の公式の料金ページで確認してください。

費用構造 - ライセンス無料 + サポート契約か、ホスト単価か

Zabbix の費用は誤解されやすいので、公式ページの記載を正確に押さえます。ライセンスは 2026 年 9 月時点で「バージョン 7.0 以降は AGPLv3 で公開」され、6.4 までは GPLv2 です。公式は「商用の文脈で使う場合は技術サポートの購入で開発を支援してほしい」と書いていますが、利用そのものにライセンス費はありません (出典: Zabbix License)。有償のサブスクリプションはソフトウェアの利用権ではなくサポート契約で、公式ページは「ライセンス費なし、成長への課税なし。価格は対応範囲、アクセス、コミットメントで決まる。ホスト / 機器 / アプリケーション、ユーザー / メトリクス / アラートは無制限」と説明しています。サポート契約は Silver / Gold / Platinum / Enterprise の 4 段階で、対応時間帯 (8x5 か 24x7)、応答時間、対象サーバーの台数や分散監視への対応で価格が決まり、上位 2 段は個別見積もりです。全ての契約に 5 年間のセキュリティ修正保証が含まれます (2026 年 9 月時点・出典: Zabbix Subscriptions)。Datadog はインフラ監視の Pro と Enterprise がホスト単位の月額で、台数に比例します (2026 年 8 月時点の課金単位・出典: Datadog Pricing)。具体的な単価はそれぞれの公式料金ページで確認してください。

表の「監視台数が 10 倍になったとき」の行だけを見れば勝負は付いているように見えますが、Zabbix のライセンス費なしには次節で扱うサーバーと人手の費用が乗ります。比較の正しい式は「Datadog の台数 × 単価」対「Zabbix のサーバー費 + 運用担当の時間 × 時間単価 + 必要ならサポート契約」で、この式の右辺が読めない組織ほど左辺の分かりやすさが効きます。料金の積み上げ構造は料金の読み解きで扱っています。

自前運用ではサーバーとデータベースを自分で持つことになる

Zabbix の公式ドキュメントはアーキテクチャを、エージェントが報告する中央のサーバー、全ての設定と収集データを保存するデータベース、通常はサーバーと同じマシンで動く Web インターフェース、負荷分散のための任意のプロキシ、監視対象に配置するエージェント (4.4 以降は Zabbix agent と Zabbix agent 2 の 2 種類) で説明しています (2026 年 9 月時点・出典: Zabbix overview)。要件ページはさらに具体的です。必要なディスクは監視するホストとパラメーターの数に依存し、長い履歴を残すなら少なくとも数ギガバイトを見込むこと、物理メモリが多いほどデータベースが速く動くこと、監視パラメーター数とデータベースエンジンによっては CPU も相当に必要になることが書かれています。加えて、大規模構成ではデータベースを別サーバーで動かすことを強く推奨し、対応データベースは MySQL / Percona / MariaDB / PostgreSQL (TimescaleDB 拡張を含む) と記載しています (出典: Zabbix Requirements)。

この 5 項目は、裏を返せば Zabbix の強みでもあります。データが自分の DB にあるので保持期間も保存場所も自分で決められ、社外にデータを出せない組織の要件を満たせます。Datadog はこの 5 項目を丸ごと引き受ける代わりに、データは Datadog 側に置かれ、保持はプランで決まります (インフラ監視 Pro / Enterprise でメトリクス 15 か月、2026 年 8 月時点・出典: 前掲 Datadog Pricing)。「自分で持つ自由」と「持たない楽さ」のどちらを買うかが、この節の選択です。

費用の固定性、オンプレ機器の監視、完全な自前保持では Zabbix が勝る

Zabbix が構造的に勝る点は 3 つあります。どれも Datadog が機能を足しても埋まらない種類の差です。第一に費用の固定性です。サポート契約の価格は監視台数に依存せず「ホスト / 機器 / アプリケーション無制限」と明記されているため (2026 年 9 月時点・出典: Zabbix Subscriptions)、監視対象が 100 台から 1,000 台に増えても Zabbix 側の費用は増えません。予算を年度初めに固定したい組織にとって、この性質は SaaS の従量課金より扱いやすいものです。第二にオンプレ機器の監視です。Zabbix は「プリンター、ネットワークスイッチ、ルーター、UPS のように SNMP が有効で、OS とエージェントの導入が現実的でない機器」を SNMP で監視する仕組みを標準で持ち、SNMP チェックは UDP で行われます (出典: Zabbix SNMP agent)。Datadog にもネットワーク機器を監視する製品はありますが、料金ページ上は機器単位で課金される別の SKU (Network Device Monitoring) として提供されています (2026 年 9 月時点・出典: Datadog Pricing)。スイッチと UPS を数十台抱える拠点では、Zabbix の「全部まとめて 1 つのサーバーで」の方が単純です。第三に完全な自前保持です。全ての設定と収集データは自分のデータベースに保存されるため (出典: Zabbix overview)、監視データを社外に出せない規程を持つ組織でも要件を満たせます。この 3 点が組織の制約として効いているなら、Zabbix に残す判断は正しく、移行を急ぐ理由はありません。

増減する対象、相関する調査、アラート疲れの 3 条件で Datadog が活きる

Datadog 側の強みも形容詞ではなく設計で示します。まず、監視対象が増減する環境です。Datadog Agent を入れると既定で 50 を超えるホストメトリクスが取れ、Agent に付けたタグが全てのメトリクス / ログ / トレースに載ります (2026 年 9 月時点・出典: Why should I install the Datadog Agent on my cloud instances?)。Zabbix ではホストを作り、テンプレートをリンクして初めて監視が始まりますが (出典: Zabbix Templates)、Datadog ではオートスケールで増えた EC2 は AWS 連携が検出し、コンテナは Agent が追いかけます。ホストの寿命が数時間の環境では、この「登録しなくても見える」設計が運用の差になります。次に、調査がメトリクスで終わらない環境です。Zabbix はアイテム (数値の時系列) とトリガーを中心にした設計です (出典: Zabbix overview)。Datadog はメトリクスとログとトレースが同じタグで結ばれているので、「CPU が跳ねたときのログ」「そのときの遅いリクエスト」へ 1 画面で降りていけます。最後に、アラート疲れへの対策です。Datadog のモニターはアラートの対象をタグで集約して 1 つのモニターにまとめる設計ができ、料金ページの比較表では Enterprise に異常検知と予測監視が含まれます (2026 年 9 月時点・出典: Datadog Pricing)。Zabbix のトリガーにも依存関係による抑制がありますが (出典: Zabbix Trigger dependencies)、集約の単位はホストとテンプレートが基本です。3 条件のうち 2 つ以上が自分の環境に当てはまるなら、ホスト単価は「調査時間の短縮と基盤運用の外部化」の対価として回収の目があります。

移行で見る 5 つの差 - 持ち出せるもの、捨てるもの、作り直すもの

移行を決めたとき実際に手を動かす人が直面するのは、機能の差ではなく設計思想の差です。5 つに分けて、それぞれ「そのまま持ち出せるか」を確かめます。

Zabbix の公式ドキュメントはテンプレートを「複数のホストに便利に適用できるエンティティの集合」と定義し、ホストにリンクすると項目やトリガーが追加され、テンプレート側の変更が全リンク先に伝わると説明しています (出典: 前掲 Zabbix Templates)。Datadog で同じ役割を果たすのはタグで、「Apache が載ったホスト」はテンプレートのリンクではなく service タグの一致で決まります。つまり移行の本質は「テンプレートの一覧をタグ規約に翻訳する」作業で、ここを雑にすると Datadog 側でダッシュボードもモニターも絞り込めなくなります。逆に 1 と 3 は機械的に進みます。閾値の数字は流用でき、アイテムのキーとメトリクス名の対応表は一度作れば済みます。4 は割り切りが必要で、Zabbix に溜めた数年分の履歴を Datadog へ持ち込むことは前提にせず、必要なら Zabbix を参照専用で残します。5 は技術ではなく規程の問題なので、最初に確認してください。ここで NG なら移行そのものが成立しません。

併走の手順と、移行を決める前のチェック

実務では一気に切り替えず、Zabbix を残したまま Datadog を横に置く併走期間を取ります。公式に用意されている道が Datadog の Zabbix インテグレーションで、2026 年 9 月時点の公式ドキュメントは「Datadog Agent で Zabbix を監視する」「Zabbix のアラートを Datadog に送り、イベントストリームでイベントとして見る」の 2 つの用途を挙げています。この統合は Agent のパッケージに含まれないコミュニティ統合で、Agent 7.21 以上なら次のコマンドで導入します (出典: Zabbix Integration)。

datadog-agent integration install -t datadog-zabbix==<INTEGRATION_VERSION>

アラートの転送は Zabbix 側の Media Type に Webhook を作り、Datadog の API キーと {EVENT.NAME} や {EVENT.NSEVERITY} などのテンプレート変数をパラメーターとして渡す方式で、Zabbix サーバーのタイムゾーンを UTC にする前提条件が明記されています (同出典)。この併走で得られるのは、「Zabbix のトリガーが鳴った時刻に、Datadog 側のメトリクスとログで何が起きていたか」を 1 画面で見る体験です。これを 1〜2 か月続けると、前節の 5 つの差のうち 2 (タグ規約) と 3 (集約の粒度) の設計が実データで固まります。

1 で止まるなら悩む必要はなく、2〜4 が Datadog 側に寄るなら併走から始め、5 が大きいなら「サーバーとクラウドは Datadog、機器は Zabbix」の分担で落ち着くのが現実的な着地です。導入を決めた後の段取りは導入判断チェックリストに、Grafana 系との比較は Datadog と Grafana の比較にまとめています。