Case Study · Monitoring & Observability
Driving Monitoring & Observability Transformation for a Global Technology Services Company
A free uptime checker told the company its servers were up. It could not tell them a disk was filling, memory was climbing, or an outage was forty minutes away. I made the case for Netdata, deployed it across AWS, Azure, and GCP, and moved the company from finding out at the same time as its customers to seeing it coming.
Overview
A free uptime checker will tell you a server is up. That is the whole of what it tells you.
It will not tell you that a disk has been filling for three weeks, that memory has been climbing since the last deploy, or that the database has been slowly degrading all afternoon. It notices when the patient stops breathing. Everything before that is invisible.
That was the monitoring strategy at a company running production systems across three clouds, for itself and for its customers. Nothing was technically wrong with it. It just meant that every incident was discovered at the same moment the customer discovered it, and every post-mortem was reconstructed from memory because there was no history to look at.
I built the case for changing that, evaluated the market, deployed Netdata, and have administered it since. The shift was from being told about outages to watching them approach.
Organization
A technology consulting and managed services provider, roughly 200 employees across the United States and India. Its infrastructure spans Amazon Web Services, Microsoft Azure, and Google Cloud Platform, running production systems for internal operations and for customer workloads.
Managed services is the part that matters here. When you operate infrastructure on someone else’s behalf, the quality of your monitoring is the quality of your service, and there is nowhere to hide a gap.
Challenge
Availability checks came from a free uptime service. Online or offline, nothing in between.
That left the company blind to almost everything worth knowing:
- No visibility into server or application performance.
- No central place where infrastructure metrics were collected or correlated.
- Incident response that started when something had already failed.
- Almost no historical data for troubleshooting or capacity planning.
- No way to catch degradation before users felt it.
The harder part was not technical. Like a lot of organizations with mature environments, new operational tooling needed a clear business case, and leadership was rightly focused on keeping costs and administrative overhead down. Enterprise observability platforms are expensive and they are hungry — they arrive with agents to manage, retention to pay for, and a dashboard nobody has time to curate. Asking for one on the grounds that engineers would like better graphs was never going to work.
So the target was narrow: visibility across production infrastructure, degradation caught before it became an outage, faster identification when something did break, real history to troubleshoot against, coverage for both internal and customer systems — and all of it at a cost and an administrative weight that could survive the conversation with leadership.
Evaluation and Strategy
I researched the observability market independently, before asking anyone for anything, scoring platforms on capability, deployment effort, scalability, administrative burden, and cost.
After testing several, Netdata came out ahead:
- Real-time metrics with very little deployment effort.
- Rich data across operating systems, applications, and services.
- Genuine observability rather than dressed-up uptime checking.
- Low administrative overhead, which mattered as much as the feature list.
- Broad compatibility with the existing cloud estate.
- A pricing model that fit the constraint instead of fighting it.
Then I made the argument in the language the decision was going to be made in. Not “we lack observability” — that describes a gap and asks somebody else to care about it. Instead: here is what an hour of undetected degradation costs us with a managed services customer, here is how much of our troubleshooting is guesswork for want of history, and here is what this costs. Framed that way, the approval was straightforward.
Implementation
With support in place, I led the deployment from planning to production:
- Designed the deployment architecture.
- Established monitoring standards.
- Rolled agents out across supported infrastructure.
- Configured dashboards and alerting.
- Integrated systems across AWS, Azure, Google Cloud Platform, and on-premises resources.
- Validated coverage and alert accuracy.
- Set up the ongoing operational practices.
I am also the platform’s primary administrator: configuration, maintenance, updates, expanding coverage, and the tuning that keeps alerts worth reading.
The change in what engineers could see was immediate. CPU, memory, storage performance, network activity, process behavior, application health — in real time, per second, across the estate. And because it was all being recorded, root cause analysis stopped being a memory exercise. You could look at the fifteen minutes before an incident and see it forming.
Results
- Monitoring moved from reactive outage detection to proactive infrastructure management.
- Resource constraints and performance degradation caught early.
- Visibility unified across three cloud platforms.
- Troubleshooting faster, with centralized metrics and real history behind it.
- Operational decisions made against current performance data instead of instinct.
- Higher confidence in infrastructure health across engineering teams.
- Better service for internal stakeholders and managed services customers alike.
The practical difference is the order of events. Before, a problem announced itself by breaking something. Now abnormal behavior gets noticed while it is still just abnormal behavior, and somebody intervenes while intervening is cheap.
The technical work was real, but the project’s actual difficulty was organizational. Getting a tool approved in a cost-conscious environment meant understanding what leadership was protecting, showing the cost of the current state in their terms, and then delivering something that justified the decision rather than merely satisfying the request. I was the technical lead and the internal advocate — and the advocacy is what made the engineering possible.
Key Technologies
- Netdata
- Amazon Web Services (AWS)
- Microsoft Azure
- Google Cloud Platform (GCP)
- Linux
- Infrastructure Monitoring
- Observability
- Systems Administration
- Performance Monitoring
- Incident Detection
- Capacity Planning
Lessons Learned
Uptime monitoring answers whether a service is available. Observability answers why it is behaving the way it is, and whether it will still be available in an hour. Those are different questions, and only one of them helps you before an outage.
The second lesson is one engineers learn slowly. A good technical case is not a business case. “We have no observability” is true, and it loses. “Here is what we cannot see, here is what not seeing it has already cost us, and here is what seeing it costs” is the same argument with the audience taken into account — and that one gets funded.
// Let's talk
You have ideas.
I have IT solutions.
Fifteen minutes on Zoom is usually enough to tell whether I'm the right person for what you're building.
Denver, CO · Available for architecture, infrastructure, and DevOps engagements