概要

Datadog のログ管理 (ログとも呼ばれます) を使用して、サーバー、コンテナ、クラウド環境、アプリケーション、既存のログプロセッサやフォワーダーなど、複数のロギングソースにまたがるログを収集します。従来のロギングでは、コスト効率を維持するために分析・保持するログを選択する必要がありました。Datadog Logging without Limits* では、ログの収集、処理、アーカイブ、探索、監視をログの制限なく行うことができます。

このページでは、Datadog でログ管理を始めるための方法を説明します。まだお持ちでない方は、Datadog アカウントを作成してください。

ロギングソースを構成する

ログ管理では、ログエクスプローラーでデータを分析・探索したり、トレーシングやメトリクスを接続して Datadog 全体で有益なデータを関連付けたり、取り込んだログを Datadog Cloud SIEM で使用したりすることができます。Datadog 内でのログのライフサイクルは、ログソースからログを取り込むところから始まります。

サーバー

サーバーから Datadog にログを転送する際には、いくつかのインテグレーションを使用することができます。インテグレーションは、サーバーから Datadog にログを転送するために、Agent のコンフィギュレーションディレクトリのルートにある conf.d/ フォルダの conf.yaml ファイル内のログコンフィギュレーションブロックを使用します。

logs:
  - type: file
    path: /path/to/your/integration/access.log
    source: integration_name
    service: integration_name
    sourcecategory: http_web_access

サーバーからログの収集を開始するには

1. まだインストールしていない場合は、お使いのプラットフォームに応じた Datadog Agent をインストールしてください。

   注意: ログ収集には Datadog Agent v6 以降が必要です。

