【初心者向け】Datadog入門|導入・設定から監視、APM、ログ分析まで徹底解説

はじめに

近年の IT システムは、マイクロサービスやコンテナ、クラウド環境の普及によって急速に複雑化しています。こうした環境では、単なる「監視(Monitoring)」だけでは障害の原因特定や予兆検知に十分対応できません。そこで注目されているのが Observability(オブザーバビリティ:可観測性) です。

オブザーバビリティは、システムの メトリクス(Metrics)・ログ(Logs)・トレース(Traces) を統合的に活用して、複雑な環境を深く理解するための考え方です。そして、このオブザーバビリティをクラウド型で手軽に実現できる代表的なサービスが Datadog です。Datadog はサーバーやクラウド、コンテナ、アプリケーションなど幅広い対象をカバーし、初心者でも導入しやすいオブザーバビリティプラットフォームとして人気を集めています。

本記事では、Datadog初心者向けに監視とオブザーバビリティの違いや、Datadogの導入方法と基本的な使い方をわかりやすく解説します。これから自宅のラボ環境や実システムに Datadog を導入したい方は、ぜひ参考にしてください。

オブザーバビリティとは

オブザーバビリティとは、多様なデータを統合的に収集・分析することで、システム内部の状態をより深く理解できる仕組みです。モニタリングとの違いを明確にすることで、理解が深まります。

モニタリング(監視)

モニタリングは、運用中のシステムで「何が起きているのか」を把握するためにデータを収集する仕組みです。主な目的は問題の検出であり、既知の問題や想定されたシナリオに基づいて、あらかじめ設定したメトリクスやログを収集・可視化し、必要に応じてアラートを通知します。

Datadogにおける代表的なモニタリング機能は以下の通りです。

  • インフラ監視
    CPU / メモリ / ディスク / ネットワーク使用率、死活監視、プロセス監視など
  • アラート
    閾値を超えた際に通知(例:CPU使用率が90%以上でメール通知)
  • ダッシュボード
    リアルタイムでのメトリクス可視化

オブザーバビリティ(可観測性)

一方でオブザーバビリティは、収集したデータを活用し「何が起きているのか」だけでなく「なぜ起きているのか」までを理解する考え方です。

たとえば、CPU使用率が閾値を超えた場合、モニタリングだけでは急増の理由までは分かりません。しかしオブザーバビリティを導入すると、

  • どのアプリケーションの処理がCPUを消費しているか
  • どのSQLクエリがリソースを占有しているか
  • どのログと関連しているか

といった情報まで追跡でき、原因特定が格段に速くなります。

オブザーバビリティを支える代表的なデータとして、メトリクス・ログ・トレースの3つがあります。

  • メトリクス
    時系列で環境の状態を追跡する定量的なデータ。CPUやメモリ使用率、レスポンスタイム、リクエスト数などを計測します。
  • ログ
    システムが出力するイベントの記録。アクセスログ、エラーログ、セキュリティログなどを蓄積し、「いつ何が起きたか」を把握できます。タイムスタンプが特に重要です。
  • トレース
    アプリケーションがリクエストを処理する時間や状態を追跡するデータ。マイクロサービスや複数コンポーネントにまたがる処理の流れを可視化し、「どこで何が起きているのか」を明らかにします。

Datadogで何ができる?

Datadogは、サーバやネットワーク、アプリケーション、データベースなど、システムを構成するさまざまなコンポーネントを一元的に監視・分析できるオブザーバビリティプラットフォームです。

単純にCPU使用率やメモリ使用率を監視するだけでなく、「システムで何が起きているのか」「なぜ問題が発生しているのか」を調査するためのさまざまな機能が提供されています。

代表的な機能は以下のとおりです。

機能概要
Infrastructure MonitoringサーバやコンテナなどのCPU、メモリ、ディスク、ネットワークなどを監視
Log ManagementOSやミドルウェア、アプリケーションのログを収集・検索・分析
APMアプリケーションのリクエスト処理をトレースし、遅延やエラーの原因を分析
Database Monitoringデータベースの負荷やSQLの実行状況、待機時間などを分析
Network Monitoringホスト間のネットワーク通信やトラフィックを可視化
Synthetic MonitoringHTTPリクエストやブラウザ操作を定期的に実行し、サービスの正常性を監視
Real User Monitoring(RUM)実際のユーザーによるWebサイトやアプリケーションの利用状況・パフォーマンスを分析
Monitorsメトリクスやログなどを監視し、異常を検知した場合にアラートを通知

たとえばWebサービスのレスポンスが突然遅くなった場合、Infrastructure MonitoringでサーバのCPUやメモリを確認し、APMで処理時間の長いリクエストを特定できます。

さらにDatabase MonitoringでSQLの実行状況を確認したり、Log Managementで同じ時間帯に発生したエラーを検索したりすることで、問題の原因をさまざまな角度から調査できます。

このように、インフラ・アプリケーション・データベース・ログなどの情報をDatadog上で横断的に確認できることが大きな特徴です。

本記事では、この中でもインフラ監視、ログ管理、APM、Database Monitoringを中心に、実際にDatadogを導入・設定しながら基本的な使い方を解説していきます。

Datadogの導入方法と基本的な使い方

ここからは、Datadogの導入方法と基本的な使い方を説明します。14日間の無料トライアル期間が用意されているので、まずは試してみましょう。無料トライアルはこちらから登録できます。
https://www.datadoghq.com/free-datadog-trial

インフラ監視

まずは基本となるインフラ監視を試してみましょう。CPUやメモリ使用率などのメトリクスを可視化できます。Datadogのコンソールにログインして、各種操作を実施してください。

Agentインストール

インフラ監視を有効にするためには、対象サーバにAgentをインストールする必要があります。
Integration > Install Agents を押下します。

エージェントをインストールする対象のプラットフォームを選択してください。

インフラ監視とは直接関連しないですが、後ほど必要になりますので「Application Performance Monitoring」を有効にしておきます。

Select API Key を押下します。

API Keyを選択します。
Use API Key を押下します。

※APIキーは、AgentからDatadogへデータを送信する際などに使用する認証情報となります。

APIキーを埋め込んだ形で、Agentインストール対象サーバにて実行するコマンドが表示されます。

本コマンドを下記の通り実行して、Agentをインストールします。

[root@appserver ~]# DD_API_KEY=<YOUR_API_KEY> \
DD_SITE="ap1.datadoghq.com" \
DD_APM_INSTRUMENTATION_ENABLED=host \
DD_APM_INSTRUMENTATION_LIBRARIES=java:1,python:3,js:5,php:1,dotnet:3,ruby:2 \
bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 82305  100 82305    0     0   604k      0 --:--:-- --:--:-- --:--:--  604k

* Datadog Agent 7 install script v1.40.0

/usr/bin/systemctl

* Installing YUM sources for Datadog

Cache was expired
43 files removed

  Installing package(s): datadog-agent

Last metadata expiration check: 0:01:54 ago on Fri 19 Sep 2025 06:41:35 AM JST.
Dependencies resolved.
================================================================================
 Package               Architecture   Version             Repository       Size
================================================================================
Installing:
 datadog-agent         x86_64         1:7.70.2-1          datadog         154 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 154 M
Installed size: 154 M
Downloading Packages:
datadog-agent-7.70.2-1.x86_64.rpm                18 MB/s | 154 MB     00:08
--------------------------------------------------------------------------------
Total                                            18 MB/s | 154 MB     00:08
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Running scriptlet: datadog-agent-1:7.70.2-1.x86_64                        1/1
Failed to stop datadog-agent-process.service: Unit datadog-agent-process.service not loaded.
Failed to stop datadog-agent-sysprobe.service: Unit datadog-agent-sysprobe.service not loaded.
Failed to stop datadog-agent-trace.service: Unit datadog-agent-trace.service not loaded.
Failed to stop datadog-agent-security.service: Unit datadog-agent-security.service not loaded.
Failed to stop datadog-agent.service: Unit datadog-agent.service not loaded.
Failed to disable unit: Unit file datadog-agent-process.service does not exist.
Failed to disable unit: Unit file datadog-agent-sysprobe.service does not exist.
Failed to disable unit: Unit file datadog-agent-trace.service does not exist.
Failed to disable unit: Unit file datadog-agent-security.service does not exist.
Failed to disable unit: Unit file datadog-agent.service does not exist.

  Installing       : datadog-agent-1:7.70.2-1.x86_64                        1/1
  Running scriptlet: datadog-agent-1:7.70.2-1.x86_64                        1/1
Creating file: '/opt/datadog-agent/.post_python_installed_packages.txt'
File '/opt/datadog-agent/.diff_python_installed_packages.txt' not found.

  Verifying        : datadog-agent-1:7.70.2-1.x86_64                        1/1

Installed:
  datadog-agent-1:7.70.2-1.x86_64

Complete!

* Adding your API key to the Datadog Agent configuration: /etc/datadog-agent/datadog.yaml


* Setting SITE in the Datadog Agent configuration: /etc/datadog-agent/datadog.yaml

/usr/bin/systemctl
* Starting the Datadog Agent...

  Your Datadog Agent is running and functioning properly.
  It will continue to run in the background and submit metrics to Datadog.
  If you ever want to stop the Datadog Agent, run:

       systemctl stop datadog-agent

  And to run it again run:

       systemctl start datadog-agent

[root@appserver ~]#

下記の通り、Agentのステータスがactive (running) になっていることが確認できれば成功です。

[root@appserver jmx.d]# systemctl status datadog-agent
 datadog-agent.service - Datadog Agent
     Loaded: loaded (/usr/lib/systemd/system/datadog-agent.service; enabled; preset: disabled)
     Active: active (running) since Sun 2025-09-21 06:32:15 JST; 5s ago
   Main PID: 3897554 (agent)
      Tasks: 9 (limit: 23168)
     Memory: 33.2M
        CPU: 4.844s
     CGroup: /system.slice/datadog-agent.service
             3897554 /opt/datadog-agent/bin/agent/agent run -p /opt/datadog-agent/run/agent.pid

Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/forwarder/defaultforwa>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/core/ipc/impl@v0.70.2/>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/core/ipc/impl@v0.70.2/>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (pkg/process/metadata/worklo>
Sep 21 06:32:20 appserver agent[3897554]: 2025-09-21 06:32:20 JST | CORE | INFO | (comp/core/tagger/impl/tagge>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (comp/forwarder/defaultforwa>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/demultiplexe>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/demultiplexe>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/time_sampler>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/runtime/runtime.go:28 i>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (comp/logs/agent/agentimpl/a>
lines 1-21/21 (END)

下記の通り、Agentがインストールされたことが確認できるはずです。

続いて、ダッシュボードを確認してみましょう。

Host Metrics を選択します。

下記の通り、Agentをインストールしたサーバのメトリクスが表示されたら成功です。
CPU、メモリ、ディスク、NWなどの各種リソース情報が確認できます。

各種ミドルウェアのメトリクス取得

各種ミドルウェアのメトリクスを取得するための手順を説明します。

 Postgresのメトリクス取得

試しにPostgreSQLのメトリクス取得について順を追ってみていきましょう。
Installations >Installations を押下します。

対象ミドルウェアに対して、+ ADD を押下します。

Install Integration を押下する。

Postgres – Metrics を押下します。

下記のようにPostgresのメトリクスが表示されるはずです。

 JVMのメトリクス取得

続いて、JVMのメトリクスを確認してみましょう。Javaアプリケーションの安定運用には欠かせない指標ですので、監視対象として設定することをおすすめします。

まず、上記のPostgres同様に Java のAgentをインストールしてください。

次に、Tomcat側でJMX(Java Management Extensions)の設定を有効にします。本手順については別の記事に記載しているので、下記を参照ください。
https://eeengineer.com/tomcat-jmx-enable-ssl-auth-monitoring/

続いて、DatadogのAgent側の設定を変更します。conf.yamlファイルのサンプルを記載しますので、参考にしてください。

[root@appserver ~]# vi /etc/datadog-agent/conf.d/jmx.d/conf.yaml
[root@appserver ~]# cat /etc/datadog-agent/conf.d/jmx.d/conf.yaml
instances:

  - host: localhost
    port: 9010  # Tomcat JMX port
    name: tomcat
    collect_default_metrics: false

    conf:
      # Full GC (Old Generation)
      - include:
          domain: java.lang
          bean: type=GarbageCollector,name=G1\ Old\ Generation
          attribute:
            - CollectionCount
            - CollectionTime
          metric_prefix: jvm.gc.old

      # Young GC (Eden)
      - include:
          domain: java.lang
          bean: type=GarbageCollector,name=G1\ Young\ Generation
          attribute:
            - CollectionCount
            - CollectionTime
          metric_prefix: jvm.gc.new

      # Heap New (Eden space)
      - include:
          domain: java.lang
          bean: type=MemoryPool,name=G1\ Eden\ Space
          attribute:
            - Usage.used
            - Usage.max
          metric_prefix: jvm.memory.new

      # Heap Old
      - include:
          domain: java.lang
          bean: type=MemoryPool,name=G1\ Old\ Gen
          attribute:
            - Usage.used
            - Usage.max
          metric_prefix: jvm.memory.old

      # Metaspace (Java8+)
      - include:
          domain: java.lang
          bean: type=MemoryPool,name=Metaspace
          attribute:
            - Usage.used
            - Usage.max
          metric_prefix: jvm.memory.metaspace

      # Thread metrics
      - include:
          domain: java.lang
          bean: type=Threading
          attribute:
            - ThreadCount
            - PeakThreadCount
            - DaemonThreadCount
          metric_prefix: jvm.threads

      # Class loading metrics
      - include:
          domain: java.lang
          bean: type=ClassLoading
          attribute:
            - LoadedClassCount
            - UnloadedClassCount
          metric_prefix: jvm.classes

      # CPU usage metrics
      - include:
          domain: java.lang
          bean: type=OperatingSystem
          attribute:
            - ProcessCpuLoad
            - SystemCpuLoad
          metric_prefix: jvm.cpu

      # Tomcat connector threads
      - include:
          domain: Catalina
          bean: type=ThreadPool,name=http-nio-8080
          attribute:
            - currentThreadCount
            - currentThreadsBusy
            - maxThreads
          metric_prefix: tomcat.threads

      # Tomcat session metrics
      - include:
          domain: Catalina
          bean: type=Manager,context=/,host=localhost
          attribute:
            - activeSessions
            - sessionCounter
          metric_prefix: tomcat.sessions

Datadogのエージェントを再起動します。

[root@appserver ~]# systemctl restart datadog-agent
[root@appserver ~]# systemctl status datadog-agent
 datadog-agent.service - Datadog Agent
     Loaded: loaded (/usr/lib/systemd/system/datadog-agent.service; enabled; preset: disabled)
     Active: active (running) since Sun 2025-09-21 06:32:15 JST; 5s ago
   Main PID: 3897554 (agent)
      Tasks: 9 (limit: 23168)
     Memory: 33.2M
        CPU: 4.844s
     CGroup: /system.slice/datadog-agent.service
             3897554 /opt/datadog-agent/bin/agent/agent run -p /opt/datadog-agent/run/agent.pid

Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/forwarder/defaultforwa>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/core/ipc/impl@v0.70.2/>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (comp/core/ipc/impl@v0.70.2/>
Sep 21 06:32:19 appserver agent[3897554]: 2025-09-21 06:32:19 JST | CORE | INFO | (pkg/process/metadata/worklo>
Sep 21 06:32:20 appserver agent[3897554]: 2025-09-21 06:32:20 JST | CORE | INFO | (comp/core/tagger/impl/tagge>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (comp/forwarder/defaultforwa>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/demultiplexe>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/demultiplexe>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/aggregator/time_sampler>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (pkg/runtime/runtime.go:28 i>
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | (comp/logs/agent/agentimpl/a>
lines 1-21/21 (END)
[root@appserver ~]#

ダッシュボードから JMX Metrics を押下します。

下記のように各種JVM関連のリソースが表示されれば成功です。

 Apacheのメトリクス取得

続いて、Apacheのメトリクスを確認してみましょう。リクエストがどのくらい来ているのかを確認できる重要な指標となりますので、監視対象として設定することをおすすめします。

まず、DatadogのApache Integrationを設定します。

続いて、DatadogのAgent側の設定を変更します。conf.yamlファイルのサンプルを記載しますので、参考にしてください。

[root@quiz apache.d]# vi /etc/datadog-agent/conf.d/apache.d/conf.yaml
[root@quiz apache.d]# cat /etc/datadog-agent/conf.d/apache.d/conf.yaml
init_config:

instances:
  - apache_status_url: https://127.0.0.1/server-status?auto
    disable_ssl_validation: true

[root@quiz apache.d]# systemctl restart datadog-agent
[root@quiz apache.d]#

※/etc/datadog-agent/conf.d/apache.d/ 配下に auto_conf.yaml が残っていると正常に動作しないため、退避しておきましょう。

ダッシュボードから Apache – Overviewを選択してください。

以下の通り各種メトリクスが表示されれば問題なく設定ができています。

“Status of worker threads”の画面を最大化すると下記のような画面になります。同時接続数に関する情報が確認できるため、有効な情報となります。

エージェントの設定

ログ監視の設定を有効にしてみましょう。
まずエージェント設定にて、logs_enabledの項目をtrueに設定してログ監視の設定を有効にします。

[root@appserver ~]# vi /etc/datadog-agent/datadog.yaml
[root@appserver ~]# cat /etc/datadog-agent/datadog.yaml
#########################
## Basic Configuration ##
#########################

## @param api_key - string - required
## @env DD_API_KEY - string - required
## The Datadog API key used by your Agent to submit metrics and events to Datadog.
## Create a new API key here: https://app.datadoghq.com/organization-settings/api-keys .
## Read more about API keys here: https://docs.datadoghq.com/account_management/api-app-keys/#api-keys .
api_key: 52bb3bd609fXXXXXXXXXXXXXXXXXXXX

~Output Truncated~

##################################
## Log collection Configuration ##
##################################

## @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: true

~Output Truncated~

続いて、サンプルとしてApacheのアクセスログとエラーログを監視する設定を追加してみましょう。

[root@appserver ~]# vi /etc/datadog-agent/conf.d/apache.d/conf.yaml
[root@appserver ~]# cat /etc/datadog-agent/conf.d/apache.d/conf.yaml
logs:
  # Apache access logs
  - type: file
    path: /var/log/httpd/access_log
    service: apache
    source: apache
    sourcecategory: http_access

  # Apache error logs
  - type: file
    path: /var/log/httpd/error_log
    service: apache
    source: apache
    sourcecategory: http_error
    # Optional: only collect WARN, ERROR, CRIT, ALERT, EMERG
    log_processing_rules:
      - type: include_at_match
        name: only_errors
        pattern: "(warn|error|crit|alert|emerg)"

[root@appserver ~]#

続いてDatadogのAgentが上記ログを参照できるように、権限を追加します。

[root@appserver ~]# setfacl -m u:dd-agent:x /var/log/httpd
[root@appserver ~]# setfacl -m u:dd-agent:r /var/log/httpd/access_log
[root@appserver ~]# setfacl -m u:dd-agent:r /var/log/httpd/error_log
[root@appserver ~]# sudo -u dd-agent tail -n 3 /var/log/httpd/error_log

dd-agentユーザでログを参照できるようになっているか、確認をしましょう。

[root@appserver ~]# sudo -u dd-agent tail -n 3 /var/log/httpd/access_log
147.185.132.103 - - [22/Sep/2025:06:24:17 +0900] "\x16\x03\x01" 400 226 "-" "-"
45.135.193.100 - - [22/Sep/2025:06:27:05 +0900] "GET / HTTP/1.1" 302 - "-" "-"
91.224.92.34 - - [22/Sep/2025:06:55:10 +0900] "\x16\x03\x01\x05\xa8\x01" 400 226 "-" "-"
[root@appserver ~]#
[root@appserver ~]# sudo -u dd-agent tail -n 3 /var/log/httpd/error_log
[Sun Sep 21 05:51:18.192859 2025] [proxy_http:error] [pid 3803544:tid 3803707] [client 106.72.183.131:5181] AH01114: HTTP: failed to make connection to backend: localhost
[Sun Sep 21 05:51:18.500838 2025] [proxy:error] [pid 3806244:tid 3806274] (111)Connection refused: AH00957: http: attempt to connect to 127.0.0.1:8080 (localhost:8080) failed
[Sun Sep 21 05:51:18.501112 2025] [proxy_http:error] [pid 3806244:tid 3806274] [client 106.72.183.131:25662] AH01114: HTTP: failed to make connection to backend: localhost, referer: https://quiz.eeengineer.com/quizapp
[root@appserver ~]#

上記設定変更が完了したら、Datadogのエージェントを再起動しましょう。
以上で設定は完了です。

ログ監視による情報取得

Datadogのコンソールから、ログ監視で取得できる情報を確認していきましょう。
Logs > Explorer を押下します。

Get Started を押下します。

Get Started を押下します。

ログを有効にしたいソースを選択し、ガイドに従って設定を追加してください。

今回は、Apacheのログ分析を設定しています。
Apacheにアクセスしてログを出力させます。下図の通り、Datadogのコンソールにログが出力されていれば成功です。

詳細を確認したいログをクリックしてください。
続けて、Metrics を押下します。

ダッシュボード上には CPU 使用率やメモリ使用量、ディスク I/O などの各種メトリクスが表示されます。これにより、ログが出力された時間帯におけるサーバーリソースやシステムの稼働状況をあわせて確認することが可能です。

APM(Application Performance Monitoring)

エージェントの設定

オブザーバビリティ製品の特長である、APM(Application Performance Monitoring)の設定を有効にしてみましょう。
まずは、Datadogの設定ファイルにてAPM機能を有効にします。apm_configenabled の項目を true にしてください。

[root@appserver ~]# vi /etc/datadog-agent/datadog.yaml
[root@appserver ~]# cat /etc/datadog-agent/datadog.yaml
~Output Truncated~

####################################
## Trace Collection Configuration ##
####################################

## @param apm_config - custom object - optional
## Enter specific configurations for your trace collection.
## Uncomment this parameter and the one below to enable them.
## See https://docs.datadoghq.com/agent/apm/
#
apm_config:

  ## @param enabled - boolean - optional - default: true
  ## @env DD_APM_ENABLED - boolean - optional - default: true
  ## Set to true to enable the APM Agent.
  #
  enabled: true

  ## @param env - string - optional - default: none
  ## @env DD_APM_ENV - string - optional - default: none
  ## The environment tag that Traces should be tagged with.
  ## If not set the value will be inherited, in order, from the top level

~Output Truncated~

[root@appserver ~]# systemctl restart datadog-agent
[root@appserver ~]#

続いて、Datadogが提供しているJava向けのトレーシングエージェントである dd-java-agent を配置します。

[root@appserver ~]# DD_AGENT_VERSION=latest
curl -L https://dtdg.co/latest-java-tracer -o /etc/datadog-agent/dd-java-agent.jar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   145  100   145    0     0    814      0 --:--:-- --:--:-- --:--:--   814
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 31.2M  100 31.2M    0     0  15.4M      0  0:00:02  0:00:02 --:--:-- 23.8M
[root@appserver ~]#
[root@appserver ~]# ll /etc/datadog-agent/dd-java-agent.jar
-rw-r--r-- 1 root root 32729838 Sep 23 22:23 /etc/datadog-agent/dd-java-agent.jar
[root@appserver ~]#

Tomcat起動時に本エージェントを起動させるために、setenv.shに下記設定を追加します。

[root@appserver ~]# vi /opt/tomcat/bin/setenv.sh
[root@appserver ~]# cat /opt/tomcat/bin/setenv.sh
~Output Truncated~

# Datadog APM Java Tracer settings
CATALINA_OPTS="$CATALINA_OPTS \
-javaagent:/etc/datadog-agent/dd-java-agent.jar \
-Ddd.service=spring-boot-app \
-Ddd.env=production \
-Ddd.version=1.0.0 \
-Ddd.agent.host=localhost \
-Ddd.trace.enabled=true"
[root@appserver ~]#
[root@appserver ~]# systemctl restart tomcat
[root@appserver ~]# 

以上で設定は完了です。

APMによる情報取得

それではDatadogのコンソールからAPMで取得できる項目を確認してみましょう。

APM > Services を押下します。

情報取得したいアプリケーションを選択します。

Performanceを押下します。
下記の通り、リクエスト数、エラー数やレイテンシー等のパフォーマンス情報が取得できるはずです。

Relationshipsを押下します。
各種コンポーネントの関係性が視覚化されるので便利です。

続いて、APM機能の真骨頂であるTracesを見てみましょう。
APM > Traces を押下します。

以下の通り、各リクエストに対するサマリ情報を確認することができます。試しにひとつ選択して、詳細を見てみましょう。

アプリ内部のどの処理で時間がかかっているのか、SQLがどこで実行されていて、どのくらい時間がかかっているか、などの詳細な情報を確認することができます。

Metrics を押下してみてください。当該処理が実行された時点の各種メトリクスを確認することができます。たとえば、レスポンスが遅延したと同じタイミングでガベージコレクションが起きていたかどうかといったことが即座に分かります。

SQL Queries を押下することで、SQLの具体的な処理内容まで確認することができます。

データベースモニタリング

PostgreSQLデータベースに対して、DatadogのDatabase Monitoring(DBM)を有効にする方法を説明します。

統計情報取得のための設定追加

postgresql.confでshared_preload_librariesにpg_stat_statementsを指定することで、PostgreSQLのSQL実行統計を取得できるようになります。設定追加したらpostgreSQLを再起動してください。

[root@appserver ~]# vi /var/lib/pgsql/data/postgresql.conf
[root@appserver ~]# cat /var/lib/pgsql/data/postgresql.conf
...omitted...
# Collecting performance statistics setting
shared_preload_libraries = 'pg_stat_statements'

# Enable collection of execution statistics
track_activities = on

# Track statistics for tables and indexes
track_counts = on

# Record timing information for I/O operations
track_io_timing = on

# Log sample queries (useful for detecting slow queries)
log_min_duration_statement = 1000   # Log SQL statements that take longer than 1 second
[root@appserver ~]#
[root@appserver ~]# systemctl restart postgresql
[root@appserver ~]#

PostgreSQL監視用ユーザの作成

DatadogでPostgreSQL のパフォーマンスやクエリ状況を監視するためには、専用の監視ユーザーを作成し、必要な権限を与える必要があります。
まず、PostgreSQLデータベースにログインして、DatadogによるPostgreSQL監視用のユーザを作成します。

postgres=# create user datadog with password 'yourpassword';
CREATE ROLE
postgres=#

Datadog 専用のスキーマdatadogを作成します。

postgres=# CREATE SCHEMA datadog;
CREATE SCHEMA
postgres=#

監視用ユーザdatadogがスキーマ内のオブジェクトにアクセスできるように権限を付与します。

postgres=# GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT
postgres=#

統計情報閲覧用ロールを付与します。

postgres=# GRANT pg_monitor TO datadog;
GRANT
postgres=#

クエリ性能分析のための拡張設定を有効にします。

postgres=# CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION
postgres=#

指定したSQL文の実行計画をJSON形式で取得できる関数を、Datadogユーザが利用できるように作成します。

postgres=# CREATE OR REPLACE FUNCTION datadog.explain_statement(
   l_query TEXT,
   OUT explain JSON
)
RETURNS SETOF JSON AS
$$
DECLARE
curs REFCURSOR;
plan JSON;

BEGIN
   OPEN curs FOR EXECUTE pg_catalog.concat('EXPLAIN (FORMAT JSON) ', l_query);
   FETCH curs INTO plan;
   CLOSE curs;
   RETURN QUERY SELECT plan;
END;
$$
LANGUAGE 'plpgsql'
RETURNS NULL ON NULL INPUT
SECURITY DEFINER;
CREATE FUNCTION
quiz=#

以上で設定は完了です。統計情報が取得できるようになっていることを確認してみましょう。下記の通り、レコードが取得できれば成功です。

postgres-# \q
[postgres@quiz ~]$
[postgres@quiz ~]$ psql -h localhost -U datadog -d postgres -A -c "select * from pg_stat_database limit 1;"
Password for user datadog:
datid|datname|numbackends|xact_commit|xact_rollback|blks_read|blks_hit|tup_returned|tup_fetched|tup_inserted|tup_updated|tup_deleted|conflicts|temp_files|temp_bytes|deadlocks|checksum_failures|checksum_last_failure|blk_read_time|blk_write_time|session_time|active_time|idle_in_transaction_time|sessions|sessions_abandoned|sessions_fatal|sessions_killed|stats_reset
0||0|0|0|72|530420|201511|118897|3|0|0|0|0|0|0|||0|0|0|0|0|0|0|0|0|
(1 row)
[postgres@quiz ~]$
[postgres@quiz ~]$ psql -h localhost -U datadog -d postgres -A -c "select * from pg_stat_activity limit 1;"
Password for user datadog:
datid|datname|pid|leader_pid|usesysid|usename|application_name|client_addr|client_hostname|client_port|backend_start|xact_start|query_start|state_change|wait_event_type|wait_event|state|backend_xid|backend_xmin|query_id|query|backend_type
||216421||||||||2025-10-19 06:30:17.392103+09||||Activity|AutoVacuumMain||||||autovacuum launcher
(1 row)
[postgres@quiz ~]$

データベースモニタリングによる情報取得

それでは、DatadogのコンソールからDatabase Monitoringの画面を確認してみましょう。
APM > Database Monitoring を押下します。

監視したいホストを選択します。

queryのスループットや処理時間等の基本的な情報が取得できているはずです。

Top queryのような情報も確認できます。

Query Metricsを選択することで、より詳細な情報も確認できます。

<参考>代表的なオブザーバビリティ製品の比較

Datadogは代表的なオブザーバビリティ製品の一つであり、これまではDynatraceやNew Relicと並んで三強とされてきました。しかし近年では、Grafana Labsの評価も高まり、注目度が増しています。

出展:2025 Gartner® Magic Quadrant™ for Observability Platforms

Datadog、Dynatrace、New Relic、Grafana Labsの4製品を比較した内容は、次の表のとおりです。

項目DatadogDynatraceNew RelicGrafana Labs
特徴インフラ、ログ、APMなどを統合的に監視フルスタックの監視・分析に対応APMを中心に幅広い監視機能を提供Grafanaを中心としたOSSエコシステム
提供形態SaaSSaaS / ManagedSaaSOSS / Grafana Cloud
インフラ監視
ログ管理
APM / トレース
主な強み導入しやすく、インフラ・ログ・APMなどを横断的に分析しやすい自動検出や依存関係の可視化、根本原因分析に強いAPMを中心に統合されたオブザーバビリティ機能OSSを活用した柔軟な監視環境を構築しやすい
向いているケースクラウドやコンテナを含むシステムを一元監視したい場合大規模システムを詳細に監視・分析したい場合アプリケーション性能を中心に監視したい場合OSSを活用して柔軟に監視基盤を構築したい場合

各製品にはそれぞれ特徴がありますが、本記事では導入が比較的容易で、インフラ・ログ・APM・データベースなどを横断的に監視できるDatadogを使用して、基本的なオブザーバビリティ環境を構築しています。

まとめ

Datadogを利用すると、CPUやメモリなどのインフラ監視だけでなく、ログ、APM、データベースなどの情報を一元的に収集・分析できます。

特に、メトリクス・ログ・トレースを横断的に確認できるため、「何が起きているのか」だけでなく「なぜ問題が発生したのか」を調査しやすい点が大きなメリットです。

本記事では、Datadog Agentの導入からインフラ監視、ログ監視、APM、Database Monitoringまで実際の設定例を紹介しました。まずはインフラ監視から導入し、必要に応じてログやAPM、Database Monitoringへ監視範囲を広げていくと理解しやすいでしょう。

コメント