Datadog Beginner’s Guide: Installation, Monitoring, APM, Logs, and Database Monitoring

Introduction

Modern IT systems are becoming increasingly complex due to the widespread adoption of microservices, containers, and cloud environments. In such environments, traditional monitoring alone is often not enough to identify the root cause of problems or detect early signs of failures. This is where observability has become increasingly important.

Observability is an approach that helps you gain deeper insight into complex systems by correlating metrics, logs, and traces. One of the leading cloud-based platforms for implementing observability is Datadog. Datadog supports a wide range of environments, including servers, cloud infrastructure, containers, and applications, and provides an observability platform that is relatively easy for beginners to get started with.

In this article, I will explain the difference between monitoring and observability, how to install Datadog, and how to use its basic features. If you are planning to introduce Datadog into your home lab or production environment, this guide will help you get started.

What Is Observability?

Observability is an approach that enables you to gain deeper insight into the internal state of a system by collecting and analyzing various types of data. Understanding how observability differs from traditional monitoring makes the concept easier to understand.

Monitoring

Monitoring is the process of collecting data to understand what is happening in a running system. Its primary purpose is to detect problems. Based on known issues and expected scenarios, predefined metrics and logs are collected and visualized, and alerts can be triggered when necessary.

Typical monitoring capabilities in Datadog include:

Infrastructure Monitoring
Monitor CPU, memory, disk, and network utilization, as well as host availability and processes.
Alerts
Send notifications when predefined thresholds are exceeded, such as when CPU utilization exceeds 90%.
Dashboards
Visualize metrics in real time.

Observability

Observability, on the other hand, uses collected data not only to understand what is happening, but also why it is happening.

For example, if CPU utilization exceeds a threshold, monitoring alone may tell you that CPU usage has increased, but it may not explain why. With observability, you can investigate information such as:

Which application or process is consuming CPU resources
Which SQL queries are consuming resources
Which logs are related to the issue

By correlating this information, you can identify the root cause of a problem much more quickly.

Three representative types of data commonly used in observability are metrics, logs, and traces.

Metrics
Quantitative time-series data used to track the state of a system, such as CPU utilization, memory usage, response time, and request count.
Logs
Records of events generated by systems and applications. Access logs, error logs, and security logs help you understand what happened and when it occurred. Timestamps are especially important when correlating events.
Traces
Data that tracks how requests are processed by an application. Traces visualize request flows across microservices and multiple components, helping identify where time is being spent and where problems occur.

What Can You Do with Datadog?

Datadog is an observability platform that enables you to centrally monitor and analyze various components of a system, including servers, networks, applications, and databases.

In addition to monitoring basic metrics such as CPU and memory utilization, Datadog provides a wide range of features that help you investigate what is happening in your system and why a problem is occurring.

Some of the main Datadog features are listed below.

Feature	Description
Infrastructure Monitoring	Monitor CPU, memory, disk, network, and other metrics for servers and containers.
Log Management	Collect, search, and analyze logs from operating systems, middleware, and applications.
APM	Trace application requests and analyze the causes of latency and errors.
Database Monitoring	Analyze database workloads, SQL query performance, wait time, and other database metrics.
Network Monitoring	Visualize network traffic and communication between hosts.
Synthetic Monitoring	Periodically execute HTTP requests and browser tests to monitor service availability and functionality.
Real User Monitoring (RUM)	Analyze application performance and user experience based on actual user interactions with websites and applications.
Monitors	Monitor metrics, logs, and other data and send alerts when abnormal conditions are detected.

For example, if a web service suddenly becomes slow, you can use Infrastructure Monitoring to check CPU and memory utilization on the server, and then use APM to identify requests with unusually high processing times.

You can then use Database Monitoring to investigate SQL query performance and Log Management to search for errors that occurred during the same time period. This allows you to investigate the problem from multiple perspectives.

One of Datadog’s major advantages is the ability to correlate infrastructure, application, database, and log data within a single platform.

In this article, I will focus on Infrastructure Monitoring, Log Management, APM, and Database Monitoring, and walk through the basic configuration and usage of each feature using a hands-on Datadog environment.

How to Install and Get Started with Datadog

Now, let’s walk through how to install Datadog and use its basic features. Datadog offers a 14-day free trial, so you can start by trying it in your own environment. You can sign up for the free trial here.
https://www.datadoghq.com/free-datadog-trial

Infrastructure Monitoring

Let’s start with Infrastructure Monitoring, one of Datadog’s core features. It allows you to visualize metrics such as CPU and memory utilization. Log in to the Datadog console and follow the steps below.

