システム監視・可観測性ガイド｜Datadog・New Relic・Grafanaの比較と導入方法

「サービスダウンをユーザーからの報告で初めて知った」「障害の原因特定に毎回数時間かかる」「サーバーのリソース状況を誰も把握していない」。こうした状況は、システム監視体制の不備が原因だ。

システムの安定運用には、適切な監視と可観測性（Observability）の確保が不可欠である。本記事では、監視と可観測性の概念整理から、主要3製品の比較、実践的なアラート設計、費用シミュレーションまで、中小企業が導入すべき監視体制を解説する。

---

監視（Monitoring）と可観測性（Observability）の違い

監視とは

監視は「既知の問題を検出する」ための仕組みだ。事前に定義した閾値を超えた場合にアラートを発報する。

例:

• CPU使用率が80%を超えたら通知
• ディスク容量が90%を超えたら通知
• HTTPレスポンスの5xxエラー率が1%を超えたら通知

監視は「何が起きたか」を教えてくれるが、「なぜ起きたか」を教えてくれるとは限らない。

可観測性とは

可観測性は「未知の問題を調査・特定できる」能力だ。システムの内部状態を外部から推測できる度合いを指す。

可観測性が高いシステムでは、以下のことが可能になる。

• 障害発生時に原因を迅速に特定できる
• パフォーマンス劣化の根本原因を追跡できる
• 予期しない動作パターンを発見できる

両者の関係

監視は可観測性の一部だ。監視だけでは「閾値を超えた」ことしか分からないが、可観測性が確保されていれば「なぜ閾値を超えたのか」「どのコンポーネントが原因なのか」まで追跡できる。

---

可観測性の3つの柱

1. メトリクス（Metrics）

数値で表されるシステムの状態。時系列データとして蓄積され、傾向分析やアラートに使用する。

インフラメトリクス:

• CPU使用率、メモリ使用率、ディスクI/O
• ネットワーク帯域、パケットロス率

アプリケーションメトリクス:

• リクエスト数（RPS: Requests Per Second）
• レスポンスタイム（p50, p95, p99）
• エラー率
• アクティブセッション数

ビジネスメトリクス:

• 注文数、売上金額
• ユーザー登録数
• コンバージョン率

2. ログ（Logs）

システムが出力するテキスト形式の記録。障害発生時の詳細調査に不可欠だ。

構造化ログの重要性:

非構造化ログ（従来型）:

構造化ログ（推奨）:

構造化ログにすることで、検索、フィルタリング、集計が容易になる。

3. トレース（Traces）

分散システムにおけるリクエストの処理経路を追跡する仕組み。マイクロサービスやサーバーレスアーキテクチャでは、1つのリクエストが複数のサービスを横断するため、ボトルネックの特定にトレースが必須となる。

トレースにより、どのサービスで時間がかかっているかを一目で把握できる。

---

主要3製品の比較

Datadog

概要: SaaS型の統合監視プラットフォーム。インフラ監視、APM（アプリケーション性能管理）、ログ管理、セキュリティ監視を1つのプラットフォームで提供する。

強み:

• 750以上のインテグレーション（AWS, GCP, Azure, Kubernetes等）
• 直感的なダッシュボードUI
• AI/MLベースの異常検知
• リアルタイムログ分析

弱み:

• 費用が高い（特にログ量が多い場合）
• 機能が多く、初期設定の学習コストがある

料金体系（2026年4月時点の目安）:

• Infrastructure: ホストあたり月額約2,300円〜
• APM: ホストあたり月額約5,000円〜
• Log Management: 取り込み1GBあたり月額約250円 + 保持1GBあたり月額約350円

New Relic

概要: フルスタック型の可観測性プラットフォーム。2020年にユーザー数無制限の料金体系に刷新し、中小企業にも導入しやすくなった。

強み:

• 無料枠が充実（月100GBのデータ取り込み）
• ユーザー数ベースのシンプルな料金体系
• APM機能の完成度が高い
• エラートラッキング機能が標準搭載

弱み:

• インフラ監視はDatadogに比べてやや弱い
• カスタムダッシュボードの柔軟性がDatadogに劣る
• 独自クエリ言語（NRQL）の学習が必要

料金体系（2026年4月時点の目安）:

• 無料枠: 月100GBのデータ取り込み + 1フルプラットフォームユーザー
• Standard: フルプラットフォームユーザーあたり月額約15,000円
• データ超過分: 1GBあたり約50円

Grafana（+ Prometheus + Loki）

概要: オープンソースの可視化プラットフォーム。メトリクス収集（Prometheus）、ログ管理（Loki）、トレース（Tempo）を組み合わせて使用する。Grafana Cloudとしてマネージドサービスも提供している。

強み:

• OSS版は完全無料
• ダッシュボードのカスタマイズ性が極めて高い
• 多様なデータソースに対応
• ベンダーロックインのリスクが低い

弱み:

• 自前運用の場合、構築・運用に専門知識が必要
• 複数ツールの組み合わせが前提で、初期構築の手間がかかる
• APM機能は別途導入が必要

