From d18f713f91adc81d3fc26a345cb04085c3edbeed Mon Sep 17 00:00:00 2001 From: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> Date: Tue, 28 Jul 2026 15:32:26 +0100 Subject: [PATCH] docs(telemetry): point the runbook at the renamed found-ratio panel The panel was renamed from NuDB Cache Hit Ratio to NuDB Read Found Ratio, which left the runbook naming a title that no longer exists and carrying a paragraph saying the rename had not happened yet. Both are corrected, and the explanation now says why the ratio is a found rate: the counter increments whenever a fetch returned an object, and a node with online_delete has no object cache at all. Co-Authored-By: Claude Opus 5 (1M context) --- docs/telemetry-runbook.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/telemetry-runbook.md b/docs/telemetry-runbook.md index 1727e5c492..9545c24887 100644 --- a/docs/telemetry-runbook.md +++ b/docs/telemetry-runbook.md @@ -2655,13 +2655,15 @@ Two more pairs from the same family: series. Existing panels that already carry part of this picture, on the _Ledger Data & -Sync_ dashboard: **NuDB Read Latency**, **NuDB Cache Hit Ratio**, **NuDB Read +Sync_ dashboard: **NuDB Read Latency**, **NuDB Read Found Ratio**, **NuDB Read Pressure**, and **Job Queue Backlog and Deferred by Type** for the lane occupancy that this procedure tells you to distrust on its own. -The **NuDB Cache Hit Ratio** title is wrong and has not been changed yet: the panel -plots `node_reads_hit / node_reads_total`, which is the found rate described above, -not a cache hit ratio. Read it as the found rate regardless of what the title says. +**NuDB Read Found Ratio** plots `node_reads_hit / node_reads_total`. That is the +found rate, not a cache hit ratio: the underlying counter increments whenever a +fetch returned an object, and a node with `online_delete` has no object cache at +all. A rate near 1.0 alongside an expensive read time is the cold-read signature, +not a sign the cache is working. ### High memory usage