ログの使用を開始する

概要

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_enabledtrue に設定してください。

    datadog.yaml

    ## @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. The logs are forwarded in TCP
          ## therefore the proxy must be able to handle TCP connections.
          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 force_use_http - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false
          ## By default, the Agent sends logs in HTTPS batches to port 443 if HTTPS connectivity can
          ## be established at Agent startup, and falls back to TCP otherwise. Set this parameter to `true` to
          ## always send logs with HTTPS (recommended).
          ## Warning: force_use_http means HTTP over TCP, not HTTP over HTTPS. Please use logs_no_ssl for HTTP over HTTPS.
          force_use_http: true
        
          ## @param force_use_tcp - boolean - optional - default: false
          ## @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false
          ## By default, logs are sent through HTTPS 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 with HTTPS. 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 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: 256000
          ## @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 256000
          ## 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: 256000
        
          ## @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
        
          ## @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
  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 を選択すると、サービスのどの部分で最も多くのエラーが記録されているかを確認することができます。

Log Explorer でのエラーパターンによるフィルタリング

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

Log Explorer のトップリスト

次のステップ

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

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

ログの相関付け

ガイド

参考資料


*Logging without Limits は Datadog, Inc. の商標です。