メインコンテンツまでスキップ

Datadog Log Ingestion APIによるイベントの取り込み

はじめに​

Datadogのログ取り込みAPIを使用すると、クラウドアプリ、マイクロサービス、またはテレメトリを送信するあらゆるシステムから、JSON形式のログイベントをDatadog Log Managementに直接送信できます。ログを取り込むと、数秒以内にLog Explorerで利用可能になります。Log Pipelinesを使用して、ログの処理、ルーティング、アーカイブを行うことができます。

このエンドポイントは、構造化および半構造化の JSON ペイロードの高スループットかつリアルタイムな取り込みをサポートしています。

この API でサポートされる操作​

  • Datadog Agent をインストールせずに、クラウドアプリから直接ログを送信します。
  • 受信データに、Grok Parser、Remapper、Lookup Processor などのパイプラインプロセッサを適用します。
  • コンテンツに基づいて、ログをインデックス、アーカイブ、またはアラート送信先にルーティングします。
  • このエンドポイントをサンプリングおよびフィルタリングルールと組み合わせることで、インデックス作成のコストを削減します。
注記

DatadogのAPIおよびAPIキーの詳細については、**こちら**をご覧ください。

開始する前に​

以下の準備が整っていることを確認してください：

  • ログ取り込み権限を持つ Datadog API キー。これは 組織設定 → API キー で確認できます。

  • Datadog サイトのアドレス。このアドレスはリージョンによって異なります：

    リージョンサイトのアドレス
    米国（東部）datadoghq.com
    米国3（西部）us3.datadoghq.com
    米国5（中部）us5.datadoghq.com
    EU（ヨーロッパ）datadoghq.eu
    AP1 (日本)ap1.datadoghq.com
    AP2 (オーストラリア)ap2.datadoghq.com

  • curl または Postman がインストールされていること。

  • JSON 形式のログペイロード。

パイプラインの概要​

Datadog ログ取り込みパイプライン

インジェストエンドポイント​

POST https://http-intake.logs.{dd_site}/api/v2/logs

{dd_site} を、お使いのリージョンのサイトアドレス（例: datadoghq.com または ap2.datadoghq.com）に置き換えてください。

リクエストヘッダー​

ヘッダー値必須説明
DD-API-KEY<your_api_key>はいDatadog API キー
Content-Typeapplication/jsonはいペイロード形式

リクエスト本文​

リクエスト本文は、1つ以上のログオブジェクトからなるJSON配列です。各ログオブジェクトは、以下のフィールドをサポートしています：

フィールド型必須説明
message文字列はいログメッセージ本文
ddsource文字列推奨ログの発生元となる技術（例：python や nginx）。
ddtags文字列任意カンマ区切りのタグ（例：env:prod,team:payments）。
hostname文字列任意ログを生成したホスト名
service文字列推奨アプリまたはサービスの名前
注記

message フィールドは必ず含める必要があります。その他のフィールドはすべてオプションですが、Datadog では使用を推奨しています。Datadog は、フィルタリング、ファセット、パイプラインのマッチングに service、ddsource、および ddtags を使用します。

ペイロードの例​

[
  {
    "message": "Transaction failed: Gateway timeout",
    "ddsource": "payment-gateway",
    "ddtags": "env:prod,region:us-east-1",
    "hostname": "payments-host-01",
    "service": "payment-gateway",
    "timestamp": "2025-11-15T08:30:00Z",
    "transaction_id": "txn_998877",
    "customer_id": "cus_554433",
    "level": "ERROR"
  }
]
注記

timestamp には、国際標準化機構（ISO）8601 による協定世界時（UTC）形式を使用する必要があります。Datadog は、Log Explorer でのタイムラインの整合のためにこの形式を使用します。Datadog は、タイムスタンプなしで送信されたログを、取り込み時刻を使用してインデックス化します。

レスポンスコード​

202 Accepted​

202 Accepted レスポンスは、Datadogがペイロードを受信したことを意味します。このレスポンスには本文がありません。ログは数秒以内にLog Explorerに表示されます。

HTTP/1.1 202 Accepted

400 Bad Request​

ペイロードにフォーマットエラーがある場合、Datadogはこのコードを返します。一般的な原因：

  • JSON構文が正しくない。
  • message フィールドが欠落している。
  • ペイロードが 5 MB の制限を超えている。
{
  "errors": ["Invalid JSON"]
}

401 Unauthorized​

API キーが欠落している、正しくない、またはログ取り込みの権限がない。

{
  "errors": ["Forbidden"]
}

429 Too Many Requests​

システムのリクエストレート制限を超えました。リクエスト頻度を減らすか、ログオブジェクトを単一の配列ペイロードにまとめてください。

Curl の例​

export DD_API_KEY="your_datadog_api_key_here"
export DD_SITE="datadoghq.com"

curl -X POST "https://http-intake.logs.$DD_SITE/api/v2/logs" \
  -H "DD-API-KEY: $DD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "message": "Transaction failed: Gateway timeout",
      "ddsource": "payment-gateway",
      "ddtags": "env:prod,region:us-east-1",
      "hostname": "payments-host-01",
      "service": "payment-gateway",
      "level": "ERROR",
      "transaction_id": "txn_998877"
    }
  ]'

複数のログイベントのバッチ処理​

配列を渡すことで、1回のリクエストで最大1,000件のログエントリを送信できます。 Datadogでは、高スループットなサービスにおいてこのアプローチを推奨しています。

[
  {
    "message": "User login succeeded",
    "service": "auth-service",
    "ddsource": "python",
    "ddtags": "env:prod",
    "level": "INFO"
  },
  {
    "message": "Transaction failed: Gateway timeout",
    "service": "payment-gateway",
    "ddsource": "python",
    "ddtags": "env:prod",
    "level": "ERROR",
    "transaction_id": "txn_998877"
  }
]

制限事項:

  • 最大ペイロードサイズ: リクエストあたり 5 MB
  • 個々のログの最大サイズ: 1 MB
  • 配列の最大エントリ数: 1,000 個のログオブジェクト

一般的なユースケース​

  • Datadog Agent をデプロイせずに、マイクロサービスからログを取り込む。
  • Amazon Web Services (AWS) Lambda や Google Cloud Platform (GCP) Cloud Run などのサーバーレス関数から、構造化された JSON イベントを送信する。
  • IoT デバイスやエッジサービスからテレメトリをストリーミングする。
  • Log Pipelines を使用して、エンリッチされたイベントをセキュリティ情報イベント管理 (SIEM)、S3、またはアラート送信先へルーティングする。
  • 継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインやデプロイスクリプトからのログ送信。

トラブルシューティング​

問題考えられる原因解決策
401 UnauthorizedAPI キーが正しくない、または欠落している組織設定 → API キー で DD_API_KEY を確認
400 Bad RequestJSONの形式が不正送信前に jq . payload.json で検証
エクスプローラーにログが表示されないパイプラインのフィルターでログが除外されているフィルターを解除し、インデックスのルーティングルールを確認
タイムスタンプの順序が乱れているUTC形式またはISO 8601形式ではない"2025-11-15T08:30:00Z" 形式を使用
429 Too Many Requestsレート制限超過ログオブジェクトを単一の配列ペイロードにバッチ処理

次の手順​