用途：借助指标与可观测性工具，诊断 Qdrant 生产环境中的常见问题，包括优化器卡住、索引过慢、内存过高等情况。
排查顺序：先检查优化器状态。多数生产问题源自活跃的优化任务争抢资源。若优化器状态干净，再检查内存，最后检查请求指标。
优化器卡住或过慢：当优化器运行数小时未完成或报错时使用。可用 /collections/{collection_name}/optimizations 端点（v1.17+）查看状态，并可用 detail 标志查询，如 ?with=queued,completed,idle_segments，返回排队优化数量、活跃优化器类型、涉及的段和进度。Web UI 中的 Optimizations 标签提供时间线视图和各任务耗时指标。若集合信息中 optimizer_status 显示错误，应检查日志，排查磁盘写满或段损坏。大数据集上的大合并与 HNSW 重建耗时数小时属正常，应先看进度再判断是否卡住。
内存偏高：当内存超出预期、节点因 OOM 崩溃或内存持续增长时，可通过 /metrics 获取进程内存指标（RSS、已分配字节、缺页）。Qdrant 有两类内存：常驻内存（数据结构、量化向量）和操作系统页缓存（缓存磁盘读取）。页缓存占满可用内存是正常现象。若常驻内存（RSSAnon）超过总内存的 80%，需进一步排查。可用 /telemetry 查看各集合的点数与向量配置明细。估算预期内存可参考：num_vectors * dimensions * 4 bytes * 1.5（向量部分），再加 payload 与索引开销。常见增长原因包括 always_ram=true 的量化向量、过多 payload 索引、优化期间较大的 max_segment_size。
查询慢：需定位原因时，按端点跟踪 rest_responses_avg_duration_seconds 与 rest_responses_max_duration_seconds，v1.8+ 可用直方图指标 rest_responses_duration_seconds 做百分位分析，gRPC 对应指标前缀为 grpc_responses_。先看优化器状态，活跃优化会争抢 CPU 与 I/O 拖慢搜索；再通过集合信息查看段数量，批量上传后段过多未合并会导致搜索变慢；对比带过滤与不带过滤的查询耗时，差距大可判断缺少 payload 索引。
避免做法：排查慢查询时忽略优化器状态；页缓存占满内存时误判为内存泄漏；在优化器运行时修改配置；在批量上传刚结束时急于归咎 Qdrant（段尚未合并）。