Challenges, Best Practices, and Solutions for Monitoring and Alerting...
summary
Atlassian monitors Jira for millions of customers with a multi‑tenant, shard‑based design and limits per‑tenant metrics because per‑tenant cardinality explodes; metrics come from AWS shards and stacks and are visualized with a tool called micros built in A‑frame and 3js (VR). The stack uses Prometheus pull model and Splunk/Signalfx for high‑cardinality workloads. Operational fixes are downsampling, lower collection resolution, splitting metrics and shard‑level visibility. A compression proof‑of‑concept claims 17x query speedup and ~40x storage reduction but depends on input resolution and degrades on highly variable series.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:05Monitoring high cardinality
- 3:30Visualizing metrics in 3D
- 5:56Dangers of unchecked cardinality
- 7:19High cardinality necessity
- 8:22Jira’s multi-tenant challenges
- 10:27Time series DB types
- 11:52Popular time series DBs
- 13:58Compression techniques for time series
- 15:03High cardinality risks
- 16:50Reducing metric cardinality
- 17:30Novel metric compression
- 20:45Q&A
related talks
44mIterative metrics, dashboards and monitors
41mScaling Observability: From Chaos to Clarity with Open Source Tools
52mBuilding a culture of observability
56mFull-stack observability and application monitoring with
52mIs your JVM app flying blind? Unmask hidden issues with Observability superpowers!
32mDesign Observability Solution for Multi-Tenancy Environment
50mIntuit Journey To Unified Observability at Scale: Challenges, Be...
32mScalable Monitoring Using Prometheus with Apache Spark