2. Datadog Agent では、ログの収集はデフォルトで有効になっていません。ログ収集を有効にするには、datadog.yaml ファイルで logs_enabled を true に設定してください。

   datadog.yaml

   Copy

   ## @param logs_enabled - boolean - optional - default: false
       ## @env DD_LOGS_ENABLED - boolean - optional - default: false
       ## Enable Datadog Agent log collection by setting logs_enabled to true.
       logs_enabled: false
       
       ## @param logs_config - custom object - optional
       ## Enter specific configurations for your Log collection.
       ## Uncomment this parameter and the one below to enable them.
       ## See https://docs.datadoghq.com/agent/logs/
       logs_config:
       
         @param container_collect_all - boolean - optional - default: false
         @env DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL - boolean - optional - default: false
         Enable container log collection for all the containers (see ac_exclude to filter out containers)
         container_collect_all: false
       
         @param logs_dd_url - string - optional
         @env DD_LOGS_CONFIG_LOGS_DD_URL - string - optional
         Define the endpoint and port to hit when using a proxy for logs.
         As of agent version 7.70.0, proxy paths are supported. To forward logs to a
         specific proxy path, the URL scheme must be specified: https://proxy.example.com:443/logs
         logs_dd_url: <ENDPOINT>:<PORT>
       
         @param logs_no_ssl - boolean - optional - default: false
         @env DD_LOGS_CONFIG_LOGS_NO_SSL - optional - default: false
         Disable the SSL encryption. This parameter should only be used when logs are
         forwarded locally to a proxy. It is highly recommended to then handle the SSL encryption
         on the proxy side.
         logs_no_ssl: false
       
         @param processing_rules - list of custom objects - optional
         @env DD_LOGS_CONFIG_PROCESSING_RULES - list of custom objects - optional
         Global processing rules that are applied to all logs. The available rules are
         "exclude_at_match", "include_at_match" and "mask_sequences". More information in Datadog documentation:
         https://docs.datadoghq.com/agent/logs/advanced_log_collection/#global-processing-rules
         processing_rules:
           - type: <RULE_TYPE>
             name: <RULE_NAME>
             pattern: <RULE_PATTERN>
       
         @param auto_multi_line_detection - boolean - optional - default: false
         @env DD_LOGS_CONFIG_AUTO_MULTI_LINE_DETECTION - boolean - optional - default: false
         Enable automatic aggregation of multi-line logs for common log patterns.
         More information can be found in Datadog documentation:
         https://docs.datadoghq.com/agent/logs/auto_multiline_detection/?tab=configurationfile
         auto_multi_line_detection: true
       
         @param force_use_http - boolean - optional - default: false
         @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false
         Set this parameter to `true` to always send logs via HTTP(S) protocol and never fall back to
         raw TCP forwarding (recommended).
         #
         By default, the Agent sends logs in HTTPS batches if HTTPS connectivity can
         be established at Agent startup, and falls back to TCP otherwise. This parameter
         can be used to override this fallback behavior. It is recommended, but not the default, to
         maintain compatibility with previous Agent versions.
         #
         Note, the logs are forwarded via HTTPS (encrypted) by default. Please use `logs_no_ssl` if you
         need unencrypted HTTP instead.
         force_use_http: true
       
         @param http_protocol - string - optional - default: auto
         @env DD_LOGS_CONFIG_HTTP_PROTOCOL - string - optional - default: auto
         The transport type to use for sending logs. Possible values are "auto" or "http1".
         http_protocol: auto
       
         @param http_timeout - integer - optional - default: 10
         @env DD_LOGS_CONFIG_HTTP_TIMEOUT - integer - optional - default: 10
         The HTTP timeout to use for sending logs, in seconds.
         http_timeout: 10
       
         @param force_use_tcp - boolean - optional - default: false
         @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false
         By default, logs are sent via HTTP protocol if possible, set this parameter
         to `true` to always send logs via TCP. If `force_use_http` is set to `true`, this parameter
         is ignored.
         force_use_tcp: true
       
         @param use_compression - boolean - optional - default: true
         @env DD_LOGS_CONFIG_USE_COMPRESSION - boolean - optional - default: true
         This parameter is available when sending logs via HTTP protocol. If enabled, the Agent
         compresses logs before sending them.
         use_compression: true
       
         @param compression_level - integer - optional - default: 6
         @env DD_LOGS_CONFIG_COMPRESSION_LEVEL - boolean - optional - default: false
         The compression_level parameter accepts values from 0 (no compression)
         to 9 (maximum compression but higher resource usage). Only takes effect if
         `use_compression` is set to `true`.
         compression_level: 6
       
         @param batch_wait - integer - optional - default: 5
         @env DD_LOGS_CONFIG_BATCH_WAIT - integer - optional - default: 5
         The maximum time (in seconds) the Datadog Agent waits to fill each batch of logs before sending.
         batch_wait: 5
       
         @param close_timeout - integer - optional - default: 60
         @env DD_LOGS_CONFIG_CLOSE_TIMEOUT - integer - optional - default: 60
         The maximum number of seconds the Agent spends reading from a file after it has been rotated.
         close_timeout: 60
       
         @param open_files_limit - integer - optional - default: 500
         @env DD_LOGS_CONFIG_OPEN_FILES_LIMIT - integer - optional - default: 500
         The maximum number of files that can be tailed in parallel.
         Note: the default for Mac OS is 200. The default for
         all other systems is 500.
         open_files_limit: 500
       
         @param file_wildcard_selection_mode - string - optional - default: `by_name`
         @env DD_LOGS_CONFIG_FILE_WILDCARD_SELECTION_MODE - string - optional - default: `by_name`
         The strategy used to prioritize wildcard matches if they exceed the open file limit.
         #
         Choices are `by_name` and `by_modification_time`.
         #
         `by_name` means that each log source is considered and the matching files are ordered
         in reverse name order. While there are less than `logs_config.open_files_limit` files
         being tailed, this process repeats, collecting from each configured source.
         #
         `by_modification_time` takes all log sources and first adds any log sources that
         point to a specific file. Next, it finds matches for all wildcard sources.
         This resulting list is ordered by which files have been most recently modified
         and the top `logs_config.open_files_limit` most recently modified files are
         chosen for tailing.
         #
         WARNING: `by_modification_time` is less performant than `by_name` and will trigger
         more disk I/O at the configured wildcard log paths.
         file_wildcard_selection_mode: by_name
       
         @param max_message_size_bytes - integer - optional - default: 900000
         @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 900000
         The maximum size of single log message in bytes. If maxMessageSizeBytes exceeds
         the documented API limit of 1MB - any payloads larger than 1MB will be dropped by the intake.
         https://docs.datadoghq.com/api/latest/logs/
         max_message_size_bytes: 900000
       
         @param integrations_logs_files_max_size - integer - optional - default: 10
         @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_FILES_MAX_SIZE - integer - optional - default: 10
         The max size in MB that an integration logs file is allowed to use
         integrations_logs_files_max_size: 10
       
         @param integrations_logs_total_usage - integer - optional - default: 100
         @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_TOTAL_USAGE - integer - optional - default: 100
         The total combined usage all integrations logs files can use
         integrations_logs_total_usage: 100
       
         @param kublet_api_client_read_timeout - duration - optional - default: 30s
         @env DD_LOGS_CONFIG_KUBELET_API_CLIENT_READ_TIMEOUT - duration - optional - default: 30s
         Configure the kubelet API client's timeout used while streaming logs.
         kublet_api_client_read_timeout: 30
       
         @param k8s_container_use_kubelet_api - boolean - optional - default: false
         @env DD_LOGS_CONFIG_K8S_CONTAINER_USE_KUBELET_API - boolean - optional - default: false
         Enable container log collection via the kubelet API, typically used for EKS Fargate
         k8s_container_use_kubelet_api: false
       
         @param streaming - custom object - optional
         This section allows you to configure streaming logs via remote config.
         streaming:
           @param streamlogs_log_file - string - optional
           @env DD_LOGS_CONFIG_STREAMING_STREAMLOGS_LOG_FILE - string - optional
           Path to the file containing the streamlogs log file.
           Default paths:
             * Windows: c:\\programdata\\datadog\\logs\\streamlogs_info\\streamlogs.log
             * Unix: /opt/log/datadog/streamlogs_info/streamlogs.log
             * Linux: /var/log/datadog/streamlogs_info/streamlogs.log
           streamlogs_log_file: <path_to_streamlogs_log_file>

