The Monitoring Path 2.0: Everything Has Changed
summary
Overview of Grammarly’s monitoring overhaul after moving to Docker: why they reworked monitoring and adopted zipper-stack, go-carbon, and carbon-c-relay (including benchmarks of alternatives). Details on ingesting a million unique metrics per second, the need for tags for unnamed instances and how they implemented them, plus how zipper-stack works and the overall architecture of their current monitoring stack.
AI-written summary · about
chapters (22)
- 0:00Monitoring introduction
- 1:49What are metrics
- 3:33Graphite architecture
- 6:40Carbon Cache problems
- 8:08Testing Carbon Cache
- 13:02Disk system limits
- 13:46Go Carbon solution
- 16:59Buffer optimization
- 17:44Filesystem impact
- 18:27Relay component in Graphite
- 20:36Testing Relay
- 21:19Carbon-relay-ng features
- 22:01Carbon-c-relay performance
- 23:28Metrics in distributed systems
- 25:13Testing InfluxDB
- 26:30InfluxDB tag problems
- 29:04Tags vs structures
- 30:51Comparison with Elasticsearch
- 32:18Carbon Zip role
- 32:59Monitoring and dev teams
- 35:08Q&A
- 37:40Support and operations
related talks
28mMonitoring Stack was yesterday – Observability Platform at scale!
32mMonitoring in the era of Generative AI, LLVMs, and embeddings
34mChanging the engine in flight: rebuilding monitoring at scale
34mMonarch, Google’s Planet Scale Monitoring Infrastructure
42mUnified Monitoring of Containers and Microservices [I]
27mMonitoring as Code: Managing your Observability Assets the Cloud-Native Way
22mService Monitoring Manual—2018 Edition
36mMetrics - What's your code actually doing?