概要
以下のコンフィギュレーションオプションを選択して、ログの取り込みを開始します。すでに log-shipper デーモンを使用している場合は、Rsyslog、Syslog-ng、NXlog、FluentD、または Logstash の専用ドキュメントを参照してください。
ログを Datadog に直接送信する場合は、使用可能な Datadog ログ収集エンドポイントのリストを参照してください。
注: ログを JSON 形式で Datadog に送信する場合は、Datadog 内にある特定の予約属性を使用します。詳細については、予約属性セクションをご覧ください。
セットアップ
- Datadog Agent をインストールします。
- ログ収集を有効にするには、Agent のメインコンフィギュレーションファイル (
datadog.yaml
) で logs_enabled: false
を logs_enabled: true
に変更します。より詳細な情報と例については、ホスト Agent ログ収集のドキュメントを参照してください。 - アプリケーション言語のインストール手順に従い、ロガーを構成し、ログの生成を開始します。
コンテナまたはオーケストレーターのプロバイダーを選択し、そのプロバイダー専用のログ収集手順に従います。
注:
環境から Datadog にログを送信する AWS Lambda 関数である Datadog Forwarder を使用します。AWS サーバーレス環境でログ収集を有効にするには、Datadog Forwarder のドキュメントを参照してください。
以下からクラウドプロバイダーを選択すると、ログを自動的に収集して Datadog に転送する方法を確認できます。
Datadog のインテグレーションとログ収集は連携しています。インテグレーションのデフォルト構成ファイルを使用すると、Datadog で専用のプロセッサー、パース、およびファセットを有効にできます。インテグレーションでログ収集を開始するには:
- インテグレーションページからインテグレーションを選択し、セットアップの指示に従います。
- インテグレーションが提供するログ収集の手順に従ってください。このセクションでは、そのインテグレーションの
conf.yaml
ファイルにある logs セクションのコメントを解除し、環境に合わせて構成する方法について説明します。
データ転送料金を削減
Datadog の Network Performance Monitoring を利用して、組織内で最もスループットの高いアプリケーションを特定しましょう。サポートされているプライベート接続を通じて Datadog に接続し、データをプライベートネットワークで送信することで、パブリックインターネットを避けてデータ転送料金を削減できます。プライベートリンクに切り替えた後は、Datadog の Cloud Cost Management ツールを使って効果を確認し、クラウドコストの削減状況を監視しましょう。
詳細については、データ転送料金を削減しながら Datadog にログを送信する方法をご覧ください。
追加のコンフィギュレーションオプション
ログのエンドポイント
Datadog では、SSL で暗号化された接続と暗号化されていない接続の両方にログのエンドポイントが提供されます。可能な場合は常に、暗号化されたエンドポイントを使用してください。Datadog Agent では、暗号化されたエンドポイントを使用して、ログが Datadog に送信されます。詳細は、Datadog のセキュリティに関するドキュメントで確認できます。
サポートされるエンドポイント
ページの右側にあるサイトセレクターのドロップダウンを使用して、Datadog サイトごとにサポートされているエンドポイントを確認できます。
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
US | HTTPS | http-intake.logs.datadoghq.com | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
US | HTTPS | agent-http-intake-pci.logs.datadoghq.com | 443 | Agent が PCI DSS コンプライアンスを有効にした組織へ HTTPS でログを送信するために使用します。詳しくは、ログ管理のための PCI DSS コンプライアンスを参照してください。 |
US | HTTPS | agent-http-intake.logs.datadoghq.com | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
US | HTTPS | lambda-http-intake.logs.datadoghq.com | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
US | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
US | TCP | agent-intake.logs.datadoghq.com | 10514 | Agent が TLS を使わずにログを送信するために使用します。 |
US | TCP と TLS | agent-intake.logs.datadoghq.com | 10516 | Agent が TLS を使ってログを送信するために使用します。 |
US | TCP と TLS | intake.logs.datadoghq.com | 443 | SSL で暗号化された TCP 接続を介してカスタムフォワーダーが生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。 |
US | TCP と TLS | functions-intake.logs.datadoghq.com | 443 | SSL で暗号化された TCP 接続を介して Azure 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。注: 他のクラウドプロバイダーもこのエンドポイントを使用できます。 |
US | TCP と TLS | lambda-intake.logs.datadoghq.com | 443 | SSL で暗号化された TCP 接続を介して Lambda 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。 |
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
EU | HTTPS | http-intake.logs.datadoghq.eu | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
EU | HTTPS | agent-http-intake.logs.datadoghq.eu | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
EU | HTTPS | lambda-http-intake.logs.datadoghq.eu | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
EU | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
EU | TCP と TLS | agent-intake.logs.datadoghq.eu | 443 | SSL で暗号化された TCP 接続を介して Agent が protobuf 形式のログを送信する際に使用されます。 |
EU | TCP と TLS | functions-intake.logs.datadoghq.eu | 443 | SSL で暗号化された TCP 接続を介して Azure 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。注: 他のクラウドプロバイダーもこのエンドポイントを使用できます。 |
EU | TCP と TLS | lambda-intake.logs.datadoghq.eu | 443 | SSL で暗号化された TCP 接続を介して Lambda 関数が生ログ、Syslog、または JSON 形式のログを送信する際に使用されます。 |
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
US3 | HTTPS | http-intake.logs.us3.datadoghq.com | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
US3 | HTTPS | lambda-http-intake.logs.us3.datadoghq.com | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
US3 | HTTPS | agent-http-intake.logs.us3.datadoghq.com | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
US3 | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
US5 | HTTPS | http-intake.logs.us5.datadoghq.com | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
US5 | HTTPS | lambda-http-intake.logs.us5.datadoghq.com | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
US5 | HTTPS | agent-http-intake.logs.us5.datadoghq.com | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
US5 | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
AP1 | HTTPS | http-intake.logs.ap1.datadoghq.com | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
AP1 | HTTPS | lambda-http-intake.logs.ap1.datadoghq.com | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
AP1 | HTTPS | agent-http-intake.logs.ap1.datadoghq.com | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
AP1 | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
サイト | タイプ | エンドポイント | ポート | 説明 |
---|
US1-FED | HTTPS | http-intake.logs.ddog-gov.com | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。Logs HTTP API のドキュメント参照。 |
US1-FED | HTTPS | lambda-http-intake.logs.ddog-gov.datadoghq.com | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 |
US1-FED | HTTPS | agent-http-intake.logs.ddog-gov.datadoghq.com | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。ホスト Agent ログ収集のドキュメント参照。 |
US1-FED | HTTPS | logs.
| 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 |
カスタムログ転送
TCP または HTTP 経由でログを転送できるカスタムプロセスまたはロギングライブラリを、Datadog ログと共に使用できます。
OpenSSL、GnuTLS、または他の SSL/TLS クライアントを使用して、接続を手動でテストすることができます。GnuTLS の場合は、以下のコマンドを実行します。
gnutls-cli intake.logs.datadoghq.com:10516
OpenSSL の場合、以下のコマンドを実行します。
openssl s_client -connect intake.logs.datadoghq.com:10516
ログエントリの前に必ず Datadog API キーを付けて、ペイロードを追加する必要があります。
<DATADOG_API_KEY> Log sent directly using TLS
ペイロード、または例で書かれている Log sent directly using TLS
(TCP 経由で直接送信されたログ) は、raw、Syslog、または JSON 形式にすることができます。ペイロードが JSON 形式の場合、Datadog は自動的にその属性をパースします。
<DATADOG_API_KEY> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}
OpenSSL、GnuTLS、または他の SSL/TLS クライアントを使用して、接続を手動でテストすることができます。GnuTLS の場合は、以下のコマンドを実行します。
gnutls-cli tcp-intake.logs.datadoghq.eu:443
OpenSSL の場合、以下のコマンドを実行します。
openssl s_client -connect tcp-intake.logs.datadoghq.eu:443
ログエントリの前に必ず Datadog API キーを付けて、ペイロードを追加する必要があります。
<DATADOG_API_KEY> Log sent directly using TLS
ペイロード、または例で書かれている Log sent directly using TLS
(TCP 経由で直接送信されたログ) は、raw、Syslog、または JSON 形式にすることができます。ペイロードが JSON 形式の場合、Datadog は自動的にその属性をパースします。
<DATADOG_API_KEY> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}
TCP エンドポイントは、このサイトでは推奨していません。詳しくはサポートにお問い合わせください。
このサイトでは、TCP エンドポイントはサポートされていません。
注:
- HTTPS API は、最大で 1MB のサイズのログをサポートします。ただし、最適なパフォーマンスには各ログが 25K バイトを超えないことをおすすめします。ログ作成に Datadog Agent を使用する場合、ログは 256kB (256000 バイト) に分割されるよう構成されています。
- 1 つのログイベントが持つことができるタグは 100 個以下です。1 日あたり最大 1,000 万個の一意のタグに対して、各タグは 256 文字を超えてはなりません。
- JSON 形式に変換されたログイベントが保持できる属性は 256 未満です。これらの各属性のキーは 50 文字未満、連続するネストのレベルは 20 未満、 それぞれの値は (ファセットに昇格した場合) 1024 文字未満となります。
- ログイベントは、過去 18 時間までのタイムスタンプで送信可能です。
上の制限に準拠しないログイベントは、システムによって変換されるか、切り詰められます。または、所定のタイムレンジ外の場合はインデックス化されません。ただし、Datadog はユーザーデータを可能な限り維持するよう全力を尽くします。
インデックス化されたログにのみ適用されるフィールドの追加の切り捨てがあります。message フィールドの値は 75 KiB に、非 message フィールドは 25 KiB に切り捨てられます。Datadog は完全なテキストを引き続き保存し、Logs Explorer の通常のリストクエリで表示されます。ただし、グループ化されたクエリを実行する際、例えばその切り捨てられたフィールドでログをグループ化する場合や、特定のフィールドを表示する操作を行う場合、切り捨てられたバージョンが表示されます。
属性とタグ
属性は、ログエクスプローラーでのフィルタリングと検索に使用されるログファセットを規定します。予約済み属性および標準属性のリストと、ログ属性とエイリアス設定を使用した命名規則のサポート方法については、専用の属性とエイリアス設定ドキュメントをご参照ください。
スタックトレースの属性
スタックトレースをログに記録するに当たっては、Datadog アプリケーション内に専用の UI 表示を持つ特別な属性があります。ロガー名、現在のスレッド、エラーの種類、スタックトレース自体などです。
この機能を使用するには、以下の属性名を使用します。
属性 | 説明 |
---|
logger.name | ロガーの名前 |
logger.thread_name | 現在のスレッドの名前 |
error.stack | 実際のスタックトレース |
error.message | スタックトレースに含まれるエラーメッセージ |
error.kind | エラーのタイプまたは「種類」(“Exception” や “OSError” など) |
注: インテグレーションパイプラインは、デフォルトのログライブラリパラメーターをこれらの属性に再マップし、スタックトレースをパースまたはトレースバックして、自動的に error.message
と error.kind
を抽出しようとします。
詳しくは、ソースコードと属性ドキュメントをご覧ください。
次のステップ
ログが収集されて取り込まれると、ログエクスプローラーで利用できるようになります。ログエクスプローラーでは、ログのアラートを検索、強化、表示できます。ログエクスプローラーのドキュメントを参照してログデータの分析を開始するか、以下の追加のログ管理ドキュメントを参照してください。
その他の参考資料
*Logging without Limits は Datadog, Inc. の商標です。