3. Datadog Agent を再起動します。

4. Datadog サイトのインテグレーション起動手順またはカスタムファイルのログ収集手順に従ってください。

   注: カスタムファイルからログを収集していて、テールファイル、TCP/UDP、journald、Windows Events の例が必要な場合は、カスタムログ収集を参照してください。

コンテナ

Datadog Agent v6 では、Agent がコンテナからログを収集することができるようになりました。それぞれのコンテナ化サービスには、Agent をどこにデプロイまたは実行するか、ログをどのようにルーティングするかなどに関する特定のコンフィギュレーション手順があります。

例えば、Docker では、Agent を Docker 環境の外部に設置するお客様のホスト上でのインストールと、コンテナ化された Agent を Docker 環境にデプロイするという 2 つの異なるタイプが用意されています。

Kubernetes では、Kubernetes クラスター内で Datadog Agent を動作させる必要があります。ログ収集の設定は DaemonSet spec、Helm チャート、または Datadog Operator を使用して行います。

コンテナサービスからのログ収集を開始するには、アプリ内の手順に従ってください。

クラウド

AWS、Azure、Google Cloud など、複数のクラウドプロバイダーのログを Datadog に転送することができます。各クラウドプロバイダーにより、それぞれコンフィギュレーション手順が異なります。

例えば、AWS サービスのログは通常、S3 バケットや CloudWatch ロググループに保存されています。これらのログを購読し、Amazon Kinesis ストリームに転送して、1 つまたは複数の宛先に転送することができます。Datadog は、Amazon Kinesis 配信ストリームのデフォルトの転送先の1つです。

クラウドサービスからのログ収集を開始するには、アプリ内の手順に従ってください。

クライアント

Datadog では、SDK やライブラリを使ってクライアントからログを収集することができます。たとえば、datadog-logs SDKを使用して、JavaScript クライアントから Datadog にログを送信します。

クライアントからのログ収集を開始するには、アプリ内の手順に従ってください。

その他

rsyslog、FluentD、Logstash などの既存のログサービスやユーティリティを使用している場合は、Datadog のプラグインやログ転送オプションをご利用いただけます。

インテグレーションが表示されない場合は、other integrations ボックスに入力すると、そのインテグレーションが利用可能になったときに通知を受け取ることができます。

クラウドサービスからのログ収集を開始するには、アプリ内の手順に従ってください。

ログの探索

ロギングソースを構成すると、ログをログエクスプローラーで確認できます。ここでログをフィルタリング・集約・可視化することができます。

例えば、あるサービスから流れてくるログをさらに調査するには、service でフィルタリングします。さらに、ERROR などの status などでフィルタリングし、Group into Patterns を選択すると、サービスのどの部分で最も多くのエラーが記録されているかを確認することができます。

ログを Fields に集計し、トップリストとして可視化すると、上位のログサービスを確認することができます。info や warn のようなソースを選択し、ドロップダウンメニューから View Logs を選択します。サイドパネルにはエラーに基づくログが表示されるため、注意が必要なホストやサービスをすぐに確認することができます。

次のステップ

ログソースが設定され、ログがログエクスプローラーに表示されるようになったら、ログ管理の他のいくつかのエリアの探索をはじめることができます。

ログコンフィギュレーション

• 属性とエイリアスを設定して、ログ環境を統一します。
• パイプラインやプロセッサーを使って、ログの処理方法をコントロールすることができます。
• Logging without Limits* では、ログの取り込みとインデックス処理を分離しているため、ログを構成して、インデックス化するログ、保持するログ、アーカイブするログを選択することができます。

ログの相関付け

• ログとトレースを接続して、特定の env、service,、または version に関連する正確なログを表示します。
• Datadog ですでにメトリクスを使用している場合は、ログとメトリクスを相関付けることで、問題のコンテキストを取得することができます。

ガイド

• ログ管理のベストプラクティス
• Logging without Limits* の詳細
• RBAC 設定による機密ログデータの管理

関連情報

お役に立つドキュメント、リンクや記事:

ログ管理の紹介ラーニングセンター ログ処理を極めるラーニングセンター インデックス化ログボリュームの管理と監視ラーニングセンター ログパイプラインの構築と管理ラーニングセンター インテグレーションパイプラインですぐに使えるログの処理ラーニングセンター ログ収集とインテグレーションドキュメント 統合サービスタグ付けの構成方法を学ぶドキュメント ログ管理を最適化するためのインタラクティブセッションにご参加くださいFOUNDATION ENABLEMENT