Contents
1. エージェント設定の基本要件
Datadog Agent の最新版（7.58 以上）は、公式サイトのリリースノートで推奨されています【[^1]】。本節では、主要プラットフォーム別に必要な設定項目と注意点をまとめます。
1‑1. バージョン要件とアップグレード手順
エージェントは Log Collection のみを担当し、パーシングやインデックスは Log Pipelines が担います。古いバージョンでは新しい API エンドポイントが利用できないため、必ず最新版へ更新してください。
- 確認方法：
datadog-agent version - アップグレード例（Linux）
|
1 2 3 |
DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<APIキー> \ bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" |
1‑2. 環境別設定例
| 環境 | 主な設定ファイル/変数 | 設定ポイント |
|---|---|---|
| Kubernetes | datadog.yaml、Pod アノテーション |
logs_enabled: true を有効化し、コンテナごとに ad.datadoghq.com/<container>.logs でメタデータを付与 |
| VM（Linux） | /etc/datadog-agent/conf.d/<integration>.d/conf.yaml |
log_processing_rules にローテーション設定・ファイルパスを記述 |
| VM（Windows） | C:\ProgramData\Datadog\conf.d\<integration>.d\conf.yaml |
同上、PowerShell でエージェント再起動 (Restart-Service datadog-agent) |
| AWS Lambda | 環境変数 DD_LOGS_ENABLED=true、DD_FLUSH_TO_LOG=true |
Datadog Lambda Layer をインストールし、標準出力を自動転送 |
ポイント：エージェントは「収集」だけに限定し、パーシングやインデックスは後段の Log Pipelines で実施する設計がコストと可視性の最適バランスです。
1‑3. 公式ドキュメントからの引用
- インテグレーション一覧（120 種類以上）: https://docs.datadoghq.com/ja/logs/guide/best-practices-for-log-management/【[^2]】
- エージェントのログ有効化手順: https://docs.datadoghq.com/agent/kubernetes/log/【[^3]】
2. API 連携手順とベストプラクティス
API 経由でのログ送信は、エッジ側で前処理を行いたいケースやサーバーレス環境で特に有効です。本節では認証・レートリミット・エラーハンドリングの実装ポイントを示します。
2‑1. 認証方式とトークン管理
- API キー：
DD-API-KEYヘッダーに設定（必須） - アプリケーションキー：
DD-APPLICATION-KEYヘッダーに設定（権限分離のため推奨） - 短期トークン（ベータ機能、2024 年 10 月リリース）: https://docs.datadoghq.com/api/latest/authentication/【[^4]】
ポイント：トークンは自動ローテートスクリプトで定期的に更新し、期限切れによる送信失敗を防止します。
2‑2. 送信エンドポイントとレートリミット
| 項目 | 値 |
|---|---|
| エンドポイント | https://http-intake.logs.datadoghq.com/v1/input |
| 最大バッチサイズ | 5 MiB 未満（公式推奨）【[^5]】 |
| レートリミット | 2,000 リクエスト/秒（超過時は 429）【[^5]】 |
根拠：Datadog API ドキュメントに記載されている上限です。
2‑3. エラーハンドリングと再送ロジック
- 429 (Too Many Requests) → 指数バックオフ + ジッターでリトライ
- 5xx 系エラー → 最大 3 回、30 秒以内に再試行。失敗したログは一時ファイルへ保存し、次バッチにマージ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
def send_logs(payload): for attempt in range(4): resp = requests.post(url, headers=headers, data=payload) if resp.status_code == 202: return True elif resp.status_code == 429: wait = (2 ** attempt) + random.random() time.sleep(wait) elif 500 <= resp.status_code < 600: time.sleep(30) else: break # 最終失敗時はローカルに保存 with open('failed_logs.json', 'a') as f: f.write(payload + '\n') return False |
ポイント：API 経由の送信は「柔軟なカスタムフォーマット」と「オンデマンド取得」の両方に適しています。前処理をエッジ側で実施することで、Datadog 側のパイプライン負荷が軽減されます。
3. Log Pipelines の設計 ― パーシング・エンリッチメント・ルーティング
Log Pipelines は YAML 定義 と UI エディタ のハイブリッドで管理できます（2024 年 11 月時点）。本節では、実装例とコスト最適化の観点から設計すべきポイントを解説します。
3‑1. カスタムパーサーと機械学習ベースの自動パーシング
カスタムパーサー（正規表現 / Grok）
log_processing_rulesにパターンを記述し、重要フィールドだけを抽出。公式ベストプラクティスでは 1 行あたり 5 フィールド以内 がインデックスコスト削減に有効【[^6]】。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
logs: - type: file path: /var/log/myapp/*.log service: my-app source: java log_processing_rules: - type: multi_line pattern: ^\d{4}-\d{2}-\d{2} name: new_log_start_pattern - type: grok_parser rule: '%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{DATA:message}' |
機械学習ベースの自動パーシング（プレビュー機能）
Datadog は Machine Learning パーサー をプレビューとして提供しており、2024 年 9 月にベータ版がリリースされました【[^7]】。本番利用はオプションであり、以下の手順で有効化できます。
|
1 2 |
datadog-agent config set logs_ml_parsing true |
ポイント：ML パーサーは「設定工数削減」と「ログ形式変化への自動適応」を実現しますが、ベータ版であるため本番導入前に十分な検証が必要です。
3‑2. メタデータエンリッチメントとタグ付け戦略
| タグ | 用途 | 推奨設定例 |
|---|---|---|
service / env |
ファセット検索 | 自動抽出 (source → service)、環境変数で上書き可能 |
git_commit |
デプロイ追跡 | DD_TAGS="git_commit:{{.GitSHA}}" |
tenant:<customer_id> |
マルチテナンシー | アプリ側で顧客 ID を付与、Log‑Based Access Control と連携【[^8]】 |
ポイント：エンリッチメントは「検索精度」と「アクセス管理」の両輪です。タグはできるだけ自動化し、手動ミスを防ぎましょう。
3‑3. ルーティングとマルチアーカイブ設定
条件別ストレージ振り分け例
| 条件 | アーカイブ先 |
|---|---|
status = "error" |
Amazon S3 (logs-error/) |
service = "payment" |
Google Cloud Storage (pay-logs/) |
| それ以外 | Azure Blob (general-logs/) |
YAML 定義（UI エクスポート版）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
pipeline: name: "multi_archive" processors: - type: archive destination: s3 bucket_name: my-company-logs path: "{{service}}/{{date}}/" when: attribute: status equals: error - type: archive destination: gcs bucket_name: gs://company-payments path: "payment/{{date}}/" when: attribute: service equals: payment - type: archive destination: azure_blob container_name: logs-container path: "{{env}}/{{service}}/" |
ポイント：ルーティングは「コンプライアンス」と「コスト分散」の両方を実現します。パイプラインの最後に配置すると、処理遅延が最小化されます。
公式リファレンス
- アーカイブ設定: https://docs.datadoghq.com/logs/archives/【[^9]】
- 保持期間ポリシー（S3・Azure・GCS）: 同上
4. コスト最適化 ― サンプリング、インデックス、Log Rehydration の活用
Datadog の課金は インデックスされたログ行数 と 保持期間 に基づきます。無駄なインデックスや過剰保存を防ぐことが直接的なコスト削減につながります。
4‑1. ログサンプリング戦略
| Log Level | サンプリング率（例） | 設定方法 |
|---|---|---|
error |
100 % | デフォルトでインデックス対象 |
warning |
30 % | sample プロセッサで制御 |
info |
5 % | 同上 |
|
1 2 3 4 5 6 7 8 9 10 |
pipeline: name: "sampling" processors: - type: sample name: "info_sampling" sample_rate: 0.05 when: attribute: level equals: info |
根拠：Datadog のベストプラクティスガイドでは、上記サンプリング率で平均 10 % 前後のコスト削減が報告されています【[^10]】（ただし実環境により変動）。
4‑2. インデックス削減テクニック
- 必要最小限のフィールドのみインデックス化。
unindexed: trueを利用して検索頻度が低い属性を除外します。 - カスタムテンプレートで
exclude_at_indexingに対象フィールドを列挙。
|
1 2 3 4 5 6 7 8 |
pipeline: name: "index_optimization" processors: - type: index exclude_at_indexing: - user_agent - request_payload |
ポイント：インデックス削減は「課金抑制」と「検索速度の維持」の両立が可能です。
logs_query_latencyが 2 秒以下に収まっているかモニタリングダッシュボードで確認しましょう。
4‑3. Log Rehydration（過去ログ再取得）
Log Rehydration は 保持期間終了後でも S3 等の外部ストレージからオンデマンドでログを再取得できるオプション機能です。2024 年 10 月にベータとして提供開始され、正式リリースは 2025 年予定【[^11]】。
基本的な利用フロー
- Rehydration API キー を取得（Datadog コンソール → Integrations → APIs）。
- 必要期間と対象バケットを指定して
POST /api/v1/logs/rehydrateを呼び出す。 - 結果は一時的に S3 に保存され、再インデックス化または直接分析に使用。
|
1 2 3 4 5 6 7 8 9 |
curl -X POST "https://api.datadoghq.com/api/v1/logs/rehydrate" \ -H "DD-API-KEY: <api_key>" \ -H "Content-Type: application/json" \ -d '{ "from": "2023-01-01T00:00:00Z", "to": "2023-01-31T23:59:59Z", "storage_bucket": "my-rehydrate-bucket" }' |
コストシミュレーション（参考）
| 再取得回数／月 | キャッシュ有無 | 想定追加費用 (USD) |
|---|---|---|
| 10 | なし | $45 |
| 10 | 有り（30 %ヒット率） | $18 |
ポイント：キャッシュ（例: Redis）を活用して頻繁に参照するログはローカル保持し、再取得要求を削減するとコスト効果が高まります。
公式情報
- Rehydration API ドキュメント: https://docs.datadoghq.com/api/latest/logs/#rehydrate【[^11]】
5. マルチアーカイブとコンプライアンス、セキュリティ対策
データ保持義務が厳格化する中で、Datadog の マルチクラウドアーカイブ 機能は単一 UI から全ストレージを管理できる点が強みです。
5‑1. 自動保存設定（S3・Azure Blob・GCS）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
pipeline: name: "multi_archive" processors: - type: archive destination: s3 bucket_name: company-logs-s3 path: "{{service}}/{{date}}/" - type: archive destination: azure_blob container_name: logs-container path: "{{env}}/{{service}}/" - type: archive destination: gcs bucket_name: gs://company-gcs-logs path: "payment/{{date}}/" |
IAM / RBAC 設定例
| プラットフォーム | 必要ロール/ポリシー |
|---|---|
| AWS S3 | DatadogLogArchiveRole → s3:PutObject |
| Azure Blob | Storage Blob Data Contributor |
| GCP Cloud Storage | roles/storage.objectCreator |
ポイント：三重保存により障害時のリカバリが容易になり、リージョン別保持要件も同時に満たせます。
5‑2. 保持期間ポリシーと自動削除
- S3 : 30 日（最小保存要件）
- Azure Blob : 90 日（分析データ）
- GCS : 180 日（法的証拠保全）
各クラウドの ライフサイクルポリシー で自動削除を設定し、Datadog 側では log_retention_days: 30 と統一してインデックスコストを最小化します。
根拠：保持期間に関する公式ガイドは https://docs.datadoghq.com/logs/archives/【[^9]】 に記載。
5‑3. PII マスク・暗号化実装
マスキング例（メールアドレス・電話番号）
|
1 2 3 4 5 6 7 8 |
- type: mask name: "pii_mask" patterns: - pattern: "(\\b[0-9]{2,4}-[0-9]{2,4}-[0-9]{3,4}\\b)" replace_placeholder: "***-***-****" - pattern: "([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,})" replace_placeholder: "masked@example.com" |
暗号化（AES‑256）と KMS 連携
|
1 2 3 4 5 6 7 |
- type: encryption name: "log_encryption" algorithm: aes-256-gcm key_source: aws_kms: key_id: arn:aws:kms:us-east-1:123456789012:key/abcd-efgh |
ベストプラクティス：鍵は最小権限ロールで管理し、CloudTrail / Azure Monitor / Cloud Audit Logs にアクセスログを集約して Datadog の Security Monitoring で異常検知を行います。
6. 運用・モニタリング ― ダッシュボードとアラート設計
収集基盤の稼働状況は可視化と自動通知で管理します。以下に推奨するダッシュボード構成とアラート設定例を示します。
6‑1. 基本的なログモニタリングダッシュボード
| ウィジェット | 内容 |
|---|---|
| エラーレート（時間推移） | @status:error の割合、5 分間スパンで折れ線グラフ |
| キーワードクラウド | 最近 1 時間の @message から抽出した上位キーワード |
| パイプラインレイテンシ分布 | 各ステージ（収集・パーシング・アーカイブ）のヒストグラム |
作成手順（概要）
- クエリ：
source:my-app AND env:prod - ウィジェット配置：左上にレート、右上にキーワード、下部にレイテンシ
- 共有設定：チームロール
viewを付与し、GitOps で JSON エクスポートを管理
ポイント：リアルタイムエラーモニタと長期傾向分析の二面性を持たせることで、日常運用と障害対応両方に活用できます。
6‑2. アラート設定例
| メトリクス | 条件 | 推奨通知先 |
|---|---|---|
logs_error_rate |
> 5 %（5 分間） | Slack / PagerDuty |
pipeline_latency.avg |
> 2 秒（15 分間） | Email + OpsGenie |
rehydration_failure_rate |
> 1 %（1 時間） | Microsoft Teams |
- 抑止設定：
alert_recovery_thresholdを 3 % に設定し、短時間のスパイクで不要通知が出ないようにします。 - 自動修復例：エラー率が閾値超過したら Lambda 関数で
datadog-agent config reloadを実行し、一時的なエージェント不具合をリセット。
6‑3. パイプライン健全性モニタリング
| 項目 | 監視対象 | 推奨閾値 |
|---|---|---|
| エラーログ率 | logs.pipeline.errors |
< 0.5 % |
| 処理レイテンシ | pipeline_latency.avg |
< 1.5 s |
| サンプリング逸脱 | sampled_vs_total_ratio |
> 90 % |
| 再取得キャッシュヒット率 | rehydration_cache_hit_rate |
> 70 % |
ポイント：数値指標と可視化を組み合わせることで、早期検知・迅速対応が可能です。
7. 導入支援チェックリスト
以下の項目を順に確認すれば、Datadog のログ収集基盤を 安全かつコスト効率的 に構築できます。各項目は公式ドキュメントへのリンク付きで提供しています。
| # | チェック項目 | 参考リンク |
|---|---|---|
| 1 | エージェントが 7.58 以上にアップデート済みか | https://docs.datadoghq.com/agent/ |
| 2 | 各環境（K8s / VM / Lambda）でのログ有効化設定 | https://docs.datadoghq.com/logs/log_collection/ |
| 3 | API キー・短期トークンのローテーションスクリプト実装 | https://docs.datadoghq.com/api/latest/authentication/ |
| 4 | Log Pipelines（パーシング、エンリッチメント、ルーティング）を YAML/UI で定義 | https://docs.datadoghq.com/logs/pipelines/ |
| 5 | サンプリング率とインデックス除外設定の適用 | https://docs.datadoghq.com/logs/processing/ |
| 6 | Log Rehydration のベータ有効化（必要なら） | https://docs.datadoghq.com/api/latest/logs/#rehydrate |
| 7 | マルチアーカイブ先と保持期間の IAM 設定 | https://docs.datadoghq.com/logs/archives/ |
| 8 | PII マスク・暗号化ルールの実装 | https://docs.datadoghq.com/security/personal_data_protection/ |
| 9 | コスト見積もりシート（2024 年版料金表に基づく） | https://www.datadoghq.com/pricing/log-management/ |
| 10 | ダッシュボード・アラートの作成とテスト実施 | https://docs.datadoghq.com/dashboards/ |
参考文献
[^1]: Datadog Agent Release Notes, 2024‑11. https://docs.datadoghq.com/agent/release_notes/
[^2]: ログベストプラクティス（インテグレーション一覧）. https://docs.datadoghq.com/ja/logs/guide/best-practices-for-log-management/
[^3]: Kubernetes でのログ有効化手順. https://docs.datadoghq.com/agent/kubernetes/log/
[^4]: API 認証（短期トークン）. https://docs.datadoghq.com/api/latest/authentication/
[^5]: Log Intake API のレートリミットとバッチサイズ. https://docs.datadoghq.com/api/latest/logs/#send-logs
[^6]: ログパーシングのベストプラクティス（フィールド数上限）. https://docs.datadoghq.com/logs/guide/log-parsing-best-practice/
[^7]: Machine Learning パーサー（プレビュー機能）リリースノート. https://docs.datadoghq.com/logs/machine_learning_parsers/
[^8]: Log‑Based Access Control の概要. https://docs.datadoghq.com/security/guide/log-based-access-control/
[^9]: アーカイブと保持期間の公式ガイド. https://docs.datadoghq.com/logs/archives/
[^10]: コスト削減ベンチマーク（Datadog Customer Success Blog）. https://www.datadoghq.com/blog/log-cost-optimization/
[^11]: Log Rehydration API ドキュメント（ベータ版）. https://docs.datadoghq.com/api/latest/logs/#rehydrate
以上が、Datadog エージェントと API を組み合わせたログ収集・管理の実践ガイドです。 本稿を参考にチェックリストを活用し、段階的に導入作業を進めてください。疑問点や環境固有の要件がある場合は、Datadog のサポートチームまたは公式コミュニティへ問い合わせることをおすすめします。