Netdata

Prerequisites

Before you deploy this image, make sure you have:

• An active Azure subscription
• An SSH key pair
• A VNet and subnet in the target region
• A VM size of Standard_B2s (2 vCPU / 4 GiB RAM) or larger. This is a comfortable starting point, and Netdata is engineered to be light on resources.
• NSG inbound rules that 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, and search the Marketplace for Netdata by SecureAnyCloud. Select Create.
• On the Basics tab, 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.
• Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once per subscription, create the VM, then open port 80.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:netdata-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name netdata \
  --image sac1647283583153:netdata-ubuntu-24-04:default:latest \
  --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

Connect to the VM over SSH.

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that both services are active.

systemctl is-active netdata.service nginx.service

Both report active. The Netdata agent collects metrics and serves its dashboard and 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. A unique password is created on the first boot of your VM and written to a root-only file. Read the file.

sudo cat /root/netdata-credentials.txt

The 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. Request it.

curl -s http://localhost/healthz

It returns ok. This endpoint never requires authentication, so you can use it 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 commands read the per-VM password from the credentials file and prove the round trip:

• An unauthenticated request is rejected.
• A wrong password is rejected.
• The correct password authenticates.
• 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 reachable only with the per-VM password. 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). 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 it are the Linux pressure-stall-information (PSI) metrics, which show, second by second, how much CPU and memory pressure the system is under.

Hover over 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 keeps this history in its on-disk metrics database. Use the timeframe picker at the top of the dashboard to scroll back in time.

Step 11 - View alerts and collectors

Netdata ships with hundreds of pre-configured health alarms, covering conditions such as running out of disk space, high CPU pressure and network errors. The Alerts tab shows the current alarm status. The agent also auto-discovers dozens of collectors on this host.

To confirm the collector and alarm counts, query 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 monitors 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. Your metrics history survives OS changes, and you can resize the disk independently. To check the mount, run:

findmnt /var/lib/netdata

A separate Azure data disk, captured into the image and re-provisioned on every VM, backs the mount. 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, 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. 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, and 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 off the oldest data. To keep more history, resize the data disk or tune the [db] retention settings in netdata.conf, then run 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. Alternatively, connect them through Netdata Cloud, which is 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 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 stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact us at sales@secureanycloud.com.

Deploy on Azure

Launch Netdata Real-Time Monitoring on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com