4.3 监控与故障排查

4.3 监控与故障排查

本节摘要：调优和高可用做得再好，系统一旦在线上跑起来，你就需要一双眼睛时刻盯着它。本节从可观测性的三根支柱——指标、日志、追踪讲起，讲清各自管什么、能回答什么，落到 Qdrant 的关键 Prometheus 指标怎么读、结构化日志怎么用，再给出延迟升高、内存增长、副本不同步等高频故障的排查路径，以及「宁可少而准」的告警策略，帮你在故障发生时用最短的时间看见它、定位它、修好它，把平均恢复时间压到最低。

上手前先明确

阅读完本节，你应当能够：

1. 区分指标、日志、追踪三类可观测性信号各自的作用
2. 说出 Qdrant 几个关键 Prometheus 指标及其含义
3. 按根因分析的步骤从症状定位到根本原因
4. 识别延迟升高、内存增长、副本不同步的常见诱因
5. 设置合理的告警阈值，避免告警疲劳
6. 用结构化日志与请求标识还原一次故障的现场

一、问题与直觉：看不见的系统最危险

运维这行有个很扎心的现实：问题很少在白天上班时间、大家盯着看的时候发生，它喜欢挑凌晨三点、流量低谷、或者刚发布完新版本的时候冒出来。而那时候，你能依赖的只有一件事——系统在问题发生前留下的一串信号。如果没有这些信号，你面对的就是一个黑箱：它慢了，但不知道慢在哪；它报错了，但不知道哪台机器、哪个集合、哪次请求。

这就是可观测性的价值。它要解决的不是「让系统不坏」，而是「系统坏了，我能以多快的速度知道它坏了、坏在哪、为什么坏」。这个速度直接决定停机时间的长短，也决定你是在五分钟内定位还是折腾一整个通宵。

很多人对监控的理解停留在「装个面板，看看曲线」。这没错，但不够。真正的可观测性要能回答三类不同层次的问题：第一类「发生了什么」，靠指标和日志；第二类「为什么会发生」，靠把指标、日志、链路串起来的分析；第三类「接下来会不会发生」，靠趋势和异常检测。只有第一类，你是在被动救火；做到第二、三类，才谈得上主动运维。

二、核心原理：指标、日志、追踪三根支柱

可观测性不是单一工具，而是三类信号的组合，业内习惯叫「三支柱」。

指标是聚合后的数值，比如每秒查询数、P99 延迟、内存占用。它的特点是轻量、可长期存储、适合画趋势图和触发告警，但它是「统计结果」，丢了单次请求的细节——你知道延迟升高了，却不知道是哪次请求、带了什么参数。

日志是离散的事件记录，保留了丰富的上下文：哪次请求、什么参数、哪行代码、什么错误。它是排障的「第一现场」，缺点是量大、难聚合，全文搜索慢。

追踪记录一个请求从进到出的完整路径和每段耗时，在跨服务调用里特别有用。对 Qdrant 而言，它更多体现在「客户端到服务端」这一段以及服务端内部各阶段的耗时，能补足指标和日志都看不清的「时间都花在哪一环」。

这张图把三支柱各自的定位和常用工具列清楚。三者不是竞争关系，而是互补：指标告诉你「哪里不对」，日志告诉你「当时发生了什么」，追踪告诉你「时间都花在哪个环节」。排障的顺序通常也是先看指标缩小范围，再翻日志还原现场，必要时用追踪追细节。

三、关键指标：看什么、怎么看

Qdrant 通过 Prometheus 端点暴露指标，这是监控它的核心途径。指标很多，但真正值得盯的、能提前预警的，其实就几类。

第一类是请求相关：总请求数能算出 QPS，请求延迟的直方图能算出 P50、P95、P99，错误请求数能算出错误率。这三样合起来，是「服务健不健康」最直接的体检表。P99 突然抬头，几乎一定有问题；错误率上升，说明有请求在失败，而不是单纯变慢。

第二类是资源相关：集合的磁盘占用、内存占用、段数量。这三样是「会不会撑爆」的预警。内存持续逼近上限，接下来就是换页和 OOM；磁盘持续增长，说明数据在涨或段没合并；段数量异常多，查询会变慢。

第三类是集群相关：副本状态、Raft 领导者标识、分片分布。这类指标只在分布式部署里出现，却能提前暴露「节点失联」「副本落后」「领导者频繁切换」这些最难缠的问题。

读指标不能只看孤立的数字，要看它们怎么一起变。举个常见组合：QPS 平稳、P99 却升高，说明不是流量变大，而是单次请求变重，问题多半出在索引结构、过滤条件或者后台段合并上；反过来 QPS 下降、错误率上升，问题更可能出在连接、负载均衡或某个节点失联上。把请求、资源、集群三类指标叠在一起看，往往一眼就能圈出「是这台机器扛不住，还是这个集合的数据变了」。这个「叠着看」的习惯，比记住几十个指标名更值钱。

💡 关键直觉：监控的本质是「给正常画一条基线」。单看某个时刻的延迟数值没有意义，有意义的是它偏离正常基线的幅度和速度。所以先让系统平稳跑一段时间、记下各指标的常态区间，之后任何异常都一目了然——没有基线的告警，都是靠猜。

