“缓存命中率是多少”看似是一个简单问题，实际首先需要回答：哪一层缓存、哪类对象、哪段时间窗口，以及命中相对于什么请求集合。

从请求路径建模

NFS 请求进入 Ganesha 后，可能涉及元数据缓存、属性缓存、目录项缓存以及后端文件系统自身的页缓存。只看某个局部计数器，很容易把“没有访问后端”误解成“数据缓存命中”。

一个可解释的指标需要明确分母。例如，属性缓存命中率的分母应是可由属性缓存回答的查询，而不是全部 NFS 操作。跨层汇总前，还要避免同一个请求被多次计数。

观测边界

建议同时记录三类信息：入口操作量、Ganesha 到 FSAL 的调用量、后端实际 I/O。它们构成一条可核对的因果链。单点指标适合告警，多点对照才适合分析。

短时间窗口会受到突发流量影响，累计值又会掩盖变化。实践中可以保留单调递增计数器，在采集端计算多个窗口的速率与比率。

结论

缓存指标不是越多越好。最有价值的指标，是能够对应到明确请求路径、支持反证，并在配置或版本变化后仍保持语义稳定的指标。