Netdata on Ubuntu 24.04 on Azure User Guide

Overview

Netdata is an open source, real-time infrastructure monitoring agent. It auto-discovers and collects thousands of per-second metrics from the host - CPU, memory, disks, filesystems, network interfaces, systemd services, running applications and containers - and renders them in a rich, interactive dashboard that updates every second, with health alerting built in. The cloudimg image installs the pinned Netdata stable 2.10.3 as a native package running under systemd, then locks it down for a marketplace appliance: the Netdata agent is bound to loopback 127.0.0.1:19999 so its normally-open dashboard is never exposed directly, and an nginx reverse proxy on port 80 adds a per-VM HTTP Basic Auth gate in front of it. Netdata Cloud phone-home and anonymous statistics are disabled by default, so this VM monitors itself privately out of the box. The metrics database (the Netdata dbengine), the registry and the per-VM machine identity live on a dedicated Azure data disk mounted at /var/lib/netdata, and a unique dashboard password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Netdata stable 2.10.3 installed as a native package and running as the netdata systemd service
• A live, per-second monitoring dashboard on :80, fronted by nginx with the agent bound to loopback only
• Per-VM HTTP Basic Auth (user admin) protecting the dashboard, with a unique password generated on first boot
• The Netdata agent is bound to 127.0.0.1:19999 - the dashboard is never exposed to the network directly
• Netdata Cloud phone-home and anonymous statistics disabled by default for a private, self-hosted setup
• A dedicated Azure data disk at /var/lib/netdata holding the dbengine metrics database and the per-VM machine identity
• netdata.service + nginx.service as systemd units, enabled and active
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point; Netdata is engineered to be light on resources. NSG inbound: allow 22/tcp from your management network, 80/tcp for the dashboard, and 443/tcp if you add TLS. Netdata serves plain HTTP on port 80; for production use, terminate TLS in front of it with your own domain and restrict access to trusted IP ranges (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Netdata by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name netdata \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name netdata --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active netdata.service nginx.service

Both report active. The Netdata agent collects metrics and serves its dashboard + API on the loopback connector 127.0.0.1:19999; nginx fronts it on port 80 and adds the per-VM HTTP Basic Auth gate. The agent's metrics database lives on the dedicated Azure data disk mounted at /var/lib/netdata.

Step 5 - Retrieve your dashboard password

nginx protects the Netdata dashboard with HTTP Basic Auth. The username is admin and a unique password is generated on the first boot of your VM and written to a root-only file:

sudo cat /root/netdata-credentials.txt

This file contains NETDATA_USERNAME, NETDATA_PASSWORD and the NETDATA_URL to open in a browser. The password is stored on disk only as a bcrypt hash in /etc/nginx/.netdata.htpasswd, so no plaintext password ships in the image. Store the password somewhere safe.

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -s http://localhost/healthz

It returns ok. This endpoint never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 7 - Confirm authentication and the metrics API

Because a password is set on first boot, an unauthenticated request to the dashboard returns HTTP 401, so nobody reaches your metrics without the password. The following reads the per-VM password from the credentials file and proves the round-trip - unauthenticated is rejected, a wrong password is rejected, the correct password authenticates, and an authenticated call to the Netdata info API returns JSON:

PW=$(sudo grep '^NETDATA_PASSWORD=' /root/netdata-credentials.txt | cut -d= -f2-)
echo "unauth  : $(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/)"
echo "wrongpw : $(curl -s -o /dev/null -w '%{http_code}' -u admin:wrong-pw http://127.0.0.1/)"
echo "authed  : $(curl -s -o /dev/null -w '%{http_code}' -u admin:$PW http://127.0.0.1/)"
echo "version : $(curl -s -u admin:$PW http://127.0.0.1/api/v1/info | python3 -c 'import sys,json;print(json.load(sys.stdin)["version"])')"

It prints unauth : 401, wrongpw : 401, authed : 200, then the Netdata version. The /api/v1/info endpoint, like the whole dashboard, is only reachable with the per-VM password because the Netdata agent itself is bound to loopback and nginx is the only way in.

Step 8 - Sign in to the dashboard

Browse to http://<vm-public-ip>/. Your browser prompts for a username and password: enter admin and the password from Step 5. Netdata opens on the Overview - a live, per-second view of the whole system. The top nodes bar and the menu on the right let you jump between sections (System Overview, CPU, Memory, Disks, Networking, Systemd Services, Applications and more), and every chart streams new data each second.

Step 9 - Drill into the CPU and pressure charts

Use the right-hand menu to open the Compute section. Netdata charts CPU utilisation per core and in aggregate, alongside the Linux pressure-stall-information (PSI) metrics that show, second by second, how much CPU and memory pressure the system is under. Hover any chart to see exact values at a point in time; drag to zoom into a window.

Step 10 - Read the storage and disk-I/O charts

Open the Storage section from the right-hand menu. Netdata shows total disk I/O throughput, per-disk read/write rates, IOPS, latency and space utilisation, plus memory paged to and from disk - so you can see exactly what your disks are doing. Netdata retains this history in its on-disk metrics database, so you can scroll back in time using the timeframe picker at the top of the dashboard.

Step 11 - View alerts and collectors

Netdata ships with hundreds of pre-configured health alarms (running out of disk space, high CPU pressure, network errors and more). The Alerts tab shows the current alarm status, and the agent auto-discovered dozens of collectors on this host. You can confirm the collector and alarm counts from the info API:

PW=$(sudo grep '^NETDATA_PASSWORD=' /root/netdata-credentials.txt | cut -d= -f2-)
curl -s -u admin:$PW http://127.0.0.1/api/v1/info | python3 -c 'import sys,json;d=json.load(sys.stdin);print("charts     :",d["charts-count"]);print("collectors :",len(d.get("collectors",[])));print("cloud      : claimed=%s" % d.get("agent-claimed"))'

Out of the box the agent is monitoring this host only, with Netdata Cloud disabled (claimed=False), so nothing leaves the VM.

Step 12 - Confirm the metrics database lives on the dedicated disk

Netdata's metrics database (the dbengine), its registry and the per-VM machine identity are kept under /var/lib/netdata on the dedicated Azure data disk, so your metrics history survives OS changes and the disk can be resized independently:

findmnt /var/lib/netdata

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM. The dbengine files live under /var/lib/netdata/cache/dbengine.

Maintenance

• Password: the dashboard password is set on first boot and stored as a bcrypt entry in /etc/nginx/.netdata.htpasswd. To change it, run sudo htpasswd -B /etc/nginx/.netdata.htpasswd admin and then sudo systemctl reload nginx.
• Restrict access: Netdata serves plain HTTP on port 80. For production, restrict the dashboard to trusted IP ranges in your Network Security Group, and front it with TLS (for example certbot with your own domain) terminating on :443.
• Loopback binding: the Netdata agent is bound to 127.0.0.1:19999 in /etc/netdata/netdata.conf ([web] bind to), so nginx is the only path to the dashboard. Keep it that way - do not change the bind address to a public interface.
• Metrics retention: the dbengine database under /var/lib/netdata/cache/dbengine grows to fill the data disk and then rolls the oldest data. To keep more history, resize the data disk or tune the [db] retention settings in netdata.conf, then sudo systemctl restart netdata.
• Monitor more nodes: this image monitors its own host. To monitor additional servers, install the Netdata agent on them and stream their metrics to this node, or connect them through Netdata Cloud (optional, and off by default here).
• Netdata Cloud: cloud connectivity is disabled by default via /var/lib/netdata/cloud.d/cloud.conf ([global] enabled = no). It is entirely optional; leave it off for a fully self-hosted, private setup.
• Storage: all Netdata state lives under /var/lib/netdata on the data disk; back up that volume to protect your metrics history.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.