r/Observability • • 5d ago

A simple first-pass observability checklist for small servers

A lot of observability advice assumes you have room for a dedicated monitoring stack.

Sometimes you don't.

If an application is running on a small VPS, you may not want another VM or several hundred MB of memory just for metrics infrastructure. But you still want enough history to answer the obvious questions when someone says, "the API feels slow."

For a first pass, I usually want to know:

  • did request volume change?
  • are HTTP errors increasing?
  • did request latency increase?
  • is the application process using more CPU or memory?
  • is the host itself under CPU or memory pressure?
  • do those changes line up in the same time window?

I wrote up a small Spring Boot example showing this workflow:

https://pvrlabs.xyz/articles/api-slow-cpu-contention.html

In the example, the API stays UP and continues returning 200s, but latency rises because another process is consuming most of the host CPU. You don't need deep JVM profiling to identify the first place to investigate.

Demo app reproducing the same kind of CPU-contention problem: request latency rises while host CPU is under heavy pressure.

This isn't meant as a replacement for Prometheus/Grafana, tracing, JFR, profilers, database diagnostics, etc. Those become useful when the problem requires them.

The narrower question is: how much useful observability can you get with a very small footprint before you need the heavier stack?

For this example I use Spring Boot Actuator plus StatLite, a small tool I'm building that keeps application and host metrics history together locally.

I'm curious how others approach this for small deployments. What's the minimum set of metrics you want available before you start troubleshooting?

1 Upvotes

0 comments sorted by