ログの収集とインテグレーション
Datadog の調査レポート: サーバーレスの状態 レポート: サーバーレスの状態

ログの収集とインテグレーション

Datadog Agent のインストール手順に従って、ログをメトリクスおよびトレースと共に転送します。Agent では、ログファイルの追跡UDP/TCP 経由で送信されたログの受信ができます。ユーザーは、ログの絞り込み機密データのスクラビング複数行に渡るログの集約を行うように Agent を構成することができます。最後に、以下のアプリケーション言語から選択して最良のログ方法を実現します。 既にログ転送デーモンを使用している場合は、RsyslogSyslog-ngNXlogFluentDLogstash の専用ドキュメントを参照してください。

Datadog ログ管理には、ログを収集して Datadog に送信する一連のソリューションも付属しています。これらのソリューションは、追加設定なしで使用できます。

Datadog のインテグレーションとログ収集は連携しています。インテグレーションのデフォルト構成ファイルを使用すると、Datadog で専用の処理パース、およびファセットを有効にできます。

現在利用可能なサポート済みインテグレーションのリストは、こちらから確認できます。

ログを直接 Datadog に送信する場合は、このページの下部にある使用可能な Datadog ログ収集エンドポイントのリスト をご覧ください。

: ログを JSON 形式で Datadog に送信する場合は、Datadog 内にある特定の予約属性を使用します。詳細については、予約属性セクション をご覧ください。

アプリケーションログの収集

ログ収集を有効にしたら、ログ生成に使用されるアプリケーション言語を設定します。


コンテナログの収集

Datadog Agent では、ログドライバーを使用せずにコンテナ stdout/stderr から直接ログを収集できます。Agent の Docker チェックを有効にすると、コンテナとオーケストレーターのメタデータがログにタグとして自動的に追加されます。 全てのコンテナから、またはコンテナのイメージ、ラベル、名前によってフィルタリングしたサブセットのみからログを収集することができます。また、オートディスカバリーを使用して、コンテナラベルでログ収集を直接設定することもできます。Kubernetes 環境では、デーモンセットのインストールも活用できます。

以下から環境を選択して、専用のログ収集手順を確認してください。


サーバーレスログの収集

Datadog で、AWS Lambda からログを収集できます。これを有効にするには、AWS Lambda インテグレーションドキュメントを参照してください。

クラウドプロバイダーログの収集

以下からクラウドプロバイダーを選択すると、ログを自動的に収集して Datadog に転送する方法を確認できます。


カスタムログフォワーダー

TCP または HTTP 経由でログを転送できるカスタムプロセスまたはロギングライブラリを、Datadog ログと共に使用​​できます。ログを転送する Datadog サイトを以下から選択します。

セキュリティ保護された TCP エンドポイントは intake.logs.datadoghq.com:10516 (セキュリティ保護されていない接続の場合はポート 10514) です。

ログエントリの前に必ず Datadog API キーを付けます。例:

<DATADOG_API_キー><ペイロード>

: <ペイロード>には未加工、Syslog、または JSON 形式を使用できます。

Telnet を使用して手動でテストします。未加工形式の<ペイロード>の例:

telnet intake.logs.datadoghq.com 10514 
<DATADOG_API_キー> TCP 経由で直接送信されるログ

これにより、ライブ追跡ページに次の結果が生成されます。

<ペイロード>が JSON 形式である場合、Datadog はその属性を自動的にパースします:

telnet intake.logs.datadoghq.com 10514
<DATADOG_API_キー> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}

セキュリティ保護された TCP エンドポイントは tcp-intake.logs.datadoghq.eu:443 (セキュリティ保護されていない接続の場合はポート 1883) です。

ログエントリの前に Datadog API キーを付けてください。例:

**注**: ``は未加工、Syslog、または JSON 形式を使用できます。

Telnet を使用して手動でテストします。未加工形式の``の例:

text telnet tcp-intake.logs.datadoghq.eu 1883 TCP 経由で直接送信されるログ

これにより、[ライブ追跡ページ][2]に次の結果が生成されます:

<div class="shortcode-wrapper shortcode-img expand"><figure class="text-center"><a href="https://datadog-docs.imgix.net/images/logs/custom_log_telnet.9a3aa1aee30c6d514ac3e88933bb8d9f.png?fit=max&amp;auto=format" class="pop" data-toggle="modal" data-target="#popupImageModal"><picture class=""  style="width:70%;"  >
          <img class="lazyload img-fluid" srcset="https://datadog-docs.imgix.net/images/logs/custom_log_telnet.9a3aa1aee30c6d514ac3e88933bb8d9f.png?auto=format"  style="width:70%;"   alt="カスタム telnet"  />
          </picture></a></figure>
</div>


`<ペイロード>`が JSON 形式である場合、Datadog はその属性を自動的にパースします:

