| name | qdrant-monitoring-debugging |
| description | Diagnoses Qdrant production issues using metrics and observability tools. Use when someone reports 'optimizer stuck', 'indexing too slow', 'memory too high', 'OOM crash', 'queries are slow', 'latency spike', or 'search was fast now it's slow'. Also use when performance degrades without obvious config changes. |
How to Debug Qdrant with Metrics
First check optimizer status. Most production issues trace back to active optimizations competing for resources. If optimizer is clean, check memory, then request metrics.
Optimizer Stuck or Too Slow
Use when: optimizer running for hours, not finishing, or showing errors.
- Use
/collections/{collection_name}/optimizations endpoint (v1.17+) to check status Optimization monitoring
- Query with optional detail flags:
?with=queued,completed,idle_segments
- Returns: queued optimizations count, active optimizer type, involved segments, progress tracking
- Web UI has an Optimizations tab with timeline view and per-task duration metrics Web UI
- If
optimizer_status shows an error in collection info, check logs for disk full or corrupted segments
- Large merges and HNSW rebuilds legitimately take hours on big datasets. Check progress before assuming it's stuck.
Memory Seems Too High
Use when: memory exceeds expectations, node crashes with OOM, or memory keeps growing.
- Process memory metrics available via
/metrics (RSS, allocated bytes, page faults)
- Qdrant uses two types of RAM: resident memory (data structures, quantized vectors) and OS page cache (cached disk reads). Page cache filling available RAM is normal. Memory article
