Cloudprober on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Cloudprober on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Cloudprober is an open source, active monitoring tool. Instead of waiting for an outage to be reported, it continuously probes your endpoints on a schedule over HTTP, HTTPS, PING, DNS, TCP, gRPC and external commands, and turns the results into availability and latency time series you can alert on. Its entire behaviour is composed from a single readable config file, and it exports the standard success, total and latency metrics for every probe in Prometheus format, alongside a live status page.

The image installs Cloudprober 0.14.3 from the official upstream release binary (a single self contained Go binary), run under systemd as an unprivileged cloudprober user. In this image Cloudprober's built in web server (the status page and the /metrics endpoint) is bound to the loopback interface only on port 9313, and nginx is the sole network facing surface. nginx terminates TLS on port 443 and fronts the whole monitoring surface with HTTP basic authentication, so your monitoring data is never exposed unauthenticated.

Secure by default, no shared credentials. Cloudprober's own HTTP surface has no authentication, which means an unprotected Cloudprober exposes its status page and metrics to the whole network. This image never exposes it that way. Nothing secret is baked into the image. On the first boot of every instance, the image generates a unique HTTP basic authentication username and password and a unique self signed TLS certificate, and writes the credentials to a root only file. The image ships a demonstration probe that monitors the instance itself, so metrics flow the moment it boots, ready for you to point at your own targets.

What is included:

• Cloudprober 0.14.3 from the official upstream release binary, run under systemd (cloudprober.service) as an unprivileged cloudprober user, with the status page and /metrics bound to 127.0.0.1:9313

• nginx (nginx.service) terminating TLS on port 443 as the only network facing service, fronting the status page and metrics with HTTP basic auth, plus an unauthenticated /healthz for load balancer probes

• A per instance HTTP basic authentication credential and TLS certificate, generated fresh on first boot, with the per instance values written to /root/cloudprober-credentials.txt

• A Prometheus metrics endpoint (/metrics) and a live status page (/ and /status), ready to scrape into Prometheus and visualise in Grafana

• A shipped demonstration probe, cloudimg_selfcheck, and the whole configuration in one readable file, /etc/cloudprober.cfg, that you version control and reload with a single command

Prerequisites

• Active Azure subscription, SSH public key, VNet + subnet in target region

• Subscription to the Cloudprober listing on Azure Marketplace

• Network Security Group rules allowing TCP 22 (admin) and TCP 443 (HTTPS, for the status page and metrics) from the operators and monitoring systems that will reach the server

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) is ample for monitoring a few dozen targets. Increase the size for very large numbers of probes or very short probe intervals.

Step 1: Deploy from the Azure Portal

Search Cloudprober in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 443 from the operators and monitoring systems that will reach the status page and metrics, and TCP 22 for administration. Keep 443 restricted to the networks you serve; a monitoring appliance rarely needs to be reachable from the whole internet.

Step 2: Deploy from the Azure CLI

RG="monitoring-prod"; LOCATION="eastus"; VM_NAME="cloudprober1"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/cloudprober-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 443 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

Step 3: First boot and per instance credentials

On first boot the image resolves this VM's IP, generates a per instance HTTP basic authentication username and password and a per instance TLS certificate, and writes everything to /root/cloudprober-credentials.txt. This completes within seconds. SSH in as azureuser and read the credentials file:

sudo cat /root/cloudprober-credentials.txt

The file is 0600 root:root and records the console user and password, the HTTPS URL, and the paths for the status page, metrics and health endpoints. These values are unique to this instance.

Step 4: Confirm the services are running

cloudprober.service and nginx.service are both active, cloudprober --version reports 0.14.3, and ss confirms that nginx owns port 443 while the Cloudprober web surface is bound to loopback only on port 9313.

systemctl is-active cloudprober.service nginx.service
/opt/cloudprober/cloudprober --version
sudo ss -tlnp | grep -E ':443 |:9313 '

Step 5: The monitoring surface is never open

The status page and the metrics endpoint are reachable only through nginx on port 443, and only with the per instance HTTP basic authentication. An unauthenticated request returns 401; a request with the per instance credentials returns 200. Only the /healthz load balancer probe is served without credentials. The block below reads the credentials from the instance credentials file, so it works unchanged on any instance.

