Expose the pali block cache stats so they are accessible in Grafana / MaaS

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 9.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Engines - Persistence
    • Fully Compatible
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Motivation
      The pali block cache stats are currently not persisted to FTDC / MaaS and cannot be queried in Grafana. This blocks fleet monitoring work such as WT-17808 (Grafana panel for the number of clusters with the block cache enabled), which only needs blockCache.maxsize > 0 but cannot reach it today.

      Why the stats are not accessible in Grafana
      In pali_block_cache.cpp, maxsize, size, count, and requests. are produced by a separate ServerStatusSectionBuilder<BlockCacheServerStatus>("blockCache"), i.e. they become serverStatus.blockCache., not serverStatus.metrics.disagg.*. In the same file, only the cache operation counters disagg.pali.handle.PutCache and disagg.pali.handle.GetCache are emitted as AutoStat, so only those follow the metrics.disagg path.

      disagg.pali.debug. works in Grafana because it matches the allowlisted prefix mongodb.serverStatus.metrics.disagg..

      If we want maxsize (and the other block cache stats) in the same Grafana / MaaS path, we have two choices:

      • Add an explicit allowlist entry for mongodb.serverStatus.blockCache.maxsize, or
      • Redesign the block-cache reporting to emit metrics under disagg. / metrics.disagg. instead of a standalone blockCache serverStatus section.

      Definition of Done

      • The pali block cache stats (at minimum maxsize) are persisted and queryable in Grafana / MaaS.
      • WT-17808 is unblocked and can build its panel on the exposed metric.

            Assignee:
            Mariam Mojid
            Reporter:
            Etienne Petrel
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: