Observability: Catch Problems Before They Happen
summary
A three‑node cluster fails a deployment because a node is down for two months and a second node is also offline, demonstrating lack of monitoring; coverage includes unit tests and error classes, logging to a central ELK-style stack with Filebeat, database error documents with automated retries, and use of MarkLogic features like manage/v2 view=health-check (JSON), the history app and the index memory usage view to spot heavy indexes. Watch for deadlocks above zero, disk corruption auto‑shutdown in MarkLogic 12, and MLCP load patterns.
AI-written summary · about
chapters (7)
- 0:00Introduction and problem
- 3:01Testing and error handling
- 9:04Capacity and infrastructure
- 15:49History and real-time monitoring
- 21:13Alerting and logging best practices
- 30:36User engagement and metrics
- 35:31Key takeaways and Q&A
related talks
23mNavigating in the Dark
36m101 Ways to Crash Your Cluster
58mObserving Applications in Production
31mBest Practices for Effective Multi-Cluster Observability: Lessons Learned
27mObserving Failure in Reactive Systems
11mKubernetes Observability
40mSurvivability of Observability: Taking your DIY system to success
44mThe Holy Trinity of Observability: Logs, Metrics, and Traces