以下のコンフィギュレーションオプションを選択して、ログの取り込みを開始します。すでに log-shipper デーモンを使用している場合は、Rsyslog、Syslog-ng、NXlog、FluentD、または Logstash の専用ドキュメントを参照してください。
ログを Datadog に直接送信する場合は、使用可能な Datadog ログ収集エンドポイントのリストを参照してください。
注: ログを JSON 形式で Datadog に送信する場合は、Datadog 内にある特定の予約属性を使用します。詳細については、予約属性セクションをご覧ください。
Datadog Agent のインストール手順 に従って、メトリクスとトレースとともにログの転送を開始します。Agent では、ログファイルの監視や UDP/TCP で送信されたログの待機ができます。ユーザーは、ログの絞り込み、機密データのスクラビング、複数行に渡るログの集約を行うように Agent を設定することができます。
ログ収集を有効にしたら、ログ生成に使用されるアプリケーション言語を設定します。
注: JSON 形式のログは、複数行のアプリケーションログの処理に役立ちます。JSON 形式のログは Datadog によって自動的にパースされます。Datadog に送信するログ形式を制御できる場合は、カスタムパースルールが不要になるように、ログを JSON として形式化することをお勧めします。
Datadog Agent では、ログドライバーを使用せずにコンテナ stdout/stderr から直接ログを収集できます。Agent の Docker チェックを有効にすると、コンテナとオーケストレーターのメタデータがログにタグとして自動的に追加されます。 全てのコンテナから、またはコンテナのイメージ、ラベル、名前によってフィルタリングしたサブセットのみからログを収集することができます。また、オートディスカバリーを使用して、コンテナラベルでログ収集を直接設定することもできます。Kubernetes 環境では、デーモンセットのインストールも活用できます。
以下から環境を選択して、専用のログ収集手順を確認してください。
Datadog で、AWS Lambda からログを収集できます。これを有効にするには、サーバーレスモニタリングのドキュメントを参照してください。
以下からクラウドプロバイダーを選択すると、ログを自動的に収集して Datadog に転送する方法を確認できます。
Datadog のインテグレーションとログ収集は連携しています。インテグレーションのデフォルト構成ファイルを使用すると、Datadog で専用の処理、パース、およびファセットを有効にできます。
利用可能なサポートされているインテグレーションのリストを参照してください。
Datadog では、SSL で暗号化された接続と暗号化されていない接続の両方にログのエンドポイントが提供されます。可能な場合は常に、暗号化されたエンドポイントを使用してください。Datadog Agent では、暗号化されたエンドポイントを使用して、ログが Datadog に送信されます。詳細は、Datadog のセキュリティに関するドキュメントで確認できます。
SSL で暗号化された接続において、Datadog へのログの送信に使用できるエンドポイントは以下のとおりです。
暗号化されていない接続において、Datadog へのログの送信に使用できるエンドポイントは以下のとおりです。
TCP または HTTP 経由でログを転送できるカスタムプロセスまたはロギングライブラリを、Datadog ログと共に使用できます。
HTTP 経由で Datadog プラットフォームにログを送信できます。開始するには、Datadog ログ HTTP API ドキュメントを参照してください。
セキュリティ保護された TCP エンドポイントは intake.logs.datadoghq.com 10516 (セキュリティ保護されていない接続の場合はポート 10514) です。
ログエントリの前に必ず [Datadog API キー][1]を付けます。例:
<DATADOG_API_キー><ペイロード>
注: <ペイロード>には未加工、Syslog、または JSON 形式を使用できます。
Telnet を使用して手動でテストします。未加工形式の<ペイロード>の例:
telnet intake.logs.datadoghq.com 10514
<DATADOG_API_キー> TCP 経由で直接送信されるログ
これにより、[ライブ追跡ページ][2]に次の結果が生成されます。
<ペイロード>が 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 キー][1]を付けます。例:
<DATADOG_API_キー><ペイロード>
注: <ペイロード>には未加工、Syslog、または JSON 形式を使用できます。
Telnet を使用して手動でテストします。未加工形式の<ペイロード>の例:
telnet tcp-intake.logs.datadoghq.eu 443
<DATADOG_API_KEY> Log sent directly via TCP
これにより、[ライブ追跡ページ][2]に次の結果が生成されます。
<ペイロード>が JSON 形式である場合、Datadog はその属性を自動的にパースします:
telnet tcp-intake.logs.datadoghq.eu 1883
<DATADOG_API_キー> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}
TCP エンドポイントはこのリージョンでサポートされていません。
注:
上の制限に準拠しないログイベントは、システムによって変換されるか、切り詰められます。または、所定のタイムレンジ外の場合はインデックス化されません。ただし、Datadog はユーザーデータを可能な限り維持するよう全力を尽くします。
属性は、ログエクスプローラーでのフィルタリングと検索に使用されるログファセットを規定します。予約済み属性および標準属性のリストと、ログ属性とエイリアス設定を使用した命名規則のサポート方法については、専用の属性とエイリアス設定ドキュメントをご参照ください。
スタックトレースをログに記録するに当たっては、Datadog アプリケーション内に専用の UI 表示を持つ特別な属性があります。ロガー名、現在のスレッド、エラーの種類、スタックトレース自体などです。
この機能を使用するには、以下の属性名を使用します。
| 属性 | 説明 |
|---|---|
logger.name | ロガーの名前 |
logger.thread_name | 現在のスレッドの名前 |
error.stack | 実際のスタックトレース |
error.message | スタックトレースに含まれるエラーメッセージ |
error.kind | エラーのタイプ (“kind”) (“Exception”、“OSError” など) |
注: インテグレーションパイプラインは、デフォルトのログライブラリパラメーターをこれらの属性に再マップし、スタックトレースをパースまたはトレースバックして、自動的に error.message と error.kind を抽出しようとします。
詳しくは、ソースコードと属性ドキュメントをご覧ください。
ログが収集されて取り込まれると、ログエクスプローラーで利用できるようになります。ログエクスプローラーでは、ログのアラートを検索、強化、表示できます。ログエクスプローラーのドキュメントを参照してログデータの分析を開始するか、以下の追加のログ管理ドキュメントを参照してください。
お役に立つドキュメント、リンクや記事:
