Skip to content

[DESIGN]: Metric/label registry, native INFO field catalog, and per-command cardinality bounds #152

@ELares

Description

@ELares

Filed from the IronCache pre-implementation coverage audit (2026-06-13): no existing issue adequately owned this.

Why this is needed

Own the concrete observability contract: exact Prometheus metric names, label sets, and series types; the IronCache-native '# IronCache' INFO section field catalog (hit ratio, shard balance, fsync lag, compression ratio, SSD endurance, advisor state); the commandstats/latencystats/errorstats series with an explicit per-command cardinality bound so high-arity workloads cannot explode label cardinality; and versioning so dashboards survive upgrades. #86 lists 'exact metric names/labels (lock before M1 freeze)' and native-field placement as OPEN DECISIONS, not an owned tested deliverable, and is silent on per-command cardinality limits despite the ops research enumerating those high-cardinality INFO sections. Lock it before M1 freeze as a tested artifact. The dashboard contract has no owner with acceptance criteria.

Context

Relates to / partially overlaps #86. Part of the vision EPIC #1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:configArea: configarea:observabilityArea: observabilitycritical-pathOn the thin vertical slice to the first running binarydesignDesign specification / decision record to be vettedwave:1Readiness wave 1: core engine + protocol

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions