1. 意思決定の背景と実務上の重要課題
インフラ監視基盤の選定において、開発現場と経営管理部門の間で絶えず繰り返される議論がある。「ライセンス費用がゼロのオープンソース（Zabbix等）で自作すれば安上がりではないか」という現場発信のコスト削減案と、「設定工数と運用保守に人件費が吸い取られ、結果として高コストになっているのではないか」というCTO・VPoEの懸念である。
サーバー監視およびAPM（Application Performance Monitoring）の選定において考慮すべき本質は、ソフトウェアの「表面的なライセンス価格」ではない。「監視サーバー自体の冗長化、OS・ミドルウェアのパッチ適用、DBパーティショニング、ディスク容量枯渇対応」に費やされるシニアインフラエンジニアの人件費と、DatadogやNew RelicなどのモダンSaaSが請求してくる「ホスト数・データ転送量・ユーザー数」に応じた従量課金との力学関係である。
現代の分散システム環境（マイクロサービス、Kubernetes、サーバーレスアーキテクチャ）では、単なる死活監視（Ping/ポート監視）やリソース監視（CPU/Memory/Disk使用率）だけでは障害の根本原因を特定できない。アプリケーションのトレース、スロークエリ、外部API連携のレイテンシを可視化するAPMおよび分散トレーシングが実質的な必須要件となっている。
本稿では、Zabbixを中心としたOSSセルフホスト構成と、Datadog、New Relicという市場を二分する監視SaaSを対象に、ホスト台数および組織体制ごとの冷徹な「損得分岐点」を実額シミュレーションに基づいて提示する。
2. 【条件別】損得分岐マトリクス（早見表）
自社のホスト規模、組織体制、アプリケーション特性に応じた最適解の早見表である。判定根拠には、監視対象の増減規模だけでなく、監視基盤の運用保守に割かれる社内リソースの時給換算コストを組み込んでいる。
| システム環境・企業フェーズ | 監視対象ホスト数 | インフラ専任エンジニアの有無 | APM・分散トレーシング要求 | 推奨ソリューション | 判定理由と損得分岐の背景 |
|---|---|---|---|---|---|
| スタートアップ / 新規事業開発 | 1〜15台 | 無（アプリ開発者が兼任） | 必須（初期バグ・ボトルネック即時特定） | Datadog または New Relic | インフラ構築・保守に月間5時間以上費やすと、時給換算でSaaS利用料を上回る。エージェント導入数分で完了するSaaSが圧倒的優位。 |
| 急成長Webサービス（SaaS等） | 16〜50台 | 1名（兼任含む） | 必須（SLA担保、クエリ最適化） | New Relic | データインジェスト課金（$0.30/GB）＋ユーザー課金のモデルにより、ホスト台数が伸長してもインフラ監視＋APMのトータル費用を低く抑え込みやすい。 |
| クラウドネイティブ大規模開発 | 51〜200台 | 有（SREチーム 2〜3名） | 必須（マイクロサービス、分散追跡） | Datadog | ログ、メトリクス、APM、ネットワークの一元相関分析によるMTTR（平均復旧時間）短縮効果がSaaS利用料（月額数十万円〜百数十万円）を上回る。 |
| 伝統的エンタープライズ / 社内基幹 | 50〜200台 | 有（情シス・インフラ専任） | 不要（死活・リソース監視が主目的） | Zabbix（オンプレ/クラウド自作） | APMが不要で、かつインフラ保守工数を内製人件費（固定費）として吸収できる場合、SaaSのホスト課金を回避して完全無償ライセンスの恩恵を最大化可能。 |
| 金融・公共・完全閉域網環境 | 規模問わず | 有（保守ベンダー常駐） | 限定的 | Zabbix（閉域オンプレミス） | 外部SaaSへのデータ送信がセキュリティ規約上不可能な場合、コスト比較以前にセルフホスト監視（Zabbix等）以外の選択肢が排除される。 |
| 超大規模インフラ基盤 | 300台以上 | 有（専任インフラチーム 5名以上） | 選択的（主要APIのみAPM導入） | ハイブリッド（Zabbix基盤 ＋ 重要部のみSaaS） | 全台にSaaSのAPMを導入すると月額費用が数百万円規模に跳ね上がるため、基幹の死活・OS監視はZabbix、フロントエンド・基幹APIのみSaaSを適用するのが最も合理的。 |
3. 【徹底対比】主要選択肢の構造・スペック・料金比較
3つのプラットフォームにおけるアーキテクチャ、課金体系、機能要件、運用保守リスクの対比である。
| 比較項目 | Datadog | New Relic | Zabbix（セルフホスト） |
|---|---|---|---|
| アーキテクチャ分類 | 完全マネージドSaaS | 完全マネージドSaaS | OSSセルフホスト（オンプレミス/IaaS） |
| 主要な課金体系 | ホスト単位＋機能別従量課金 （Infrastructure: $15〜$23/host/月、APM: +$31/host/月、Log: $0.10/GB〜） | データ転送量＋ユーザー課金 （データ: $0.30/GB/月、Full Platform User: $99〜$349/月/人、無料枠100GB/月） | 完全無料（GNU GPL v2） ※監視サーバーのコンピュート/ストレージ費用および保守人件費が実質コスト |
| エージェント導入・設定工数 | 極めて低い（curlコマンド1行、各種クラウド連携はOAuth/IAMで数分） | 極めて低い（ワンライナーインストール、Guided Install完備） | 中〜高（Agentインストール、zabbix_agentd.conf設定、Template割り当て、SELinux/ファイアウォール調整） |
| APM・分散トレーシング | 業界最高水準の可視化。コード改修不要のエージェント自動計装が豊富。 | 強力な自動計装と分散トレーシング。APMを導入してもホスト追加料金なし（データ量依存）。 | 基本機能としては非対応（OpenTelemetry CollectorやJaeger、Grafana Tempo等との別途統合自作が必要）。 |
| サーバー監視以外の機能網羅性 | ログ管理、ネットワーク、Synthetics、RUM、CSPM、Database Monitoring | ログ管理、エラー追跡、Synthetics、RUM、脆弱性管理、CodeStream | ネットワーク機器（SNMP）、死活監視、閾値トリガー、スクリプト実行、各種通知 |
| アラート設定・ダッシュボード | 高度な相関分析、機械学習による異常検知、ノーコードでのダッシュボード構築 | NRQL（独自クエリ言語）による柔軟なクエリ、美麗なダッシュボード | マクロを多用した複雑なトリガー設定。ダッシュボードは機能的だがモダンUIと比較すると設計に一定の習熟が必要 |
| 監視サーバー自体の運用負荷 | ゼロ（ベンダー側で完全担保、アップデートも自動） | ゼロ（ベンダー側で完全担保、アップデートも自動） | 極めて高い ・Zabbix Server / Web / DB（PostgreSQL/MySQL）の二重化 ・DB容量監視、ハウスキーパー負荷制御 ・メジャーバージョンアップ時のスキーマ移行 |
| データ保持期間 | 標準15ヶ月（メトリクス） | 標準8日〜395日（契約・データタイプ依存、設定変更可能） | ストレージ容量が許す限り無制限（ヒストリ・トレンドの保存設計に依存） |
| ベンダーロックイン / 移行性 | 高（カスタムメトリクスやアラート定義の独自性） | 高（NRQLや独自ダッシュボードへの依存） | 低（OSSであり、OpenMetrics/Prometheus等との相互運用性が高い） |
4. 【規模別・年数別】3年間の実額TCO（総保有コスト）シミュレーション
監視基盤におけるTCO（Total Cost of Ownership）を計算する際、多くの組織が見落とすのが「監視基盤の運用保守に消費されるエンジニアの人件費」である。
前提条件の定義
- 為替レート: 1ドル = 150円で試算。
- エンジニア人件費単価: 時給換算 6,000円（年収換算 約1,000万〜1,200万円レベルのシニアインフラ/SREエンジニア、または外注委託フィーを想定）。
- Zabbixインフラ構成費用:
- 10台規模: AWS t4g.medium 1台 ＋ EBS 100GB（月額 約6,000円）
- 50台規模: AWS t4g.large 2台（冗長化） ＋ Aurora RDS（PostgreSQL）db.t4g.medium（月額 約35,000円）
- 200台規模: AWS c6g.xlarge 2台 ＋ Aurora RDS db.r6g.xlarge ＋ プロキシサーバー（月額 約180,000円）
- Zabbix保守工数:
- 10台規模: 月間4時間（OSパッチ、Zabbixバージョン管理、アラートチューニング）＝ 月額24,000円
- 50台規模: 月間12時間（DBハウスキーピング最適化、監視テンプレート更新、障害調査）＝ 月額72,000円
- 200台規模: 月間30時間（パーティショニング管理、プロキシ負荷分散、冗長系フェイルオーバーテスト）＝ 月額180,000円
- Datadog構成内訳:
- 10台/50台/200台すべてで「Infrastructure Pro（$15/台）」＋「APM（$31/台）」を採用。ホストあたり月額$46（6,900円）。ログ等は基本枠内想定。
- New Relic構成内訳:
- 全ホストにインフラ監視＋APMエージェントを導入。データ送信量は1ホストあたり月間15GB（無料枠100GB超過分は$0.30/GB）。
- Full Platform User（エンジニア）：10台規模=1名（$99/月）、50台規模=3名（$99/月×3）、200台規模=8名（$349/月×8 ※Enterprise）。Core User等は適宜追加。
パターンA：小規模（監視対象 10台）/ 3年間のTCO
少人数開発チーム、スタートアップを想定した規模。
| 費用項目 | Datadog（Pro + APM） | New Relic | Zabbix（AWS自作） |
|---|---|---|---|
| ソフトウェア/SaaS利用料（年額） | 828,000円（$46×10台×12ヶ月×150円） | 223,200円（User 1名 + 転送量50GB超過分） | 0円（ライセンスフリー） |
| 監視サーバー基盤費用（年額） | 0円 | 0円 | 72,000円（EC2+EBS） |
| 構築初期費用（初期工数換算） | 30,000円（5時間） | 30,000円（5時間） | 240,000円（40時間：OS・DB・Zabbix初期設定） |
| 運用保守人件費（年額） | 36,000円（月間0.5時間） | 36,000円（月間0.5時間） | 288,000円（月間4時間×12ヶ月×6,000円） |
| 1年目の実額TCO | 894,000円 | 289,200円 | 600,000円 |
| 3年間の累計TCO | 2,622,000円 | 807,600円 | 1,320,000円 |
分析: 10台規模において、最もTCOを圧縮できるのはNew Relicである。無料枠100GBの恩恵と低廉なユーザー課金が効く。一方、Zabbixはライセンス費用がゼロであっても、初期構築工数と月4時間の最小限のパッチ当て工数だけで3年累計132万円に達し、New Relicを大幅に上回る。DatadogはAPMを全台に付与すると高額になるが、運用工数が完全に浮くため「エンジニアの採用難・事業開発への集中」を考慮すれば十分許容範囲となる。
パターンB：中規模（監視対象 50台）/ 3年間のTCO
サービスがスケールし、マイクロサービス化や本番・ステージング環境が拡充した規模。
| 費用項目 | Datadog（Pro + APM） | New Relic | Zabbix（AWS冗長化） |
|---|---|---|---|
| ソフトウェア/SaaS利用料（年額） | 4,140,000円（$46×50台×12ヶ月×150円） | 623,700円（User 3名 + 転送量650GB超過分） | 0円 |
| 監視サーバー基盤費用（年額） | 0円 | 0円 | 420,000円（EC2×2+Aurora） |
| 構築初期費用（初期工数換算） | 60,000円（10時間） | 60,000円（10時間） | 480,000円（80時間：冗長構成、テンプレート設計） |
| 運用保守人件費（年額） | 72,000円（月間1時間） | 72,000円（月間1時間） | 864,000円（月間12時間×12ヶ月×6,000円） |
| 1年目の実額TCO | 4,272,000円 | 755,700円 | 1,764,000円 |
| 3年間の累計TCO | 12,696,000円 | 2,147,100円 | 4,332,000円 |
分析: 50台規模では、Datadogの「ホスト単位一律課金」の負担感が増大し、3年で1,200万円を超える。これに対し、New Relicはデータ量依存のため約215万円と際立ったコストパフォーマンスを発揮する。Zabbixはサーバー冗長化と月12時間の運用工数が発生するため3年で約433万円となり、「Zabbixオンプレ自作よりもNew Relicの方が安い」という現象が発生する。ただし、APMが完全に不要で純粋なリソース監視のみであれば、Zabbixの運用工数は低下し、Datadogの料金も半額（Infrastructureのみ）になる点に留意されたい。
パターンC：大規模（監視対象 200台）/ 3年間のTCO
エンタープライズ、または大規模トラフィックを抱えるWebプラットフォーム。
| 費用項目 | Datadog（Pro + APM） | New Relic（Enterprise） | Zabbix（大規模分散構成） |
|---|---|---|---|
| ソフトウェア/SaaS利用料（年額） | 16,560,000円（ボリューム値引き適用前） | 5,529,600円（Full User 8名 + 転送量2.9TB） | 0円 |
| 監視サーバー基盤費用（年額） | 0円 | 0円 | 2,160,000円（分散プロキシ+高スペックDB） |
| 構築初期費用（初期工数換算） | 120,000円（20時間） | 120,000円（20時間） | 960,000円（160時間：大規模チューニング） |
| 運用保守人件費（年額） | 144,000円（月間2時間） | 144,000円（月間2時間） | 2,160,000円（月間30時間×12ヶ月×6,000円） |
| 1年目の実額TCO | 16,824,000円 | 5,793,600円 | 5,280,000円 |
| 3年間の累計TCO | 50,064,000円 | 17,140,800円 | 13,920,000円 |
分析: 200台規模に達すると、Datadogの年間費用は1,600万円（3年で5,000万円）を突破し、明確に経営課題化する水準となる。ここで初めてZabbixの自作・運用保守人件費（3年で約1,392万円）が、SaaSの利用料を下回る逆転現象が確立される。専任のSRE/インフラエンジニアを1名アサインして監視基盤の面倒を見させても、Datadogより遥かに安く、New Relicと比較しても競争力を持つ領域に入る。
🧭 【この分岐とあわせて検討したい意思決定バイブル】
関連する周辺領域の損得分岐点もあわせて確認し、全体の費用対効果を最大化してください。
- 🔗 【条件別】法人PC調達（デル・レノボ直販一括購入 vs 法人リース vs DaaS月額レンタル）の減価償却と3年TCO比較マトリクス
【損得分岐】調達台数（〜10台 vs 50台超）と固定資産税・キッティング（初期設定）廃棄工数を含めた3年間の総費用比較- 🔗 【条件別】SIEM・ログ分析（Datadog vs Splunk Cloud vs AWS CloudWatch）のログ取り込みギガ単価課金爆発防止とインシデント検知分岐マトリクス
【損得分岐】ログ取り込み容量（GB/月）ごとの課金体系（Splunk容量課金 vs Datadogインデックス分離 vs S3保管）のコスト分岐
5. 実務で直面する「3大失敗パターン」と生々しい回避策
失敗1：Zabbixの「DB容量枯渇・ハウスキーパー地獄」による監視共倒れ
発生現象: Zabbixの運用開始から約半年後、監視対象ホストの増加とメトリクス取得間隔（30秒〜1分）の過密さにより、バックエンドDB（MySQL/PostgreSQL）のディスク使用率が100%に達する。ヒストリデータを削除するプロセス（Housekeeper）のI/O負荷が限界を超え、Zabbix Serverのプロセスがクラッシュ。本番環境で障害が発生した瞬間に監視サーバー自体が停止しており、アラートが一切発報されないという最悪の二次障害を引き起こす。
泥臭い回避策:
- ヒストリ保存期間の短縮とトレンド機能の徹底: 数値の生データ（History）の保持は最大7日〜14日に制限し、長期傾向は自動集計されるTrends（1時間ごとの最小/最大/平均）に任せて365日保持する。
- DBパーティショニングの初期導入: Zabbix運用開始のDay 1から、PostgreSQLのpg_partman、あるいはMySQLのRANGEパーティショニングを導入し、日付単位でテーブルを分割する。削除時はDELETEクエリを発行せず、
DROP TABLEで瞬時にディスク領域を解放する設計を義務付ける。Housekeeperプロセスは設定で無効化（DisableHousekeeping=1）する。
失敗2：Datadogの「カスタムメトリクス爆発」による青天井請求
発生現象: 開発チームがKubernetesクラスタやアプリケーションコード内で、PrometheusのカスタムメトリクスをDatadog Agent経由で送信開始。タグ（ラベル）に「ユーザーID」「注文番号」「コンテナUUID」などカーディナリティ（値の種類数）が極めて高い属性を含めてしまった結果、Datadog上のカスタムメトリクス数が数千〜数万倍に爆発。翌月の請求書に「カスタムメトリクス超過料金：$15,000（約225万円）」が突如計上され、予算が即座に吹き飛ぶ。
泥臭い回避策:
- タグフィルタリングの厳格化:
datadog.yaml内のexclude_tags設定で、動的かつ無限に増えるID系タグを完全に除外する。 - Metric Summaryの監視と制限設定: Datadog管理画面の「Metrics Summary」を週次でチェックし、Top 10のカーディナリティを監視する。また、Datadogサポートに依頼、または管理機能で「カスタムメトリクスの上限キャップ」を設定し、上限到達時に自動で追加をドロップさせる安全弁を組み込む。
失敗3：New Relicの「Full Platform Userアカウント共有」によるガバナンス崩壊
発生現象: New Relicはデータ量課金が安価である一方、フル機能を利用できる「Full Platform User」の単価（月額$99〜$349/人）が高い。コスト削減を狙い、開発部内で1つのFull Platform Userアカウントのログイン情報を数十名で共有して運用。その結果、「誰がいつアラート通知の閾値を変更したのか」「誰が無効化（Mute）したのか」の監査ログが完全に追跡不能となり、本番重大障害のトリガー設定がいつの間にか削除されていたというインシデントが発生する。
泥臭い回避策:
- ユーザーロールの階層化運用の徹底: 実際に設定変更を行う「Core SRE（Full Platform User）」を2〜3名に限定し、一般の開発エンジニアにはクエリ実行とダッシュボード閲覧・アラート通知の確認のみが可能な「Basic User（無料）」または「Core User（低価格）」を割り振る。
- SSO（SAML）強制とSCIM連携: OktaやAzure ADと連携させ、個人アカウント以外でのログインを物理的に遮断する。設定変更はTerraform（IaC）経由のCI/CDパイプラインからのみ許可し、コンソール上での直接変更権限を制限する。
6. あなたの最適解を導く「意思決定フローチャート」
以下の4つの質問に順番に回答することで、自社が採用すべき監視基盤の客観的な結論が導かれる。
[START]
│
▼
【Q1: セキュリティ規約上、システムメトリクスやログの外部SaaSへの送信が全面的に禁止されているか？】
├─［YES］───────────────────────────────────► 【結論: Zabbix（閉域オンプレミス完全自作）】
│ （選択の余地なし。DBパーティショニングと
│ 冗長化設計に工数を確保せよ）
└─［NO］
│
▼
【Q2: インフラ運用の専任エンジニアが社内に存在し、監視サーバー自体のパッチ当てや障害保守に
毎月10〜20時間以上の工数を恒常的に割く余力（または外部保守契約）があるか？】
├─［NO］ ──► 【SaaS監視（Datadog / New Relic）が確定】
│ │
│ ▼
│ 【Q3: アプリケーションのボトルネック追跡（APM・分散トレーシング）を全台で深く行いたいか？】
│ ├─［YES］──► 【結論: New Relic】
│ │ （APM導入に伴うホスト追加費用がなく、
│ │ データインジェスト課金によりTCOを最小化可能）
│ │
│ └─［NO: インフラ死活・ログ監視が主］──► 【結論: Datadog（Infrastructure Proのみ）】
│ （圧倒的なクラウド連携の簡易さと
│ UXの直感性で運用負荷を極小化）
│
└─［YES］
│
▼
【Q4: 監視対象のサーバー・コンテナノードの台数は定常的に50台を超えているか？】
├─［NO: 50台未満］ ──► 【結論: New Relic または Datadog】
│ （専任者がいても、50台未満なら自作監視のサーバー代＋保守人件費の方が
│ SaaSの利用料より高くつくため自作は経済的に非合理）
│
└─［YES: 50台超〜数百台］
│
▼
【APMの要求レベルはどの程度か？】
├─［高度なAPM・分散トレースが全システムで必須］ ──► 【結論: New Relic】
│ （Datadogだとホスト課金で破綻、
│ ZabbixだとAPM構築が泥沼化する）
│
└─［死活・リソース・SNMP監視が主、APMは不要か局所的］ ──► 【結論: Zabbix（自作構成）】
（ホスト増に伴うSaaSの青天井課金を完全回避し、
内製インフラ要員の価値を最大化）
7. 現場で迷ったときのFAQ（よくある質問5選とズバリ回答）
Q1. ZabbixでAPM（分散トレーシング）を実現することは本当に不可能なのか？
A. 不可能ではないが、極めて非推奨。 Zabbix単体にはAPM機能は存在しない。実現するには、OpenTelemetry Collectorを各サーバーに導入し、トレースデータをJaegerやGrafana Tempoに流し、可視化のためにGrafanaを連携させ、それらすべてのバックエンドストレージ（ElasticsearchやClickHouse）を自前で運用保守する必要がある。この構成を組んだ場合、監視基盤の保守工数は月間40時間〜60時間を超え、シニアSREの稼働を丸ごと1名分消費する。結果としてDatadogやNew Relicに毎月100万円支払うよりも確実に高コスト化する。
Q2. DatadogとNew Relicの二者択一で、最も決定打となる判断基準は何か？
A. 「APMを適用するホストの比率」と「監視に関わるエンジニアの人数」である。 全ホスト（例：50台）に対してAPMと分散トレーシングを常時適用したい場合、Datadogはホストあたり月額$46（約6,900円）が固定で積み上がるため跳ね上がる。New Relicはデータ量課金（$0.30/GB）のため、ホスト数が増えてもデータ送信量を絞れば費用は数分の一で済む。 逆に、エンジニアが20名以上おり、全員にダッシュボードの自由な編集やアラート設定権限（Full Platform User）を与えたい場合、New Relicはユーザー課金（1人あたり月額数十ドル〜数百ドル）が爆発する。ユーザー数が多くAPMが一部のみならDatadog、ホスト数が多くAPMを全台に適用したいならNew Relicが有利である。
Q3. クラウドベンダー純正の監視（AWS CloudWatch / GCP Cloud Monitoring）だけで済ませる選択肢はどうか？
A. 10台未満の単純なシステムなら推奨。ただし、マルチクラウドやAPMを求める段階で破綻する。 CloudWatchはエージェントレスでEC2やRDSのメトリクスが取れるため初期費用は最も安い。しかし、カスタムメトリクス（1メトリクスあたり$0.30）、APIリクエスト費用、CloudWatch Logsの取り込み（$0.50/GB）と検索費用が極めて高額であり、ログ量が増えるとDatadog以上の請求が発生することが実務上多発する。また、コンテナの分散トレーシング（X-Ray）のUI/UXは専業SaaSに遠く及ばない。
Q4. Zabbixのバージョンアップ（例: 6.0 LTSから7.0 LTS）の工数はどの程度見積もるべきか？
A. ステージング検証を含め、最低でも「40人時〜80人時（エンジニア実働1〜2週間分）」を見込む必要がある。 Zabbixのメジャーバージョンアップは、DBスキーマのマイグレーションを伴う。数億レコード規模のヒストリテーブルを抱えている場合、DBマイグレーションだけで数時間〜半日システム停止（監視停止）が発生するリスクがある。また、古いエージェントとの後方互換性検証、非推奨となった監視プラグイン・スクリプトの改修テストが必須となる。この移行工数（時給6,000円換算で24万〜48万円相当）を年次TCOに必ず算入しなければならない。
Q5. 監視データ（ログ・メトリクス）の転送による「クラウドのアウトバウンド通信費」は見落とされがちだが、どの程度影響するか？
A. 1ホストあたり月額数百円レベルだが、ログを大量に吐くシステムでは無視できない。 AWSからインターネット（Datadog/New RelicのSaaSエンドポイント）へ送信する場合、データ転送アウト（約$0.114/GB ※東京リージョン）が課金される。 例えば1ホストが月間100GBのメトリクス・トレース・ログをSaaSに送信した場合、AWS側のデータ転送費だけで約$11.4（約1,700円）/台が毎月上乗せされる。100台規模では通信費だけで月間17万円に達する。社内同一VPC/閉域網に立てたZabbix ServerへプライベートIP経由で送信する場合はこのアウトバウンド費用がゼロになるため、大規模環境下では無視できないコスト差異要因となる。
8. 結論と今すぐできるアクションプラン
サーバー監視・APMの選定における損得分岐の結論は以下の通りである。
- ホスト数1〜50台規模の組織: 迷わずSaaS（New Relic または Datadog）を選択せよ。この規模でZabbixを自作・保守することは、エンジニアの貴重な工数を「事業価値を直接生まないインフラ保守」にドブ捨てすることと同義である。特にAPMを重視するならNew Relic、インフラの可視化と運用の平易さを最優先するならDatadogが最適解となる。
- ホスト数50〜200台超で、APMが不要な基幹・オンプレミス組織: 専任エンジニアを配置した上でのZabbixセルフホスト運用が最もTCOが低い。ただし、DBパーティショニングの初期実装と、ヒストリ保持期間の厳格な設計を行わなければ、運用開始半年でDB枯渇の障害対応に忙殺されることになる。
- 50台以上のクラウドネイティブ/マイクロサービス組織: New Relicが最もコストと機能のバランスが良い。全台にAPMを入れつつ、データ送信量のサンプリングレート調整を行うことで、Datadogの半額以下のコストで最高水準の可観測性を手に入れることができる。
今すぐ実行すべき3つのアクションプラン
- Step 1: 自社インフラの正確なホスト数とAPM要求の仕分け 全サーバーのうち、「単なる死活・リソース監視で十分な台数」と「コードレベルのAPM（分散トレース）が必須な台数」をスプレッドシートにリストアップする。
- Step 2: 現行の監視運用にかかっている「隠れ人件費」の算出 インフラ担当者が監視基盤自体のパッチ当て、Zabbixのアラート誤検知対応、ディスク容量拡張に過去3ヶ月で何時間使ったかをヒアリングし、自社の時給単価を掛けて実質コストを可視化する。
- Step 3: New RelicおよびDatadogの無料トライアルによるデータ送信量計測 代表的な本番ホスト3〜5台にエージェントを試験導入し、1台あたり「1日何ギガバイトのデータが送信されるか」を実測する。この実測値を持って、本稿第4章のシミュレーション式に当てはめ、社内稟議用の損得分岐レポートを作成する。