text telnet tcp-intake.logs.datadoghq.eu 1883 {“message”:“json formatted log”, “ddtags”:“env:my-env,user:my-user”, “ddsource”:“my-integration”, “hostname”:“my-hostname”, “service”:“my-service”} ```

EU または米国のサイトに HTTP 経由でログを送信するには、Datadog ログ HTTP API ドキュメントを参照してください。

Datadog ログのエンドポイント

Datadog では、SSL で暗号化された接続と暗号化されていない接続の両方にログのエンドポイントが提供されます。 可能な場合は常に、暗号化されたエンドポイントを使用してください。Datadog Agent では、暗号化されたエンドポイントを使用して、ログが Datadog に送信されます。詳細は、Datadog のセキュリティに関するドキュメントで確認できます。

Datadog へのログの送信に使用できるエンドポイントは以下のとおりです。

SSL で暗号化された接続のエンドポイントポート説明
agent-intake.logs.datadoghq.com10516SSL で暗号化された TCP 接続を介して Agent が protobuf 形式のログを送信する際に使用されます。
agent-http-intake.logs.datadoghq.com443HTTPS 経由で protobuf 形式のログを送信するために Agent が使用。HTTP 経由のログ送信方法ドキュメント参照。
http-intake.logs.datadoghq.com443HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。HTTP 経由のログ送信方法ドキュメント参照。
intake.logs.datadoghq.com10516SSL で暗号化された TCP 接続を介してカスタムフォワーダーが生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。
lambda-intake.logs.datadoghq.com10516SSL で暗号化された TCP 接続を介して Lambda 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。
lambda-http-intake.logs.datadoghq.com443HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。
functions-intake.logs.datadoghq.com10516SSL で暗号化された TCP 接続を介して Azure 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。: 他のクラウドプロバイダーもこのエンドポイントを使用できます。
暗号化されていない接続のエンドポイントポート説明
intake.logs.datadoghq.com10514暗号化されていない TCP 接続を介してカスタムフォワーダーが生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。
SSL で暗号化された接続のエンドポイントポート説明
agent-intake.logs.datadoghq.eu443SSL で暗号化された TCP 接続を介して Agent が protobuf 形式のログを送信する際に使用されます。
agent-http-intake.logs.datadoghq.eu443HTTPS 経由で protobuf 形式のログを送信するためにエージェントが使用します。HTTP 経由のログ送信方法ドキュメントを参照してください。
http-intake.logs.datadoghq.eu443HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用します。HTTP 経由のログ送信方法ドキュメントを参照してください。
tcp-intake.logs.datadoghq.eu443SSL で暗号化された TCP 接続を介してカスタムフォワーダーが生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。
lambda-intake.logs.datadoghq.eu443SSL で暗号化された TCP 接続を介して Lambda 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。
lambda-http-intake.logs.datadoghq.eu443HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 機能が使用します。
functions-intake.logs.datadoghq.eu443SSL で暗号化された TCP 接続を介して Azure 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。: 他のクラウドプロバイダーもこのエンドポイントを使用できます。
暗号化されていない接続のエンドポイントポート説明
tcp-intake.logs.datadoghq.eu1883暗号化されていない TCP 接続を介してカスタムフォワーダーが生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。

HTTP 経由でログを送信するには、Datadog ログ HTTP API ドキュメントを参照してください。

予約済み属性

以下に、プロジェクトの設定時に注意を必要とする重要な属性の一部を示します。

属性説明
hostメトリクスで定義された送信元ホストの名前。Datadog で一致したホストから、対応するホストタグが自動的に取得され、ログに適用されます。Agent では、この値が自動的に設定されます。
sourceこれは、インテグレーション名 (ログの生成元) に対応します。インテグレーション名と一致する場合、対応するパーサーとファセットが自動的にインストールされます。たとえば、nginxpostgresql などです。
statusログのレベル/重大度に対応します。パターンの定義に使用され、Datadog ログ UI 専用のレイアウトがあります。
serviceログイベントを生成するアプリケーションまたはサービスの名前。Logs から APM への切り替えに使用されます。このため、両方の製品を使用する際には必ず同じ値を定義してください。
messageデフォルトでは、message 属性の値はログエントリの本文として収集されます。Logstream では、この値はハイライトされて表示され、全文検索用にインデックス化されます。

収集されたログは、Log Explorer ビューで集中管理されます。ログの検索や追加、またアラートの設定などが可能です。

アプリケーションログを最大限に活用する方法

スタックトレースをログに記録するに当たっては、Datadog アプリケーション内に専用の UI 表示を持つ特別な属性があります。ロガー名、現在のスレッド、エラーの種類、スタックトレース自体などです。

この機能を使用するには、以下の属性名を使用します。

属性説明
logger.nameロガーの名前
logger.thread_name現在のスレッドの名前
error.stack実際のスタックトレース
error.messageスタックトレースに含まれるエラーメッセージ
error.kindエラーのタイプ (“kind”) (“Exception”、”OSError” など)

: インテグレーションパイプラインは、デフォルトのログライブラリパラメーターをこれらの属性に再マップし、スタックトレースをパースまたはトレースバックして、自動的に error.messageerror.kind を抽出しようとします。

JSON によるアプリケーションログの送信

Datadog は、インテグレーションフレームワーク向けに JSON をログファイルに記録する方法のガイドラインを提供しています。JSON 形式のログは、複数行のアプリケーションログを処理するために便利で、Datadog によって自動的にパースされます。

JSON 形式のログを収集するメリット

Datadog は、JSON 形式のログを自動的にパースします。このため、Datadog に送信するログの形式を管理できる場合は、それらのログを JSON にすることをお勧めします。そうすると、カスタムパース規則を作成する必要がなくなります。

その他の参考資料