Datadog入門:監視とオブザーバビリティの違いから導入・設定方法まで徹底解説

はじめに

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

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

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

オブザーバビリティとは

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

モニタリング(監視)

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

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

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

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

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

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

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

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

オブザーバビリティを支える主要な機能として以下の3要素が定義されています。

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

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

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

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

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

項目DatadogDynatraceNew RelicGrafana Labs
特徴SaaSネイティブで急成長エンタープライズ向けフルスタックAPMAPMの老舗OSS起点で可視化のデファクト
提供形態SaaSのみ・SaaS
・On-Prem (Dynatrace Managed)
SaaSのみ・OSS(無料)
・SaaS(Grafana Cloud)
・Enterprise
強み・導入が簡単
・クラウド連携が得意
・ダッシュボード豊富
・自動検出・依存関係マップ
・大規模システム実績
・高信頼性
・単一UIでシンプル
・従量課金で小規模導入しやすい
・Kubernetes/マイクロサービス監視に強い ・OSSコミュニティ基盤
AI/自動化・シンプルなアラート最適化
・ログパターン分析
Davis AI による根本原因分析・自己修復支援が強力自動化は限定的・自動化は弱め
・拡張はユーザー任せ
導入しやすさ非常に容易(エージェント導入直後に可視化可能)導入は複雑(設計・PoC必要、導入支援が前提)UIが直感的で導入しやすい・OSSは構築に知識必須
・SaaSは比較的容易
対象ユーザースタートアップ〜中規模クラウド事業者金融、通信など大規模エンタープライズSaaS事業者、中小〜中堅企業OSS志向エンジニアチーム、Kubernetesユーザー
課金モデル従量課金(データ量ベース)ホスト単位+機能別ライセンス従量課金(ユーザー数+データ量)OSS=無料、SaaS/Enterpriseはサブスク
UI/UX・視覚的にわかりやすい
・ダッシュボード豊富
情報量重視で複雑だが高機能初心者に優しくシンプル自由度が高いが設計力が必要
マーケット印象(グローバル)クラウドネイティブの代表格、急成長中。エンタープライズ領域で高い信頼APMの老舗だが成長スピードはやや鈍化OSS文化を背景に急伸。「第4の巨頭」候補。
マーケット印象(日本)スタートアップ〜Web系で人気増加。2024年度国内市場シェア34.7%(富士キメラ総研)知名度はやや限定的。導入は100社前後とされる老舗としての認知度が高く、国内シェア40.9%(同社発表)OSS利用は広いが商用サブスク導入は限定的

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キーは、Datadog のクラウドサービスにデータを送信したり、API 経由で操作を行ったりする際の認証情報です。

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

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

[root@appserver ~]# DD_API_KEY=52bb3bd609f81c1ced94d58138b4f892 \
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関連のリソースが表示されれば成功です。

ログ監視

エージェントの設定

ログ監視の設定を有効にしてみましょう。
まずエージェント設定にて、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にアクセスしてログを出力させます。下図の通り、Datadogのコンソールにログが出力されていれば成功です。

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

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

APM(Application Performance Monitoring)

エージェントの設定

オブザーバビリティ製品の特長である、APM(Application Performance Management)の設定を有効にしてみましょう。
まずは、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データベースに対して、APM機能の一部であるデータベースモニタリングの機能を有効にする方法をご説明します。

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

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を活用したオブザーバビリティの基本と具体的な導入手順を紹介しました。ポイントを整理すると以下の通りです。

  1. オブザーバビリティの理解
    • モニタリングは「何が起きているか」を把握する仕組み
    • オブザーバビリティは「なぜ起きているか」を分析する仕組み
    • メトリクス、ログ、トレースの3つを統合的に活用することで原因特定が迅速化
  2. Datadogの導入と基本設定
    • Datadog Agentをサーバにインストール
    • インフラ監視(CPU、メモリ、ディスクなど)を可視化
    • ミドルウェアやJVMのメトリクス取得も可能
  3. ログ監視
    • Apacheなどのログを収集・可視化
    • ログとメトリクスを組み合わせることでシステム状況をより深く理解
  4. APM(アプリケーションパフォーマンス監視)
    • Javaアプリにdd-java-agentを導入
    • リクエスト単位で処理時間やSQL実行状況を追跡可能
    • ボトルネックやパフォーマンス問題の特定に有効
  5. データベースモニタリング
    • PostgreSQLのパフォーマンス統計を収集
    • Datadog専用ユーザと権限設定でクエリ状況や処理時間を可視化
    • SQLパフォーマンスの分析が容易に

Datadogを活用することで、複雑なシステムでも可視化・分析がスムーズになり、障害の早期検知やパフォーマンス改善に役立ちます。まずは無料トライアルで試しながら、必要な機能を順に導入していくことがおすすめです。

コメント