Installing the Datadog Agent

To enable Infrastructure Monitoring, you need to install the Datadog Agent on the target server.
Click Integration > Install Agents.

Select the platform on which you want to install the Datadog Agent.

Although it is not directly related to Infrastructure Monitoring, enable Application Performance Monitoring as well because we will use it later in this guide.

Click Select API Key.

Select an API key and click Use API Key.

Note: The API key is authentication information used by the Datadog Agent when sending data to Datadog.

Datadog will display an installation command containing the selected API key. Run this command on the server where you want to install the Agent.

Run the command as shown below to install the Datadog 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 ~]#

If the Agent status is displayed as active (running), as shown below, the installation was successful.

[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 | ...
Sep 21 06:32:20 appserver agent[3897554]: 2025-09-21 06:32:20 JST | CORE | INFO | ...
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | ...
lines 1-21/21 (END)

You should now be able to confirm that the Agent has been successfully installed.

Next, let’s check the dashboard.

Select Host Metrics.

If metrics from the server where you installed the Agent are displayed as shown below, the setup was successful.
You can monitor various system resources, including CPU, memory, disk, and network metrics.

Collecting Middleware Metrics

Next, let’s look at how to collect metrics from various middleware components.

PostgreSQL Metrics

As an example, let’s configure PostgreSQL metric collection step by step.
Click Installations > Installations.

Click + ADD for the middleware you want to monitor.

Click Install Integration.

Click Postgres – Metrics.

If the PostgreSQL metrics are displayed as shown below, the integration has been configured successfully.

JVM Metrics

Next, let’s check JVM metrics. These are essential metrics for maintaining the stability of Java applications, so it is highly recommended to include them in your monitoring setup.

As with PostgreSQL, first configure the Java integration.

Next, enable JMX (Java Management Extensions) on the Tomcat side. The detailed procedure is covered in a separate article, so please refer to the link below.
https://eeengineer.com/tomcat-jmx-enable-ssl-auth-monitoring/

Then, modify the Datadog Agent configuration. The following is a sample conf.yaml configuration.

[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

Restart the Datadog Agent.

[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 | ...
Sep 21 06:32:20 appserver agent[3897554]: 2025-09-21 06:32:20 JST | CORE | INFO | ...
Sep 21 06:32:21 appserver agent[3897554]: 2025-09-21 06:32:21 JST | CORE | INFO | ...
lines 1-21/21 (END)
[root@appserver ~]#

From the dashboard, click JMX Metrics.

If various JVM-related metrics are displayed as shown below, the configuration was successful.

Apache Metrics

Next, let’s check Apache metrics. These metrics are useful for understanding how many requests are being handled by the web server, so it is recommended to include them in your monitoring setup.

First, configure the Datadog Apache Integration.

Next, modify the Datadog Agent configuration. The following is a sample conf.yaml configuration.

[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]#

Note: If auto_conf.yaml remains under /etc/datadog-agent/conf.d/apache.d/, the integration may not work correctly. Move or rename the file before continuing.

From the dashboard, select Apache – Overview.

If the Apache metrics are displayed as shown below, the configuration is working correctly.

If you enlarge the “Status of worker threads” panel, you can view information related to Apache worker threads and concurrent connections, as shown below.

Configuring the Agent for Log Collection

Next, let’s enable log monitoring.
First, set logs_enabled to true in the Datadog Agent configuration.

[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~

Next, configure the Agent to collect Apache access and error logs.

[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 ~]#

Next, grant the Datadog Agent permission to read these log files.

[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

Verify that the dd-agent user can read the log files.

[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 ~]#

Once the configuration changes are complete, restart the Datadog Agent. This completes the log collection setup.

Viewing Logs in Datadog

Now, let’s check the information collected by Log Management in the Datadog console.
Click Logs > Explorer.

Click Get Started.

Click Get Started again.

Select the log source you want to enable and follow the on-screen guide to complete the configuration.

In this example, Apache log analysis is configured.
Access the Apache web server to generate log entries. If the logs appear in the Datadog console as shown below, the configuration was successful.

Click a log entry to view its details.
Then click Metrics.

The dashboard displays related metrics such as CPU utilization, memory usage, and disk I/O. This allows you to correlate log events with the server resource usage and system conditions at the same point in time.

“`html

APM (Application Performance Monitoring)

Configuring the Agent

Next, let’s enable APM (Application Performance Monitoring), one of the key features of an observability platform.
First, enable APM in the Datadog configuration file. Set enabled under apm_config to 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 ~]#

Next, download the dd-java-agent, the Java tracing agent provided by Datadog.

[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 ~]#

To load this agent when Tomcat starts, add the following settings to 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 ~]#

This completes the APM configuration.

Viewing APM Data

Now, let’s check the information collected by APM in the Datadog console.

Click APM > Services.

Select the application you want to analyze.

Click Performance.
You should be able to view performance information such as request count, error count, and latency.

Click Relationships.
This view visualizes the relationships between different system components, making it easier to understand application dependencies.

Next, let’s look at traces, one of the most powerful features of APM.
Click APM > Traces.

As shown below, you can view summary information for each request. Select one of the requests to examine it in more detail.

You can identify which internal application processes are taking the most time, where SQL queries are being executed, and how long each operation takes.

Click Metrics to view system metrics from the time when the request was processed. For example, you can quickly determine whether garbage collection occurred at the same time as an increase in response latency.

By clicking SQL Queries, you can also view detailed information about the SQL queries executed during the request.

Database Monitoring

Next, let’s configure Datadog Database Monitoring (DBM) for a PostgreSQL database.

Configuring PostgreSQL Statistics Collection

By specifying pg_stat_statements in shared_preload_libraries in postgresql.conf, PostgreSQL can collect SQL execution statistics. Restart PostgreSQL after applying the configuration.

[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 ~]#

Creating a PostgreSQL Monitoring User

To monitor PostgreSQL performance and query activity with Datadog, create a dedicated monitoring user and grant it the required permissions.
First, log in to PostgreSQL and create a user for Datadog monitoring.

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

Create a dedicated datadog schema.

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

Grant the datadog monitoring user permission to access objects in the schema.

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

Grant the built-in pg_monitor role so that the Datadog user can access PostgreSQL monitoring statistics.

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

Enable the pg_stat_statements extension for query performance analysis.

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

Create a function that allows the Datadog user to retrieve the execution plan of a specified SQL statement in JSON format.

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=#

The configuration is now complete. Verify that the monitoring user can retrieve PostgreSQL statistics. If records are returned as shown below, the configuration was successful.

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 ~]$

Viewing Database Monitoring Data

Now, let’s check the Database Monitoring screen in the Datadog console.
Click APM > Database Monitoring.

Select the host you want to monitor.

You should be able to view basic query information such as throughput and execution time.

You can also view information about top queries.

Select Query Metrics to view more detailed query performance information.

<Reference> Comparison of Popular Observability Platforms

Datadog is one of the major observability platforms available today. Dynatrace, New Relic, and Grafana Labs are also widely known platforms in this field.

Source: 2025 Gartner® Magic Quadrant™ for Observability Platforms

The following table provides a simple comparison of Datadog, Dynatrace, New Relic, and Grafana Labs.

Category	Datadog	Dynatrace	New Relic	Grafana Labs
Overview	Unified monitoring for infrastructure, logs, APM, and more	Full-stack monitoring and analysis	Broad observability capabilities centered around APM	Open-source ecosystem centered around Grafana
Deployment Model	SaaS	SaaS / Managed	SaaS	OSS / Grafana Cloud
Infrastructure Monitoring	○	○	○	○
Log Management	○	○	○	○
APM / Tracing	○	○	○	○
Main Strengths	Easy to deploy and useful for correlating infrastructure, logs, and APM data	Strong automated discovery, dependency visualization, and root cause analysis	Integrated observability capabilities with a strong focus on APM	Flexible monitoring environments built around open-source tools
Best Suited For	Organizations that want centralized monitoring across cloud, containers, applications, and infrastructure	Large-scale systems that require detailed monitoring and analysis	Teams that want to focus on application performance monitoring	Teams that want to build flexible monitoring environments using open-source technologies

Each platform has its own strengths. In this article, we used Datadog to build a basic observability environment because it is relatively easy to deploy and allows infrastructure, logs, APM, and databases to be monitored and analyzed from a single platform.

Conclusion

Datadog allows you to centrally collect and analyze not only infrastructure metrics such as CPU and memory utilization, but also logs, APM data, and database performance information.

One of its major advantages is the ability to correlate metrics, logs, and traces, making it easier to understand not only what is happening in a system, but also why a problem is occurring.

In this article, we walked through the installation of the Datadog Agent and covered Infrastructure Monitoring, Log Management, APM, and Database Monitoring using practical configuration examples. A good way to get started is to begin with infrastructure monitoring and then gradually expand your observability coverage to logs, APM, and databases as needed.