Monitoring Your OpenSearch Cluster Effectively
summary
Explains why clusters go red (primary shard loss from node drops) and how large aggregations trigger G1GC OOM from large aggregations; recommends right‑sizing JVM heap (~50% of RAM), lowering the default 95% circuit‑breaker, using keyword subfields instead of fielddata, and enabling search back pressure. Advises exporting node stats to TSDB (once per minute), using performance‑analyzer, slow logs, profile API, hot threads, cat allocation/cat shards and task APIs to find shard or load skew, and remedies like reroute, split/shrink, reindex and 10–50 GB shard sizing.
AI-written summary · about
chapters (14)
- 0:00OpenSearch monitoring intro
- 1:04Red cluster states causes
- 4:15JVM heap and GC
- 7:04Prevent OOM proactively
- 10:57Search back pressure checks
- 13:27Performance Analyzer monitoring
- 16:13Timeouts and slow logs
- 20:47Node stats hot threads
- 25:01Cluster imbalance shards
- 28:51Load skew impact
- 32:02Debug skewed clusters APIs
- 36:15Prevent cluster imbalance
- 38:26Hotspots shard management
- 39:10Q&A query queuing
related talks
28mRunning OpenSearch at Scale in High-Traffic Gaming Systems
40mMaking your elastic cluster perform
04mOpenSearch Performance and Monitoring
16mTop Elasticsearch tips
31mMaximize Resource Efficiency with Separated Index and Search Workloads
29mThe Search for Speed
43mMulti-tenancy for all workloads
41mScaling Observability: From Chaos to Clarity with Open Source Tools