Demo Monitoring

​

Prerequisites

• Ubuntu/Debian EC2 instance with sudo access.
• NGINX installed and running on the instance.
• Datadog account and API key.
• Basic familiarity with editing NGINX configuration files and reloading the service.

​

1. Install the Datadog Agent

DD_API_KEY="<YOUR_API_KEY>" DD_SITE="datadoghq.eu" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

• Add the Datadog apt repository and import signing keys.
• Install the datadog-agent package.
• Start the Datadog Agent service.

gpg: key E6266D4AC0962C7D: "Datadog, Inc. APT key (2023-04-20) (APT key) <package+aptkey@datadoghq.com>" not changed
Get:2 https://apt.datadoghq.com stable Release [26.0 kB]
Get:5 https://apt.datadoghq.com stable/7 amd64 Packages [92.1 kB]
Fetched 252 MB in 3s (95.5 MB/s)
Selecting previously unselected package datadog-agent.
Preparing to unpack .../datadog-agent_1%3a7.62.3-1_amd64.deb ...
Unpacking datadog-agent (1:7.62.3-1) ...
Setting up datadog-agent (1:7.62.3-1) ...
datadog-agent start/running, process 1234

​

2. Enable the NGINX integration (stub_status)

1. Verify your NGINX has the stub_status module:

nginx -V 2>&1 | grep -o http_stub_status_module || true

2. Configure NGINX to expose stub_status on localhost. A common pattern is to listen on 127.0.0.1:81 and restrict access to the loopback interface. Add a server block (for example in /etc/nginx/sites-available/example-https or another site file):

server {
    listen 127.0.0.1:81;
    server_name localhost;

    access_log off;
    allow 127.0.0.1;
    deny all;

    location /nginx_status {
        # Open source NGINX stub status
        stub_status;

        # For older open source NGINX (<1.7.5) the syntax may be:
        # stub_status on;

        # NGINX Plus users may use:
        # status;

        # ensure version info is available
        server_tokens on;
    }
}

• Listens on 127.0.0.1:81 so only the local host can connect.
• Turns off access logging for the endpoint to prevent log growth from frequent scraping.
• Allows only 127.0.0.1 and denies all other addresses.

3. Test and reload NGINX:

sudo nginx -t
sudo nginx -s reload

4. Verify the endpoint from the host itself (run on the server):

curl http://127.0.0.1:81/nginx_status

Active connections: 1
server accepts handled requests
9 9 13
Reading: 0 Writing: 1 Waiting: 0

• If you fetch the endpoint from a remote machine you should either receive a 403 Forbidden (if bound to 0.0.0.0 but access denied) or a connection error like connection refused (if bound to loopback only). Both outcomes are normal depending on your binding configuration.
• In Datadog’s NGINX integration settings, use localhost and the port you configured (for example, 81) if it requests a host/port.

location /nginx_status {
    stub_status;
    access_log off;
    allow 127.0.0.1;
    deny all;
}

​

3. Datadog dashboards and host view

• Bookmark dashboards you use often.
• Create monitors/alerts for CPU, memory, disk I/O, or NGINX-specific metrics (active connections, request rates).
• Run load tests (for example ab, wrk) to generate traffic and observe behavior.

​

Quick reference — useful commands & checks

​

Troubleshooting checklist

• Ensure the Datadog Agent is running: sudo systemctl status datadog-agent.
• Confirm the nginx_status endpoint is reachable from the host: curl http://127.0.0.1:81/nginx_status.
• If Datadog reports no NGINX metrics:
  • Verify the NGINX integration is enabled in Datadog and the host/port configured in the integration matches your setup (e.g., localhost:81).
  • Check the agent logs for errors: sudo journalctl -u datadog-agent -f (or review /var/log/datadog/).
• Keep the stub_status endpoint bound to localhost or explicitly deny external access to avoid exposing internal server state.

​

Links and references

• Datadog Agent installation documentation
• Datadog NGINX integration docs
• NGINX stub_status module documentation