Cloudprober

Search the Azure Marketplace for Cloudprober, select the SecureAnyCloud publisher, and click Create.

Configure the NSG to allow TCP 443 from the operators and monitoring systems that will reach the status page and metrics, and TCP 22 for administration. Restrict port 443 to the networks you serve, because a monitoring appliance rarely needs to be reachable from the whole internet.

RG="monitoring-prod"; LOCATION="eastus"; VM_NAME="cloudprober1" IMAGE_URN="sac1647283583153:cloudprober-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:cloudprober-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --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

On first boot the image resolves the VM's IP address, 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. It 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.

Confirm that cloudprober.service and nginx.service are both active and that cloudprober --version reports 0.14.3. Then use ss to confirm that nginx owns port 443 and that 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 '

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, and a request with the per-instance credentials returns 200. Only the /healthz load balancer probe is served without credentials.

The following block 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 you supply the per-instance credentials.

Cloudprober exports the standard success, total, latency and resp_code series for every probe in Prometheus format on /metrics. The demonstration probe sac_selfcheck monitors this instance's own status endpoint, so metrics are already flowing.

Read the metrics 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 demonstration probe, success equals total and resp_code carries code="200", which confirms that the probe is running and every request has succeeded.

Point your Prometheus scraper at this endpoint to collect the metrics.

Cloudprober serves a live status page at / and /status that lists every configured probe with its recent success and latency. nginx serves it over HTTPS with the same per-instance credentials.

Open https://<vm-ip>/status in your browser and accept the self-signed certificate. Alternatively, confirm from the shell that the page 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

Cloudprober is configured entirely in /etc/cloudprober.cfg. Each probe block sets a type, a set of targets and an interval.

The following example adds an HTTP probe that checks a website you own. The same pattern works for PING, DNS, TCP and GRPC probes. Edit the config, then 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.

To collect the metrics centrally, point a Prometheus server at this instance's authenticated metrics endpoint. Replace <vm-ip> with the 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. Prometheus can then trust the connection without insecure_skip_verify.

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. To rotate it, update /etc/nginx/cloudprober.htpasswd with htpasswd and reload nginx.

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

Use a real certificate in production. The per-instance certificate is self-signed. Put a CA-signed certificate and a DNS name in front of the instance so that clients and scrapers trust the connection without extra configuration.

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

Cloudprober is open-source software distributed under the Apache License 2.0. This SecureAnyCloud image bundles the unmodified official Cloudprober release binary.

SecureAnyCloud 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 deployment guide, and 24/7 support with a guaranteed 24-hour response SLA.

SecureAnyCloud 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 in the Azure Marketplace, published by SecureAnyCloud. Deploy from the Azure Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions or licensing enquiries.

Deploy on Azure

Launch Cloudprober 0.14.3 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

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Cloudprober. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of m5.large or larger. Cloudprober is very light, but m5.large is the tested recommendation. Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet, then create or select a security group that allows inbound port 22 from your management network and inbound port 443 from the networks you will reach the status page from. Keep the root volume at the default size or larger.

Select Launch instance. First-boot initialisation takes under a minute after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud Cloudprober Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID and <security-group-id> with a security group that opens ports 22 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options "HttpTokens=required,HttpEndpoint=enabled" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cloudprober}]'

On first boot, the image resolves the instance's public address using the EC2 Instance Metadata Service (IMDSv2), so it works with HttpTokens=required enabled. That address becomes the common name and a subject alternative name on the per-instance TLS certificate.

Connect as the ubuntu user, as listed in Connecting to your instance above.

ssh ubuntu@<public-ip>

When you log in, the message of the day prints the status page URL and the key operational commands.

First boot generates a unique basic authentication username and password for this instance and writes them, with the resolved status page URL, to a root-only file. Nothing secret ships inside the image, so this file is the only place the credential exists.

sudo cat /root/cloudprober-credentials.txt

Real output from a running instance, with the secrets redacted:

# Cloudprober on Ubuntu 24.04 LTS (sac AWS Marketplace image) - this VM.
# Generated per-VM on first boot. Keep this file secret (0600 root:root).
# --- Cloudprober console + metrics (HTTPS, per-VM HTTP basic auth via nginx) --- CLOUDPROBER_USER=sac CLOUDPROBER_PASSWORD=<CLOUDPROBER_PASSWORD> CLOUDPROBER_URL=https://<public-ip>/

Cloudprober and nginx start automatically after the first-boot service has generated the per-instance credential and certificate. Confirm that both are active:

systemctl is-active cloudprober nginx

Both report active.

