Stop Flying Blind: Real-Time Infrastructure Monitoring with Datadog on Linux

It is 3:00 AM. Your phone buzzes. The load average on your primary database node just hit 25.0, and your customers in Bergen are seeing 504 Gateway Time-out errors. If you are still relying on a static Nagios check that pings the server once every five minutes, you are already too late. You aren't managing infrastructure; you are reacting to a disaster that has already happened.

In the world of Systems Administration, visibility is the difference between a minor hiccup and a resume-generating event. While legacy tools tell you if a server is up, modern platforms like Datadog tell you what the server is doing. Today, we are going to walk through a production-grade setup of Datadog on a Linux VPS, specifically focusing on CentOS 7 and Ubuntu 14.04 LTS environments, to monitor a standard LEMP stack.

The Problem with "Up or Down" Monitoring

Traditional monitoring scripts usually look like this:

#!/bin/bash
# The old way: Is it alive?
ping -c 1 192.168.1.50 > /dev/null
if [ $? -eq 0 ]; then
    echo "OK"
else
    echo "CRITICAL"
fi

This is useless when your disk I/O is saturated or your MySQL InnoDB buffer pool is thrashing. You need time-series data. You need to know that CPU usage spiked to 90% exactly when the backup script triggered, or that network latency to the NIX (Norwegian Internet Exchange) increased by 50ms.

This is where CoolVDS shines. We provide raw KVM virtualization with dedicated NVMe storage. We don't oversell resources, so when you see a spike in your graphs, you know it is your application, not a noisy neighbor stealing your cycles. But high-performance infrastructure requires high-performance instrumentation.

Step 1: Installing the Datadog Agent (v5)

The Datadog Agent is a python-based daemon that collects metrics and events. Unlike simple SNMP, it runs locally and pushes data out (no firewall holes needed for incoming connections).

On your CoolVDS instance, run the following to install the agent. We typically use the one-line install command which detects the OS and adds the necessary repositories:

# Install Datadog Agent on CentOS 7 / Ubuntu 14.04
DD_API_KEY=YOUR_API_KEY_HERE bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"

Once installed, the configuration lives in /etc/dd-agent/datadog.conf. A critical step that many skip is tagging. Tags allow you to aggregate data. If you have three web servers, you don't want to check them individually; you want to check the average load of role:webserver.

Configuring Host Tags

Open the configuration file:

vi /etc/dd-agent/datadog.conf

Scroll down to the tags section. If you are hosting with us in Oslo, tag it appropriately so you can differentiate it from your testing servers in Frankfurt.

# /etc/dd-agent/datadog.conf

# Set the host's tags (optional)
tags: env:production, role:webserver, region:norway, provider:coolvds

Restart the agent to apply changes:

sudo service datadog-agent restart

Step 2: Monitoring Nginx Performance

CPU and memory metrics are standard, but they don't tell you about business performance. You need to track requests per second and connections. For Nginx, this requires the ngx_http_stub_status_module.

First, verify your Nginx has the module compiled (standard on most repos):

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

Next, configure a local status page in your nginx.conf or a specific vhost. Keep this restricted to localhost for security.

server {
    listen 127.0.0.1:80;
    server_name localhost;

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

Reload Nginx (service nginx reload). Now, tell Datadog to read this endpoint. Create the configuration file for the integration:

cd /etc/dd-agent/conf.d/
cp nginx.yaml.example nginx.yaml
vi nginx.yaml

Modify the YAML to point to your local status page:

init_config:

instances:
  - nginx_status_url: http://127.0.0.1/nginx_status
    tags:
      - instance:coolvds-web-01

Pro Tip: YAML is extremely sensitive to indentation. Do not use tabs. Use spaces. If the agent fails to start, check /var/log/datadog/collector.log for parsing errors.

Step 3: MySQL Integration and the Importance of I/O

Database monitoring is where latency issues usually hide. On a VPS, disk I/O is the bottleneck. CoolVDS utilizes local NVMe storage which significantly reduces iowait compared to standard SATA SSDs found in budget hosting, but you must verify this via metrics.

Create a dedicated monitoring user in MySQL so you aren't putting root credentials in a config file:

CREATE USER 'datadog'@'localhost' IDENTIFIED BY 'UniquePassword123';
GRANT REPLICATION CLIENT ON *.* TO 'datadog'@'localhost';
GRANT PROCESS ON *.* TO 'datadog'@'localhost';
GRANT SELECT ON performance_schema.* TO 'datadog'@'localhost';

Configure the mysql.yaml in the Datadog conf.d directory:

init_config:

instances:
  - server: localhost
    user: datadog
    pass: UniquePassword123
    tags:
      - db_type:master
    options:
      replication: 0
      galera_cluster: 0

This will start pulling in metrics like mysql.performance.slow_queries, innodb.buffer_pool_free, and com_select.

The "Safe Harbor" Reality Check

We cannot discuss infrastructure in 2016 without addressing the legal elephant in the room. In October 2015, the ECJ invalidated the Safe Harbor agreement. If you are a Norwegian company storing customer data on US-controlled servers (even if they claim the datacenter is in Ireland), you are in a legal grey area right now.

This is why physical data residency matters. When you deploy on CoolVDS, your data sits on servers physically located in Oslo. We adhere to Norwegian data privacy laws and Datatilsynet guidelines. Monitoring your infrastructure with Datadog allows you to maintain operational excellence, but hosting it locally ensures you aren't scrambling when the lawyers come knocking about cross-border data transfers.

War Story: The Magento Memory Leak

Last month, we helped a client migrating from a shared hosting environment to a CoolVDS NVMe instance. They were running Magento 1.9. Their shop would randomly lock up every 48 hours. The previous host blamed "traffic spikes."

We installed Datadog and set up a custom check for PHP-FPM processes. We immediately saw a sawtooth pattern in memory usage—a slow leak in a third-party extension. It wasn't traffic; it was bad code consuming RAM until the OOM (Out of Memory) killer shot the database process. Without historical metrics, we would have been guessing. With Datadog, we fixed it in an hour.

Conclusion

You cannot optimize what you do not measure. Whether you are running a high-traffic media site or a critical corporate backend, visibility is mandatory. By combining the raw, low-latency power of CoolVDS with the granular insights of Datadog, you build a stack that is not just fast, but resilient.

Don't wait for the next outage to realize you are blind. Deploy a high-performance VPS Norway instance on CoolVDS today, configure your agent, and finally see what your servers are really doing.