Building a Lightweight Observability Platform on AWS

I wanted one place to answer a simple operational question: what is actually happening across the services I run?

That became Richmack Network Audit, a lightweight self-hosted observability platform running alongside my applications on AWS Lightsail.

The problem

A basic uptime check tells me whether a URL responds. It does not tell me which service is consuming memory, whether errors are concentrated on one subdomain, where requests originate, whether TLS is close to expiration, or whether the monitoring application itself is affecting the numbers.

I wanted visibility across the whole path:

Internet
  |
Route 53
  |
Nginx + TLS
  |
  +-- richmackos.com
  +-- servesense.richmackos.com
  +-- audit.richmackos.com
  |
Docker + Linux host

What the platform collects

The current system collects Nginx request telemetry and stores it in SQLite. It tracks request volume, unique IPs, bytes transferred, latency, 4xx and 5xx responses, referrers, GeoIP data, TLS state, backend health, container resource usage, and host-level memory and process information.

The monitoring agent reads host /proc, the Docker Engine socket, and Nginx logs. The Flask dashboard reads snapshots from SQLite instead of performing expensive infrastructure work in the browser request path.

That separation became important. Monitoring software can distort its own measurements if it performs synchronous probes while serving the dashboard.

Docker and host memory are not the same thing

One useful lesson was that a Linux server showing 60-70% memory usage does not mean application containers are consuming 60-70%.

Linux aggressively uses free memory for filesystem cache. Docker also has fixed overhead from dockerd and containerd. The dashboard therefore separates:

• total RAM
• available RAM
• reclaimable cache
• swap usage
• container working-set memory
• top host processes

That makes it much easier to answer the question that actually matters: what is consuming memory, and is the host under pressure?

Service health needs context

A 302 redirect from an authenticated application is not an outage. A backend returning 200 while a service's self-public probe times out is also not necessarily an outage.

Richmack Network Audit now keeps the raw public probe and backend probe while calculating an effective service-health state. That lets the dashboard preserve diagnostic evidence without turning every redirect into a false DOWN condition.

Reporting

The platform can generate a PDF report covering a selected time window with:

• executive request summary
• application reliability
• server memory
• per-service traffic
• service health
• traffic sources
• GeoIP coverage
• container memory
• active alerts

The goal is not to reproduce every Datadog feature. The goal is to understand the observability stack by building the pieces I actually need.

What I learned

Building the monitoring system exposed issues that are easy to miss when using a managed observability product: schema migrations, SQLite write contention, health-check semantics, self-monitoring loops, container namespaces, Linux cache behavior, and the difference between raw metrics and useful operational signals.

That is exactly why I build these systems: not only to deploy software, but to understand what happens after it is deployed.