料金体系（2026年4月時点の目安）:

• OSS版: 無料（インフラ費用は自社負担）
• Grafana Cloud Free: メトリクス10,000シリーズ、ログ50GB/月
• Grafana Cloud Pro: 月額約4,000円〜

3製品の比較表

項目	Datadog	New Relic	Grafana Cloud
導入の容易さ	簡単	簡単	やや難しい
メトリクス監視	優秀	良好	優秀
APM	優秀	優秀	要別途導入
ログ管理	優秀	良好	良好
分散トレーシング	優秀	優秀	良好
ダッシュボード	優秀	良好	最も柔軟
無料枠	14日間トライアル	月100GB	充実
月額費用（5台規模）	約5〜8万円	約2〜4万円	約0.5〜2万円
適する企業	中〜大規模	中小企業	技術力のある企業

---

中小企業への推奨

パターン1: 技術者がいない場合 → New Relic

無料枠が充実しており、小規模な環境であれば無料で始められる。SaaSのため構築・運用の手間がなく、APM機能が標準搭載されている。

パターン2: 技術力があり費用を抑えたい場合 → Grafana Cloud

Grafana Cloudの無料枠で基本的な監視を開始し、必要に応じてProプランに移行する。カスタマイズ性が高く、長期的なコスト効率が良い。

パターン3: 本格的な監視体制を構築する場合 → Datadog

予算が確保でき、包括的な監視を実現したい場合の選択肢。統合されたプラットフォームで、監視の一元管理が可能。

---

アラート設計のベストプラクティス

アラート疲れを防ぐ

過剰なアラートは「狼少年」状態を招く。重要なアラートが埋もれ、結果的に障害対応が遅れる原因となる。

アラートの分類:

レベル	条件	通知先	対応
Critical	サービス停止、データ損失の危険	電話・SMS	即時対応
Warning	パフォーマンス劣化、閾値接近	チャットツール	営業時間内に対応
Info	参考情報、傾向変化	ダッシュボード表示のみ	定期確認

SLI/SLO ベースのアラート

個別のメトリクスに閾値を設定するのではなく、サービスレベル指標（SLI）とサービスレベル目標（SLO）に基づいたアラートを設計する。

例:

• SLI: APIのレスポンスタイム（p99）
• SLO: p99が500ms以下を99.9%の時間で維持する
• アラート: エラーバジェット（許容される違反時間）の50%を消費した時点でWarning、80%でCritical

アラートに必要な情報

アラートメッセージには、以下の情報を含めるべきだ。

1. 何が起きているか: 具体的な症状の説明
2. 影響範囲: どのサービス・ユーザーに影響があるか
3. 確認手順: ダッシュボードやログへのリンク
4. 対応手順: ランブック（対応手順書）へのリンク

---

費用シミュレーション

想定環境

• Webサーバー: 3台
• データベース: 1台
• アプリケーション: 1サービス
• 月間ログ量: 50GB
• 監視対象メトリクス: 500種類

年間費用比較

項目	Datadog	New Relic	Grafana Cloud
インフラ監視	110,400円	0円（無料枠内）	0円（無料枠内）
APM	240,000円	180,000円	別途構築費用
ログ管理	150,000円	0円（50GB無料枠内）	48,000円
年間合計	約500,400円	約180,000円	約48,000円

New Relicは無料枠の活用で大幅にコストを抑えられる。Grafana Cloudは最もコスト効率が良いが、構築・カスタマイズの工数を考慮する必要がある。

---

導入ステップ

Step 1: 現状把握（1週間）

• 監視対象のシステム構成を整理する
• 現在発生している障害の種類と頻度を洗い出す
• チームのスキルレベルと運用体制を確認する

Step 2: ツール選定とPoC（2〜3週間）

• 上記の比較表を参考にツールを選定する
• 無料枠またはトライアルで検証環境に導入する
• 基本的なダッシュボードとアラートを設定する

Step 3: 本番導入（2〜4週間）

• エージェントやSDKを本番環境にインストールする
• アプリケーションに計装（Instrumentation）を追加する
• アラートの通知先とエスカレーションルールを設定する

Step 4: 運用改善（継続的）

• アラートの発報状況を定期的にレビューする
• 不要なアラートを削除し、必要なアラートを追加する
• ダッシュボードをチームの運用に合わせて改善する
• インシデント発生時の対応フローを整備する

---

まとめ

システム監視と可観測性の確保は、安定したサービス運用の基盤だ。重要なポイントを整理する。

• 監視は「既知の問題検出」、可観測性は「未知の問題調査」。両方が必要
• メトリクス・ログ・トレースの3つの柱でシステムの内部状態を把握する
• 中小企業の第一選択はNew Relic（無料枠が充実）またはGrafana Cloud（コスト最小）
• アラート設計はSLI/SLOベースで行い、アラート疲れを防ぐ
• まずは小さく始め、運用しながら改善を続ける

障害が起きてからでは遅い。今のうちに監視体制を構築し、サービスの信頼性を高めてほしい。