⚠️ 常见坑：只看平均延迟不看分位。平均延迟会被大量快请求「拉平」，掩盖少数慢请求的恶化。用户体感最差的那部分恰恰藏在 P99 甚至 P99.9 里，所以延迟指标一定要看分位数，尤其是 P99。

四、日志与链路：还原一次故障的现场

指标告诉你「有问题了」，但要找到「为什么」，得翻日志。Qdrant 支持 JSON 格式的结构化日志，这对集中式日志系统非常友好——结构化意味着每个字段都能被机器解析、检索、过滤，而不是靠人肉 grep 一段半格式化的文本。

生产环境的日志通常设成 INFO 或 WARN 级别，在不制造太多噪音的前提下保留关键事件。排查时，在集中式日志系统里按「时间范围 + 错误关键字 + 请求标识」组合搜索，能快速锁定问题发生那一刻的上下文。这里有个容易被忽略的习惯：给请求带上统一的标识，让它贯穿「客户端调用、服务端处理、错误返回」整个过程，排障时按这个标识一搜，一条请求的一生就完整了。

链路追踪则是日志的补充。当一次查询慢，但指标和日志都看不出「慢在计算、慢在 I/O、还是慢在等待」，追踪就能把内部各阶段的耗时切开。它不一定每时每刻都开，但出了问题开一下，往往能省下大量瞎猜的时间。

一个可操作的习惯是给查询带上统一标识：客户端记录它，服务端日志也打印它。故障时先锁定几条慢请求的标识，再拿标识到日志系统里过滤，这条请求「什么时候进来、命中哪个集合、带了什么过滤条件、耗时多少、有没有报错」就完整还原了。这比在几十万行日志里翻关键字快得多，也是结构化日志真正的价值所在。

五、常见故障与排查路径

排查要有章法，而不是凭直觉乱翻。一个可复用的思路是根因分析：先确认症状，再界定影响范围（单节点还是全集群、单集合还是全局），收集相关指标和日志，提出假设并验证，找到根本原因后修复，最后复盘防止复发。沿着这个流程走，比「先重启再说」可靠得多。

几个高频故障的排查路径，可以浓缩成一张表：

这张流程图是「P99 延迟升高」这一个具体告警的排查骨架。先分全局还是局部，全局查集群和资源、局部查集合和节点，两边汇合到「分析指标与日志」，再定位根因、修复验证、复盘。把它套到其他告警上，骨架是一样的，只是每个分支里要查的指标换一换。

💡 关键直觉：排查的一半时间花在「界定影响范围」上。全局慢和单集合慢是两码事，前者指向集群资源或网络，后者指向这个集合的索引、数据或过滤条件。范围没界定清楚就动手，很容易在错误的方向上浪费时间。

六、告警策略：宁可少而准

告警是把「系统异常」翻译成「人该行动」的最后一环，也是最容易出问题的一环。告警太少，故障没人知道；告警太多，运维被淹没，最终对告警麻木——这就是「告警疲劳」，它的危害比漏报更隐蔽，因为人会习惯性地忽略所有告警，包括真正要紧的那条。

对抗告警疲劳，靠的是「少而准」。每条告警都要能回答两个问题：这条告警意味着需要人做什么、不做会怎样。能回答的才配发出来，回答不了的应该降级为面板上的曲线，留给主动查看。阈值也要设得有区分度：CPU 连续五分钟超过九成才告警，而不是一超过就告警；P99 超过服务等级目标并持续一段窗口才告警，而不是瞬时抖动就响。趋势告警和基于历史基线的异常检测，比死板阈值更不容易误报。

通知渠道上，把告警按严重程度分流：需要立即处理的走即时通讯和电话，可以稍后看的走邮件或工单。这样紧急的事不会被日常噪音淹没，日常的事也不会半夜把人吵醒。

告警的另一个锚点是服务等级目标。先给查询延迟、错误率、可用性定一个业务能接受的目标值，告警阈值就围绕这个目标值来设，而不是拍脑袋填一个数字。比如业务要求 P99 低于一百毫秒，那告警就设在 P99 逼近或超过一百毫秒并持续几分钟时触发。有了目标值兜底，告警就从「这数字看着不对」变成了「这数字已经越过业务红线」，值班的人收到后不用先判断轻重，直接进入处置。

核心回顾

• 可观测性三支柱：指标看趋势、日志还原现场、追踪定位耗时环节
• 指标要画基线：有意义的是偏离常态的幅度，不是单点数值
• 延迟看分位：P99 比平均延迟更能暴露少数慢请求
• 日志要结构化：JSON 输出加统一请求标识，让机器能搜、人能追
• 根因分析有步骤：界定范围、收集数据、假设验证、修复复盘
• 常见故障各有路径：延迟、内存、磁盘、副本、领导者五类各有排查重点
• 告警宁可少而准：每条告警都要能回答「该做什么、不做会怎样」
• 对抗告警疲劳：阈值设区分度、按严重度分流、用趋势代替瞬时抖动

到这里，性能调优、高可用、监控排查三块拼齐了。下一章我们转向 Qdrant 的生态系统与未来走向——看它如何与 LangChain、LlamaIndex 等 AI 工具链协作，以及向量数据库这条赛道接下来会往哪走。