Cloudprober Black Box Monitoring

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Why This AMI Instead of Self-Managed Cloudprober

If you install Cloudprober from source, you get a powerful prober with no authentication on its HTTP surface, no TLS termination, and manual systemd configuration ahead of you. If you use a SaaS uptime monitor, you pay per-probe pricing and lose control over your vantage point. This image eliminates both trade-offs: you get a fully hardened, production-ready Cloudprober instance that exports Prometheus metrics within minutes of launch, with unique per-instance credentials and TLS termination handled for you.

## Who This Is For

SRE teams, platform engineers, and DevOps leads running microservices on AWS who need active black box monitoring from a controlled vantage point. If your stack already includes Prometheus and Grafana, this AMI slots directly into your existing alerting pipeline.

## How It Works

Cloudprober continuously probes your endpoints on a schedule over HTTP, HTTPS, PING, DNS, TCP, gRPC, and external commands, then turns results into availability, success ratio, and latency time series. You describe targets and probes in a single textproto configuration file at /etc/cloudprober.cfg, and Cloudprober exports standard success, total, and latency metrics in Prometheus format.

## Example Deployment Scenario

An SRE team monitoring 50 microservice health endpoints across multiple availability zones configures one probe block per service in /etc/cloudprober.cfg, sets a 5-second interval, and scrapes the metrics endpoint into their existing Prometheus instance. When a service becomes unreachable, the success ratio drops immediately, so their own alerting pipeline can page within seconds of failure, without waiting for a customer report.

## Secure by Default - No Shared Credentials

This image never exposes Cloudprober's HTTP surface to the network. Cloudprober binds to loopback only, and on first boot the instance generates its own unique HTTP basic authentication password and its own self-signed TLS certificate, then writes them to a root-only credentials file. No secret is baked into the image, so no two instances ever share a credential. An unauthenticated request to the status page or metrics is rejected, while a separate unauthenticated health endpoint is available for load balancer probes.

## Ready to Use on First Boot

The image ships a demo probe that monitors the instance's own status endpoint, so the full probe-to-surfacer-to-metrics pipeline is exercised and reporting success the moment the instance comes up with no external dependency. From there you edit one config file to add probes for your own targets, restart the service, and scrape the metrics endpoint into Prometheus, Grafana, or any Prometheus-compatible alerting stack.

## Application Architecture

• Cloudprober runs as a hardened systemd service, bound to loopback only
• nginx terminates TLS on port 443 and fronts the status page and metrics endpoint with HTTP basic authentication
• No database and no console to administer, so your monitoring configuration lives in version-controllable text
• A single config file at /etc/cloudprober.cfg drives all probe definitions

## Getting Started

1. Launch the AMI and allow inbound TCP 443 in your security group

2. SSH into the instance and retrieve your generated credentials from the root-only credentials file

3. Access the status page at https://your-instance-ip to verify the demo probe is reporting

4. Edit /etc/cloudprober.cfg to add probes for your own targets

5. Restart the service and point your Prometheus scrape config at the metrics endpoint

## Built and Verified by cloudimg

Every cloudimg image is built from the official upstream release, checksum verified at build time, fully patched, and verified working end to end before publication. Backed by 24/7 cloudimg support via email and live chat.