CLOUDPROBER_USER=$(sudo grep -E '^CLOUDPROBER_USER=' /root/cloudprober-credentials.txt | cut -d= -f2-)
CLOUDPROBER_PASSWORD=$(sudo grep -E '^CLOUDPROBER_PASSWORD=' /root/cloudprober-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'healthz  (no auth)   -> HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'metrics  (no auth)   -> HTTP %{http_code}\n' https://127.0.0.1/metrics
curl -sk -u "$CLOUDPROBER_USER:$CLOUDPROBER_PASSWORD" -o /dev/null -w 'status   (with auth) -> HTTP %{http_code}\n' https://127.0.0.1/status

The -k flag tells curl to accept the self signed per instance certificate. The unauthenticated /metrics request returns 401, and the status page returns 200 only when the per instance credentials are supplied.

Step 6: View the probe metrics

Cloudprober exports the standard success, total, latency and resp_code series for every probe in Prometheus format on /metrics. The shipped demonstration probe cloudimg_selfcheck monitors this instance's own status endpoint, so metrics are already flowing. Read them through nginx with the per instance credentials.

CLOUDPROBER_USER=$(sudo grep -E '^CLOUDPROBER_USER=' /root/cloudprober-credentials.txt | cut -d= -f2-)
CLOUDPROBER_PASSWORD=$(sudo grep -E '^CLOUDPROBER_PASSWORD=' /root/cloudprober-credentials.txt | cut -d= -f2-)
curl -sk -u "$CLOUDPROBER_USER:$CLOUDPROBER_PASSWORD" https://127.0.0.1/metrics | grep -E '^(total|success|latency|resp_code)\{'

Each series is labelled by probe type (ptype), probe name (probe) and destination (dst). For the demo probe you will see success equal to total and resp_code with code="200", confirming the probe is running and every request has succeeded. Point your Prometheus scraper at this endpoint to collect the metrics.

Step 7: The live status page

Cloudprober serves a live status page at / and /status that lists every configured probe with its recent success and latency. It is served through nginx over HTTPS with the same per instance credentials. Open https://<vm-ip>/status in your browser (accepting the self signed certificate), or confirm from the shell that it is served:

CLOUDPROBER_USER=$(sudo grep -E '^CLOUDPROBER_USER=' /root/cloudprober-credentials.txt | cut -d= -f2-)
CLOUDPROBER_PASSWORD=$(sudo grep -E '^CLOUDPROBER_PASSWORD=' /root/cloudprober-credentials.txt | cut -d= -f2-)
curl -sk -u "$CLOUDPROBER_USER:$CLOUDPROBER_PASSWORD" https://127.0.0.1/status | grep -iE 'cloudprober|probe|selfcheck' | head

Step 8: Add probes for your own targets

Everything Cloudprober does is defined in /etc/cloudprober.cfg. Each probe block picks a type, a set of targets and an interval. The example below adds an HTTP probe that checks a website you own; the same pattern works for PING, DNS, TCP and GRPC probes. Edit the config and reload.

# append a probe to /etc/cloudprober.cfg, for example an HTTP check of your own site:
#   probe {
#     name: "my_website"
#     type: HTTP
#     targets { host_names: "<your-domain>" }
#     http_probe { protocol: HTTPS }
#     interval_msec: 15000
#     timeout_msec: 5000
#   }
# then apply the change (Cloudprober re-reads its config on restart):
sudo systemctl restart cloudprober

Cloudprober re-reads its config on reload. The new probe appears on the status page and its success, total and latency series appear on /metrics within one interval. See the Cloudprober documentation for the full set of probe types and options.

Step 9: Scrape the metrics into Prometheus

To collect the metrics centrally, point a Prometheus server at this instance's authenticated metrics endpoint. Replace <vm-ip> with this instance's address and use the per instance credentials from /root/cloudprober-credentials.txt.

# prometheus.yml scrape config
scrape_configs:
  - job_name: cloudprober
    scheme: https
    tls_config:
      insecure_skip_verify: true   # or provide the per instance CA certificate
    basic_auth:
      username: <user>
      password: <password>
    static_configs:
      - targets: ['<vm-ip>']

For production, replace the self signed certificate with a CA signed certificate and a DNS name so Prometheus trusts the transport without insecure_skip_verify.

Step 10: Security recommendations

• Restrict the NSG. Allow TCP 443 only from the operators and monitoring systems that reach the status page and metrics, and TCP 22 only from your administration network. A monitoring appliance rarely needs to be public.

• Protect the console password. It lives in /root/cloudprober-credentials.txt (0600 root:root). The status page and metrics are reachable only through nginx and only with this password; rotate it by updating /etc/nginx/cloudprober.htpasswd with htpasswd and reloading nginx.

• Keep the web surface on loopback. Cloudprober's built in server is bound to 127.0.0.1:9313; keep it that way so nginx and its basic auth stay the only path to the monitoring data.

• Use a real certificate for production. The per instance certificate is self signed. Put a CA signed certificate and a DNS name in front for production so clients and scrapers trust the transport without extra configuration.

• Keep the OS patched. Unattended security upgrades remain enabled on the running VM.

Step 11: Support and Licensing

Cloudprober is open source software distributed under the Apache License 2.0. This cloudimg image bundles the unmodified official Cloudprober release binary. cloudimg provides the packaging, the systemd hardening, the nginx TLS front, the loopback only web surface with per instance basic auth, the per instance credential automation, the paired deploy guide, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg is not affiliated with or endorsed by the Cloudprober project. Cloudprober is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find Cloudprober on Ubuntu 24.04 LTS on the Azure Marketplace, published by cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.