This is the most important security property of the image. Cloudprober's own HTTP server has no authentication, so it must never be reachable from the network directly. Confirm that it is bound to 127.0.0.1 and that only nginx listens on the public interface:

ss -ltn | grep -E '9313|:443'

Real output from a running instance:

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 4096 127.0.0.1:9313 0.0.0.0:* LISTEN 0 511 [::]:443 [::]:*

Port 9313 is bound to 127.0.0.1 only. Port 443 is nginx.

The status page and the metrics endpoint must reject unauthenticated requests. The following check succeeds when the request is refused:

if curl -sk --fail -o /dev/null -m 10 https://127.0.0.1/metrics; then echo "UNEXPECTED: metrics were served without a credential" exit 1 else echo "refused (exit $?) - correct, the monitoring surface requires the per instance credential" fi

The unauthenticated health endpoint, which exists for load balancers, is served without credentials:

curl -sk -o /dev/null -w 'GET /healthz -> HTTP %{http_code}\n' https://127.0.0.1/healthz

Now authenticate with the per-instance credential and confirm that the status page answers. This reads the credential straight from the root-only file, so the password is never typed or echoed:

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

Browse to https://<public-ip>/ and sign in with the username and password from Step 4. The certificate is self-signed and generated per instance, so your browser warns you once. Accept it, or replace the certificate with your own as described later in this guide.

The status page shows every configured probe, its success ratio over several time windows, and a chart of that ratio over time. Out of the box it shows the bundled sac_selfcheck demonstration probe, which monitors this instance's own status endpoint. This exercises the full probe-to-surfacer-to-metrics pipeline with no external dependency.

The /config view renders the configuration that Cloudprober is running, including every probe with its type, interval, timeout and targets, and the configured surfacers.

You can also read the same configuration on the instance:

grep -vE '^\s*#' /etc/cloudprober.cfg | grep -vE '^\s*$'

Real output from a running instance:

host: "127.0.0.1" port: 9313 surfacer { type: PROMETHEUS } probe { name: "sac_selfcheck" type: HTTP targets { host_names: "127.0.0.1" } http_probe { port: 9313 relative_url: "/status" } interval_msec: 5000 timeout_msec: 3000 }

Every probe exports the standard total, success, latency, timeouts and failure series in Prometheus format. Confirm that the demonstration probe is reporting success:

U=$(sudo grep -E '^CLOUDPROBER_USER=' /root/cloudprober-credentials.txt | cut -d= -f2-)
P=$(sudo grep -E '^CLOUDPROBER_PASSWORD=' /root/cloudprober-credentials.txt | cut -d= -f2-)
curl -sk -u "$U:$P" https://127.0.0.1/metrics | grep -E 'probe="sac_selfcheck"'

Real output from a running instance:

total{ptype="http",probe="sac_selfcheck",dst="127.0.0.1"} 18 success{ptype="http",probe="sac_selfcheck",dst="127.0.0.1"} 18 latency{ptype="http",probe="sac_selfcheck",dst="127.0.0.1"} 13142.685 timeouts{ptype="http",probe="sac_selfcheck",dst="127.0.0.1"} 0 resp_code{ptype="http",probe="sac_selfcheck",dst="127.0.0.1",code="200"} 18 failure{ptype="http",probe="sac_selfcheck",dst="127.0.0.1"} 0

Here success equals total and failure is zero, so every probe attempt has succeeded.

To scrape this instance from an external Prometheus server, point a job at port 443 with scheme: https, tls_config.insecure_skip_verify: true (or trust your own certificate) and a basic_auth block carrying this instance's username and password.

Cloudprober is configured through a single file. Add a probe block for each target, then apply the change. Cloudprober supports HTTP, PING, DNS, TCP, GRPC and EXTERNAL probe types.

For example, to monitor two public web endpoints every thirty seconds, add:

probe { name: "my_website" type: HTTP targets { host_names: "www.example.com,api.example.com" } http_probe { protocol: HTTPS relative_url: "/" } interval_msec: 30000 timeout_msec: 5000 }

Edit the file and apply the change. cloudprober.service defines no reload action, so systemctl reload does not apply here. Use restart instead, which is effectively instant for a single static binary.

sudo nano /etc/cloudprober.cfg
sudo systemctl restart cloudprober

Confirm that the service came back up cleanly after the restart:

sudo systemctl restart cloudprober && sleep 3 && systemctl is-active cloudprober

Each probe you add appears on the status page. It also exports its own success, total and latency series to /metrics under its probe label, ready to alert on.

The /logs view shows Cloudprober's structured log, filterable by source and level. It is the quickest way to confirm that a newly added probe is resolving its targets.

You can read the same log from systemd:

sudo journalctl -u cloudprober --no-pager | tail -5