システムやアプリケーションを運用していると、「サーバーは正常に動いているか？」「アプリケーションのパフォーマンスは？」「ログにエラーは出ていないか？」といった疑問に、常に答える必要があります。これらを個別のツールで管理すると、画面を行ったり来たりして非効率ですよね。
そこで登場するのがDatadog（データドッグ）です。Datadogは、インフラ監視、アプリケーション性能監視（APM）、ログ管理、セキュリティ監視など、システム運用に必要なすべての機能を1つのプラットフォームで提供するSaaS型の統合監視サービスなんです。
2010年に創業したDatadogは、現在では世界中の27,000社以上が利用する、クラウド時代を代表する監視プラットフォームとなっています。AirbnbやPeloton、Samsungなどの大企業から、スタートアップまで幅広く採用されています。
最大の魅力は、すぐに使い始められる手軽さと、美しく分かりやすいダッシュボード、そして600以上の統合（Integration）により、あらゆるテクノロジースタックを一箇所で監視できること。エージェントをインストールするだけで、数分後には詳細なメトリクスが可視化されます。
この記事では、Datadogの基本から、実際の導入方法、料金体系、他のツールとの比較まで、初心者の方にも分かりやすく解説していきます！
Datadogとは？基本概念を理解する
まず、Datadogが何なのか、基本から押さえましょう。
Datadogの定義
Datadog（データドッグ）は、SaaS型のクラウドベース監視・分析プラットフォームです。
主な特徴：
- 創業： 2010年（ニューヨーク）
- 創業者： Olivier Pomel、Alexis Lê-Quôc
- 本社： アメリカ・ニューヨーク
- 上場： 2019年（NASDAQ: DDOG）
- 公式サイト： https://www.datadoghq.com/
- 利用企業数： 27,000社以上（2024年時点）
- タイプ： フルマネージドSaaS
SaaS型監視の利点
従来型（オンプレミス）との違い：
従来型（Prometheus、Zabbixなど）：
セットアップ:
1. サーバーを用意
2. ソフトウェアをインストール
3. データベースを設定
4. 可視化ツール（Grafana等）を別途構築
5. バックアップ・冗長化を設定
6. 定期的なメンテナンス
→ 時間とコストがかかるSaaS型（Datadog）：
セットアップ:
1. アカウント作成（1分）
2. エージェントをインストール（5分）
3. 完了！
→ すぐに使い始められる
→ インフラ管理不要
→ 自動アップデートオブザーバビリティ・プラットフォーム
オブザーバビリティの3本柱を統合：
┌─────────────────────────────────────┐
│ Datadog Platform │
├─────────────────────────────────────┤
│ 1. Metrics（メトリクス） │
│ → Infrastructure Monitoring │
│ │
│ 2. Traces（トレース） │
│ → Application Performance │
│ Monitoring (APM) │
│ │
│ 3. Logs（ログ） │
│ → Log Management │
└─────────────────────────────────────┘
↓ 統合ダッシュボード ↓さらに追加機能：
- セキュリティ監視
- リアルユーザーモニタリング（RUM）
- ネットワーク監視
- Database Monitoring
- CI/CD監視
Datadogの主要機能
Datadogが提供する主要な機能を見ていきましょう。
1. Infrastructure Monitoring（インフラ監視）
サーバーやコンテナのリソース監視：
監視対象：
- 物理サーバー／仮想マシン
- CPU使用率
- メモリ使用量
- ディスクI/O
- ネットワークトラフィック
- コンテナ／Kubernetes
- Pod数
- コンテナのリソース使用状況
- ノードの健全性
- クラスターメトリクス
- クラウドサービス
- AWS EC2、RDS、Lambda等
- Google Cloud Compute、GKE等
- Azure VM、AKS等
特徴：
- リアルタイム監視（1秒間隔も可能）
- ホストマップで視覚的に把握
- 自動的にタグ付け（環境、サービス、チームなど）
ホストマップの例：
視覚的なヒートマップ:
┌──────┐ ┌──────┐ ┌──────┐
│ 🟢 │ │ 🟢 │ │ 🟡 │ ← CPU使用率で色分け
│Web-1 │ │Web-2 │ │Web-3 │
└──────┘ └──────┘ └──────┘
┌──────┐ ┌──────┐
│ 🔴 │ │ 🟢 │ ← 赤は問題あり
│App-1 │ │App-2 │
└──────┘ └──────┘
緑：正常（0-60%）
黄：注意（60-80%）
赤：警告（80%以上）2. Application Performance Monitoring（APM）
アプリケーションのパフォーマンス監視：
主な機能：
分散トレーシング：
ユーザーのリクエスト1つを追跡:
HTTP Request → Web Server → App Server → Database
↓ ↓ ↓ ↓
10ms 50ms 200ms 150ms
↑
ボトルネックを特定！自動計測：
- リクエスト数
- レスポンス時間（p50、p75、p95、p99）
- エラー率
- スループット
サービスマップ：
サービス間の依存関係を可視化:
[Frontend] ──→ [API Gateway] ──→ [Auth Service]
↓ ↓
└──────→ [User Service] ──→ [Database]
↓
[Cache (Redis)]対応言語：
- Java
- Python
- Ruby
- Go
- Node.js
- PHP
- .NET
- その他多数
導入例（Pythonの場合）：
# ddtraceライブラリをインストール
# pip install ddtrace
# アプリケーションを起動時にトレーシングを有効化
ddtrace-run python app.py
# または手動で
from ddtrace import tracer
@tracer.wrap()
def my_function():
# 自動的にトレース
pass3. Log Management（ログ管理）
ログの収集・検索・分析：
主な機能：
ログ収集：
- アプリケーションログ
- システムログ
- アクセスログ
- エラーログ
- 監査ログ
ログ処理：
生ログ:
2025-10-26 10:30:15 ERROR [UserService] Failed to create user: email=test@example.com error=DatabaseConnectionError
Datadogでの表示:
┌───────────────────────────────────────────┐
│ Timestamp: 2025-10-26 10:30:15 │
│ Level: ERROR │
│ Service: UserService │
│ Message: Failed to create user │
│ email: test@example.com │
│ error: DatabaseConnectionError │
└───────────────────────────────────────────┘
→ 構造化され、検索・フィルタリングが容易ログ分析：
- パターン検出（同じエラーの頻度）
- ログベースのメトリクス生成
- トレースとの紐付け
例：ログからメトリクスを生成
エラーログの数をカウント:
count(*) where status:error
→ グラフ化してダッシュボードに表示
→ しきい値を超えたらアラート4. Real User Monitoring（RUM）
実際のユーザー体験を監視：
収集データ：
- ページロード時間
- JavaScriptエラー
- ユーザーセッション
- クリックやスクロールなどのインタラクション
- Core Web Vitals（LCP、FID、CLS）
導入方法：
<!-- HTMLにスニペットを追加 -->
<script>
(function(h,o,u,n,d) {
h=h[d]=h[d]||{q:[],onReady:function(c){h.q.push(c)}}
d=o.createElement(u);d.async=1;d.src=n
n=o.getElementsByTagName(u)[0];n.parentNode.insertBefore(d,n)
})(window,document,'script','https://www.datadoghq-browser-agent.com/datadog-rum.js','DD_RUM')
DD_RUM.onReady(function() {
DD_RUM.init({
applicationId: 'YOUR_APP_ID',
clientToken: 'YOUR_CLIENT_TOKEN',
site: 'datadoghq.com',
service: 'my-web-app',
env: 'production',
sessionSampleRate: 100,
sessionReplaySampleRate: 20,
trackUserInteractions: true,
})
})
</script>セッションリプレイ：
- ユーザーの操作を動画のように再生
- エラー発生時の状況を正確に把握
5. Security Monitoring
セキュリティ脅威の検出：
機能：
- Cloud Security Posture Management（CSPM）
- クラウド設定の不備を検出
- コンプライアンス違反の警告
- Application Security Management（ASM）
- SQLインジェクション検出
- XSS攻撃の監視
- 不正アクセスの検出
- Cloud Workload Security（CWS）
- ランタイムセキュリティ
- ファイル整合性監視
- プロセス監視
6. Network Performance Monitoring
ネットワークトラフィックの可視化：
監視対象：
- サービス間の通信
- レイテンシ
- パケットロス
- トラフィック量
DNSモニタリング：
- DNS解決時間
- DNS失敗率
7. Database Monitoring
データベースのパフォーマンス監視：
対応データベース：
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- MongoDB
監視内容：
- 遅いクエリの特定
- クエリ実行計画
- インデックス使用状況
- ロック状況
8. Synthetic Monitoring
外部からのエンドポイント監視：
機能：
- API Test：定期的にAPIを呼び出して応答を確認
- Browser Test：自動化されたブラウザテスト
例：API監視
設定:
- URL: https://api.example.com/health
- Method: GET
- 頻度: 1分ごと
- 監視地点: 東京、シンガポール、米国
チェック項目:
- ステータスコードが200か
- レスポンス時間が500ms以下か
- JSON内の特定フィールドの値が正しいかDatadogのアーキテクチャ
Datadogがどのように動作するか見ていきましょう。
全体構成図
┌────────────────────────────────────────┐
│ 監視対象（お客様の環境） │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Server 1 │ │ Server 2 │ │
│ │ ┌──────┐ │ │ ┌──────┐ │ │
│ │ │Agent │ │ │ │Agent │ │ │
│ │ └───┬──┘ │ │ └───┬──┘ │ │
│ └─────┼────┘ └─────┼────┘ │
│ │ │ │
│ ┌─────┴─────────────┴─────┐ │
│ │ Datadog Agent │ │
│ │ - メトリクス収集 │ │
│ │ - ログ収集 │ │
│ │ - トレース収集 │ │
│ │ - プロセス監視 │ │
│ └──────────┬────────────────┘ │
└─────────────┼──────────────────────────┘
│ HTTPS
│ (暗号化された通信)
↓
┌─────────────────────────────────────────┐
│ Datadog Cloud Platform │
│ (SaaS - Datadogが管理) │
│ │
│ ┌──────────────────────────────────┐ │
│ │ Data Ingestion │ │
│ │ - メトリクス受信 │ │
│ │ - ログ受信 │ │
│ │ - トレース受信 │ │
│ └────────────┬─────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────┐ │
│ │ Data Processing & Storage │ │
│ │ - データ集計 │ │
│ │ - インデックス作成 │ │
│ │ - 時系列データベース │ │
│ └────────────┬─────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────┐ │
│ │ Analytics & Alerting │ │
│ │ - クエリ実行 │ │
│ │ - アラート評価 │ │
│ │ - 異常検知（AI/ML） │ │
│ └────────────┬─────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────┐ │
│ │ API & Web UI │ │
│ │ - ダッシュボード │ │
│ │ - アラート通知 │ │
│ │ - REST API │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────┘
↓
┌──────────────┐
│ ユーザー │
│ (ブラウザ) │
└──────────────┘Datadog Agentの役割
Agentは軽量なデーモンプロセス：
主な機能：
- メトリクス収集
- システムメトリクス（CPU、メモリなど）
- 統合メトリクス（Nginx、MySQL、Redisなど）
- カスタムメトリクス
- ログ収集
- ファイルからのログ読み取り
- Docker/Kubernetesログ
- Syslogリスナー
- トレース収集
- APMトレースの転送
- プロセス監視
- 実行中のプロセス一覧
- リソース使用状況
リソース使用量：
CPU: 通常 < 1%
メモリ: 100-200MB程度
ネットワーク: 数KB/秒（圧縮済み）
→ 非常に軽量で本番環境でも安心データの流れ
1. Agent が15秒ごとにメトリクスを収集
↓
2. データを集約・圧縮
↓
3. HTTPS経由でDatadogクラウドに送信
↓
4. Datadogがデータを処理・保存
↓
5. ほぼリアルタイムでダッシュボードに反映
（通常1-2秒の遅延）Datadogの導入方法
実際にDatadogを使い始める手順です。
ステップ1：アカウント作成
- https://www.datadoghq.com/ にアクセス
- 「Start Free Trial」をクリック
- メールアドレスとパスワードを入力
- 14日間の無料トライアル開始
リージョン選択：
- US1（アメリカ）
- US3（アメリカ）
- US5（アメリカ）
- EU1（ヨーロッパ）
- AP1（日本）← 日本企業はこちらを推奨
ステップ2：Agentのインストール
Linux（Ubuntu/Debian）の場合：
# Datadogのインストールスクリプトを実行
DD_API_KEY=YOUR_API_KEY_HERE DD_SITE="ap1.datadoghq.com" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"
# Agentの起動確認
sudo systemctl status datadog-agent
# 設定を確認
sudo datadog-agent statusmacOSの場合：
# Homebrewでインストール
brew install --cask datadog-agent
# API Keyを設定
sudo sh -c "sed 's/api_key:.*/api_key: YOUR_API_KEY_HERE/' \"/opt/datadog-agent/etc/datadog.yaml.example\" > \"/opt/datadog-agent/etc/datadog.yaml\""
# Agentを起動
launchctl load -w /Library/LaunchDaemons/com.datadoghq.agent.plistWindowsの場合：
# PowerShellで実行
Start-Process -Wait msiexec -ArgumentList '/qn /i datadog-agent-7-latest.amd64.msi APIKEY="YOUR_API_KEY_HERE" SITE="ap1.datadoghq.com"'
# サービスの確認
Get-Service -Name datadogagentDockerの場合：
docker run -d --name datadog-agent \
-e DD_API_KEY=YOUR_API_KEY_HERE \
-e DD_SITE="ap1.datadoghq.com" \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-v /proc/:/host/proc/:ro \
-v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
gcr.io/datadoghq/agent:latestKubernetesの場合：
# Helmを使用
helm repo add datadog https://helm.datadoghq.com
helm repo update
# values.yamlを作成
cat <<EOF > datadog-values.yaml
datadog:
apiKey: YOUR_API_KEY_HERE
site: ap1.datadoghq.com
logs:
enabled: true
apm:
enabled: true
processAgent:
enabled: true
EOF
# インストール
helm install datadog-agent datadog/datadog \
-f datadog-values.yaml \
--namespace datadog \
--create-namespaceステップ3：統合（Integration）の設定
600以上の統合が利用可能：
人気の統合例：
1. Nginx監視：
# /etc/datadog-agent/conf.d/nginx.d/conf.yaml
init_config:
instances:
- nginx_status_url: http://localhost/nginx_status/
tags:
- instance:my-nginx# Nginx側でstatus pageを有効化
# /etc/nginx/sites-available/default に追加
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
# Agentを再起動
sudo systemctl restart datadog-agent2. MySQL監視：
# /etc/datadog-agent/conf.d/mysql.d/conf.yaml
init_config:
instances:
- host: localhost
port: 3306
username: datadog
password: YOUR_PASSWORD
options:
replication: true
galera_cluster: false-- MySQL側でDatadog用のユーザーを作成
CREATE USER 'datadog'@'localhost' IDENTIFIED BY 'YOUR_PASSWORD';
GRANT REPLICATION CLIENT ON *.* TO 'datadog'@'localhost';
GRANT PROCESS ON *.* TO 'datadog'@'localhost';
GRANT SELECT ON performance_schema.* TO 'datadog'@'localhost';
FLUSH PRIVILEGES;3. Redis監視：
# /etc/datadog-agent/conf.d/redisdb.d/conf.yaml
init_config:
instances:
- host: localhost
port: 6379
password: YOUR_REDIS_PASSWORD # パスワードが設定されている場合ステップ4：カスタムメトリクスの送信
Pythonの例：
from datadog import initialize, statsd
# 初期化
options = {
'api_key': 'YOUR_API_KEY',
'app_key': 'YOUR_APP_KEY'
}
initialize(**options)
# メトリクスを送信
statsd.increment('myapp.page.views') # カウンターを増加
statsd.gauge('myapp.queue.size', 25) # ゲージ値を設定
statsd.histogram('myapp.response.time', 0.234) # ヒストグラム
# タグ付き
statsd.increment('myapp.login.success', tags=['env:production', 'region:ap'])Node.jsの例：
const StatsD = require('hot-shots');
const dogstatsd = new StatsD();
// メトリクスを送信
dogstatsd.increment('myapp.page.views');
dogstatsd.gauge('myapp.queue.size', 25);
dogstatsd.histogram('myapp.response.time', 0.234);
// タグ付き
dogstatsd.increment('myapp.login.success', 1, ['env:production', 'region:ap']);ダッシュボードの作成
データを可視化してみましょう。
ダッシュボードの種類
1. Screenboard（スクリーンボード）
- 自由なレイアウト
- ドラッグ&ドロップで配置
- プレゼンテーション向き
2. Timeboard（タイムボード）
- グリッドレイアウト
- 時間軸が統一
- トラブルシューティング向き
ダッシュボードの作成手順
1. 新規ダッシュボード作成
Dashboards → New Dashboard
→ 名前を入力（例：「Production Infrastructure」）
→ レイアウトを選択2. ウィジェットを追加
Timeseriesグラフ（時系列グラフ）：
Add Widget → Timeseries
メトリクス:
avg:system.cpu.user{env:production} by {host}
表示設定:
- ライン表示
- 色: 自動
- 凡例: ホスト名クエリ例：
# CPU使用率の平均
avg:system.cpu.user{*} by {host}
# メモリ使用率
(avg:system.mem.total{*} - avg:system.mem.usable{*}) / avg:system.mem.total{*} * 100
# HTTPリクエスト数（5分間の平均）
avg:trace.requests.hits{service:myapp}.rollup(sum, 300)
# エラー率
(sum:trace.requests.errors{service:myapp}.as_count() / sum:trace.requests.hits{service:myapp}.as_count()) * 1003. その他のウィジェット
ヒートマップ：
- レスポンス時間の分布
- レイテンシの可視化
Top List（ランキング）：
- 最もCPUを消費しているホスト
- 最も遅いエンドポイント
Query Value（数値表示）：
- 現在のアクティブユーザー数
- 今日のエラー数
ホストマップ：
- サーバーの健全性を視覚的に表示
テンプレート変数
動的なダッシュボード：
設定:
Name: $env
Tag: env
Default: production
使用:
avg:system.cpu.user{env:$env} by {host}
→ ドロップダウンで環境を切り替え
production / staging / developmentアラート設定
問題を自動的に検出して通知しましょう。
モニターの種類
1. Metric Monitor
- メトリクスのしきい値監視
- 最も一般的
2. Anomaly Monitor
- AI/MLによる異常検知
- 通常パターンから逸脱を検出
3. Outlier Monitor
- 他のホストと比べて異常なホストを検出
4. Forecast Monitor
- 将来の値を予測してアラート
5. Log Monitor
- ログパターンの検出
6. APM Monitor
- トレースメトリクスの監視
モニターの作成例
CPU使用率監視：
Monitors → New Monitor → Metric
設定:
1. Define the metric:
avg:system.cpu.user{env:production} by {host}
2. Set alert conditions:
Alert threshold: > 80
Warning threshold: > 60
3. Say what's happening:
Name: {{host.name}} High CPU Usage
Message:
{{#is_alert}}
CPU usage is {{value}}% on {{host.name}}
@slack-alerts-critical
{{/is_alert}}
{{#is_warning}}
CPU usage is {{value}}% on {{host.name}}
@slack-alerts-warning
{{/is_warning}}
4. Notify your team:
- Slack channel
- Email
- PagerDutyエラー率監視（Anomaly Detection）：
Monitors → New Monitor → Anomaly
設定:
avg:trace.requests.errors{service:myapp}.as_rate()
Anomaly Detection:
- Algorithm: Agile
- Seasonality: Weekly
- Alert threshold: 3 deviations
- Warning threshold: 2 deviations
→ 通常のパターンから大きく外れたら通知通知チャンネルの設定
Slack連携：
Integrations → Slack → Connect Account
チャンネル設定:
#alerts-critical → 重大なアラート
#alerts-warning → 警告レベル
#alerts-info → 情報PagerDuty連携：
Integrations → PagerDuty → Configure
シビラティ別にルーティング:
Critical → On-call エンジニアに即座に電話
Warning → Slack通知のみWebhook（カスタム）：
POST https://your-endpoint.com/webhook
{
"title": "{{event_title}}",
"message": "{{event_msg}}",
"priority": "{{priority}}",
"tags": {{tags}}
}料金体系
Datadogの料金について理解しましょう。
基本的な料金モデル
従量課金制：
- ホスト数（サーバー／コンテナ数）
- ログ量（取り込んだログのGB数）
- APMスパン数
- カスタムメトリクス数
主要プランの料金（2024年時点）
Infrastructure Monitoring：
Free:
- 5ホストまで
- 1日のメトリクス保持
- 基本的な統合
Pro: $15/ホスト/月
- 無制限のホスト
- 15ヶ月のメトリクス保持
- 高度な統合
- アラート機能
Enterprise: $23/ホスト/月
- Proの全機能
- SAML/SSO
- 監査ログ
- サポート優先度高APM（Application Performance Monitoring）：
Pro: $31/ホスト/月
- 15ヶ月の保持
- 1ホストあたり月150万スパン含む
- 追加スパン: $1.70/100万スパン
Enterprise: $40/ホスト/月
- 高度な機能
- 延長サポートLog Management：
Ingest: $0.10/GB（取り込み）
Index: $1.70/GB/月（検索可能な状態で保存）
Retention: 15日〜15ヶ月（プランによる）
コスト削減テクニック:
- ログをフィルタリング
- 重要なログのみインデックス化
- 古いログはアーカイブ（S3等）Real User Monitoring（RUM）：
$1.50/1,000セッション
例:
月100万PV（セッション数: 50万）
→ $750/月料金シミュレーション例
中規模Webアプリケーション：
環境:
- ホスト数: 20台
- APM有効ホスト: 10台
- ログ取り込み: 500GB/月
- ログインデックス: 50GB/月
- RUMセッション: 100万/月
計算:
Infrastructure (Pro): $15 × 20 = $300
APM (Pro): $31 × 10 = $310
Log Ingest: $0.10 × 500 = $50
Log Index: $1.70 × 50 = $85
RUM: $1.50 × 1,000 = $1,500
合計: $2,245/月コスト最適化のヒント
1. タグを活用
不要な環境を除外:
system.cpu.user{env:production}
開発環境やテスト環境は別プランに2. ログのフィルタリング
# datadog.yaml
logs_config:
processing_rules:
- type: exclude_at_match
name: exclude_debug_logs
pattern: DEBUG3. メトリクスの集約
毎秒ではなく、1分ごとに集約
→ データ量を大幅削減4. コミットメント割引
年間契約で20%割引
3年契約で40%割引他のツールとの比較
Datadogと競合ツールを比較しましょう。
比較表
| 項目 | Datadog | New Relic | Dynatrace | Prometheus + Grafana | AWS CloudWatch |
|---|---|---|---|---|---|
| タイプ | SaaS | SaaS | SaaS | OSS | クラウドサービス |
| セットアップ | 簡単 | 簡単 | 簡単 | 複雑 | 簡単（AWS内） |
| APM | ✅ 優秀 | ✅ 優秀 | ✅ 最高 | ⚠️ 別途必要 | ⚠️ 基本的 |
| ログ管理 | ✅ | ✅ | ✅ | ❌ Loki等が必要 | ✅ |
| 料金 | 高め | 高め | 最も高い | 無料（運用コスト） | 従量制（安め） |
| カスタマイズ | 中 | 中 | 低 | 高 | 低 |
| 学習コスト | 低 | 低 | 低 | 高 | 低 |
| マルチクラウド | ✅ 最高 | ✅ | ✅ | ✅ | ❌ AWS専用 |
詳細比較
Datadog vs Prometheus + Grafana：
Datadog：
- ✅ すぐに使える
- ✅ 統合が豊富
- ✅ サポートあり
- ❌ コストが高い
- ❌ ベンダーロックイン
Prometheus + Grafana：
- ✅ 無料
- ✅ 完全なコントロール
- ✅ Kubernetes親和性
- ❌ セットアップが大変
- ❌ 運用負荷が高い
- ❌ APM/ログは別途
おすすめの選択：
Datadogが向いている:
- スタートアップ〜中規模企業
- 運用リソースが限られている
- すぐに始めたい
- コストをかけてもOK
Prometheus + Grafanaが向いている:
- 大規模企業
- エンジニアリソースが豊富
- コスト削減重視
- カスタマイズ性重視Datadog vs New Relic：
類似点：
- どちらもSaaS型
- APM、Infrastructure、Logsをカバー
- 料金体系も似ている
Datadog の優位点：
- より多くの統合（600+ vs 400+）
- Kubernetes監視が強い
- カスタマイズ性が高い
New Relicの優位点：
- UIがシンプル
- 価格体系が分かりやすい（ユーザーベース課金も選択可）
- FedRAMP認証取得（米国政府案件）
Datadogのメリット・デメリット
客観的な評価をしましょう。
メリット
1. すぐに使い始められる
アカウント作成 → Agent インストール → 完了
所要時間: 10分
→ 即座にメトリクスが可視化
→ インフラ管理不要2. 統合（Integration）が豊富
600以上の統合:
- クラウドプロバイダー（AWS、GCP、Azure）
- データベース（MySQL、PostgreSQL、MongoDB等）
- メッセージキュー（Kafka、RabbitMQ、Redis）
- CI/CD（Jenkins、GitLab、GitHub Actions）
- その他多数
→ ほぼすべての技術スタックをカバー3. 美しく分かりやすいUI
- 直感的な操作
- ドラッグ&ドロップ
- レスポンシブデザイン
- モバイルアプリあり4. オールインワン
1つのプラットフォームで:
- インフラ監視
- APM
- ログ管理
- セキュリティ
- RUM
→ 画面を切り替える必要なし
→ データの相関分析が容易5. AI/ML機能
- 異常検知（Anomaly Detection）
- 外れ値検出（Outlier Detection）
- 予測監視（Forecast）
- 自動的なパターン認識6. 強力なクエリ言語
柔軟なメトリクス集計:
avg:system.cpu.user{env:prod} by {host}
sum:trace.requests.hits{service:api}.rollup(sum, 60)
(a / b) * 100デメリット
1. コストが高い
中規模環境での試算:
月額 $2,000〜$10,000+
大規模になると:
月額 $50,000〜$100,000+
→ スタートアップには負担大
→ 予算管理が重要2. ベンダーロックイン
Datadogに依存すると:
- 他のツールへの移行が困難
- 価格交渉の余地が減る
- データのエクスポートが制限的
対策:
- オープンスタンダード（OpenTelemetry等）を使用
- 重要なダッシュボードはバックアップ3. データ保持期間の制限
メトリクス: 15ヶ月
ログ: 15日〜（プランによる）
長期保存には:
- 別途アーカイブストレージ（S3等）
- コストが追加4. カスタマイズの限界
SaaSゆえの制約:
- バックエンドは触れない
- データの完全なコントロール不可
- 特殊な要件には対応困難5. 学習コスト
機能が豊富すぎて:
- すべてを理解するのは大変
- 最適な設定には時間がかかる
- トレーニングが必要な場合もよくある質問（FAQ）
Q1. Datadogは日本語対応していますか？
回答：
はい、UIは日本語に対応しています。
対応状況：
- WebUI：日本語表示可能
- ドキュメント：一部日本語
- サポート：日本語対応（Enterpriseプラン）
- データセンター：東京リージョン（AP1）あり
Q2. 無料プランでどこまで使えますか？
回答：
5ホストまで無料で使えますが、機能に制限があります。
Freeプランの制限：
- ホスト数：5台まで
- メトリクス保持：1日
- ログ管理：なし
- APM：なし
- カスタムメトリクス：100個まで
用途：
- 個人プロジェクト
- 検証用
- 小規模な趣味のサーバー
本番環境には：
Proプラン以上を推奨
Q3. Prometheusから移行できますか？
回答：
はい、可能です。
移行方法：
1. OpenMetrics形式でエクスポート
# datadog.yaml
prometheus_scrape:
enabled: true
configs:
- prometheus_url: http://localhost:9090/metrics
namespace: prometheus
metrics:
- "*"2. Prometheus Exporterを活用
既存のExporterをそのまま使用:
- Node Exporter
- MySQL Exporter
- Redis Exporter
→ Datadogが自動的にスクレイピング3. OpenTelemetryで標準化
OpenTelemetry Collector経由で:
- Prometheusからデータ収集
- Datadogに転送
- 将来的な移行も容易Q4. Datadogのセキュリティは大丈夫ですか？
回答：
Datadogは高いセキュリティ基準を満たしています。
認証・コンプライアンス：
- SOC 2 Type II
- ISO 27001
- HIPAA 対応
- PCI DSS 対応
- FedRAMP (New Relicが取得、Datadogは進行中)
データ保護：
- 転送中の暗号化（TLS 1.2+）
- 保存時の暗号化（AES-256）
- RBAC（ロールベースアクセス制御）
- SAML/SSO対応（Enterpriseプラン）
- 監査ログ
データの所在：
- リージョンごとにデータ分離
- EU/日本リージョンはデータが地域内に保持
Q5. ログの機密情報をマスクできますか？
回答：
はい、機密情報の除外・マスキングが可能です。
方法1：Agent側でフィルタリング
# datadog.yaml
logs_config:
processing_rules:
# クレジットカード番号をマスク
- type: mask_sequences
name: mask_credit_card
replace_placeholder: "[MASKED_CREDIT_CARD]"
pattern: \d{4}-\d{4}-\d{4}-\d{4}
# メールアドレスをマスク
- type: mask_sequences
name: mask_email
replace_placeholder: "[MASKED_EMAIL]"
pattern: \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b
# パスワードを含む行を除外
- type: exclude_at_match
name: exclude_passwords
pattern: password|secret|api_key方法2：Datadog UI側で設定
Logs → Configuration → Sensitive Data Scanner
→ 自動的にクレジットカード、SSN、メールアドレス等を検出・マスクQ6. Datadogのアラートはうるさくないですか？
回答：
適切に設定すれば、ノイズを減らせます。
アラート疲労を防ぐテクニック：
1. しきい値の調整
急激な変化のみ検知:
- 突然のスパイク
- 継続的な高負荷（5分以上）
一時的な変動は無視2. Anomaly Detectionの活用
機械学習で通常パターンを学習:
→ 真の異常のみアラート
→ 誤検知が減る3. Composite Monitorの使用
複数条件の組み合わせ:
CPU高 AND メモリ高 AND エラー率高
→ 総合的に判断4. アラートの優先度付け
Critical: 即座に対応が必要
Warning: 監視は必要だが緊急ではない
Info: 参考情報
→ Criticalのみページャー通知
→ Warningはメール・Slack5. Downtimeスケジュール
定期メンテナンス時はアラート停止:
毎週日曜 2:00-4:00
→ 自動的に沈黙Q7. DatadogとKubernetesの相性は？
回答：
非常に良いです。Datadog はKubernetesネイティブです。
Kubernetes専用機能：
- 自動検出：Pod/Serviceの自動発見
- Autodiscovery：アノテーションベースの設定
- Live Container View：コンテナのリアルタイム監視
- Orchestrator Explorer：クラスター全体の可視化
- Network Performance Monitoring：Pod間通信の可視化
導入例：
# Podにアノテーション追加で自動監視
apiVersion: v1
kind: Pod
metadata:
annotations:
ad.datadoghq.com/nginx.check_names: '["nginx"]'
ad.datadoghq.com/nginx.init_configs: '[{}]'
ad.datadoghq.com/nginx.instances: '[{"nginx_status_url": "http://%%host%%:%%port%%/nginx_status"}]'まとめ：Datadogは「今すぐ使える」統合監視プラットフォーム
Datadogは、現代のクラウドネイティブ環境に最適化された、包括的な監視ソリューションです。
この記事のポイント：
- DatadogはSaaS型のオールインワン監視プラットフォーム
- インフラ、APM、ログ、RUM、セキュリティを統合
- 10分でセットアップ完了、すぐに使える
- 600以上の統合で幅広い技術スタックに対応
- 美しく直感的なUIで誰でも使いやすい
- AI/ML機能で異常検知が自動化
- Kubernetesとの親和性が非常に高い
- コストは高めだが、運用負荷削減で相殺可能
- 14日間の無料トライアルで試せる
- Prometheus等のOSSと比べて運用が楽
Datadogは特に、「運用リソースが限られているチーム」「すぐに本格的な監視を始めたいスタートアップ」「マイクロサービス／Kubernetes環境」に最適です。
セットアップの手軽さ、統合の豊富さ、そして何よりも「1つのプラットフォームですべてが見える」という利点は、複雑化するシステム運用において非常に大きな価値があります。
コストは確かに高めですが、インフラ管理の手間、アラート疲労の削減、障害対応時間の短縮などを考慮すれば、十分にROIが見込めるツールです。
まずは14日間の無料トライアルで、Datadogの威力を体験してみてください。一度使えば、その便利さに手放せなくなること間違いなしです！
コメント