Monitoring software sucks
summary
Monitoring is presented as a set of concrete choices: assess whether monitoring is needed (e.g., for software without revenue), define the specific problem to solve, and collect only the data required. The speaker presents Inspector, a production example built over 4 years with ~600 subscriptions and customers in 30+ countries, explains its architecture and how it works, emphasizes tracing (transactions/segments/spans) because logs alone are insufficient, compares agent versus package approaches, and reports an observed overhead of about 3–5% CPU.
AI-written summary · about
chapters (20)
- 0:00Monitoring software sucks
- 1:48When not to monitor
- 2:30Monitoring’s strategic role
- 3:55Author’s context
- 8:08Monitoring stats in USA
- 10:41Monitoring fails
- 13:10Monitoring as automation
- 15:18Removing customer feedback
- 17:50Monitoring mistakes
- 18:53Developer workflow
- 21:03Connecting prod to dev
- 23:34Why monitor
- 24:17Reducing user reports
- 27:29Choosing the right tool
- 29:33Logs aren’t enough
- 32:48Error tracking limits
- 34:11What is observability
- 34:54Tracing app flow
- 36:40Monitoring agents impact
- 38:26Q&A
related talks
39mPanel Discussion: Application Monitoring
39mThe Story of One Monitoring
34mMonitoring for devs. The necessity or self-indulgence
52mHolistic Monitoring
16mMonitoring your platform from multiple locations
33mMonitoring Systems as a Service – Walking the Line between...
32mEssential Software Observability for Every Role: Look No Further
05mMonitoring Decoded, Why What and How? in 5 Ignite minutes