We are transitioning to a DevOps & SRE model, but we have a lot of legacy monoliths that aren't easily observable. Beyond just 'uptime,' what specific SLIs and SLOs should we be tracking to prove the value of our reliability engineering efforts to stakeholders?
3 answers
When dealing with legacy systems, focus on the "Four Golden Signals": Latency, Traffic, Errors, and Saturation. For a monolith, latency is often the most telling metric. You should set an SLO that defines what percentage of requests must be served within a specific timeframe. For example, 95% of requests should complete in under 500ms. Tracking the error rate is equally important—not just 5xx errors, but also logical errors that impact user experience. By quantifying these, you can create an Error Budget that dictates when to slow down feature releases in favor of stability.
How do you realistically calculate saturation for a legacy application running on physical hardware where we don't have modern container-level monitoring or auto-scaling capabilities?
Don't forget about Mean Time to Repair (MTTR). In legacy systems, documentation is often poor, so tracking how long it takes to recover is a vital metric.
Spot on, Laura. Improving the runbooks for these older systems is one of the fastest ways to lower your MTTR and improve overall team confidence.
Gregory, you can start by monitoring OS-level metrics like CPU wait time and disk I/O throughput. Even on bare metal, tools like Prometheus with the Node Exporter can give you enough visibility to see when your system is nearing its breaking point, allowing you to trigger alerts before a total failure occurs.