Bounded label registries keep agent metrics from adding a time series per run

Every field on that first counter is something a person debugging a failed run would want. It gets past code review for the same reason. In metric systems that key a series on the full attribute set, the counter writes a new time series for each distinct combination of its labels ^[2]. A run ID differs on every run, so the counter adds at least one series per run before the prompt or the stringified tool arguments multiply it further ^[19]. The post lists prompts, run IDs, user IDs, URLs, document IDs, tool arguments and raw errors as effectively unbounded, and notes that agent workloads produce all of them naturally ^[3].

The fix is a split by signal. Metric labels come from small vocabularies the application owns: workflow, environment, outcome, model family and policy result ^[4]. Those answer aggregate questions, such as whether failures are rising for one workflow or policy blocks jumped after a release. They cannot point at a single run ^[5]. The trace carries the run ID, parent-child structure, timing and links to protected evidence, and it is sampled and retained on its own terms ^[6].

The budget is a multiplication done before deployment: the product of allowed values per label, plus a rule for anything outside the list ^[9]. The post's registry allows three workflows and three outcomes and maps everything else to "other" ^[10]. With the fallback counted, that caps the counter at 4 x 4, or 16 series, however many runs execute ^[11]. The post puts the collector or backend limit last. The instrumentation library should normalize or drop unsafe values first and count the drops under one bounded reason code ^[9].

The scheme breaks where a vocabulary grows by itself. Raw error messages carry IDs, URLs, payload fragments and provider wording that changes between versions. The post counts four error classes and keeps the original text in a protected diagnostic event ^[12]. "Keep the vocabulary versioned. If every new message becomes a new class, cardinality returns under another name," the post warns ^[13]. Tool names have the same failure: a model-generated or remote MCP tool name can be unbounded, so unknown tools become "other" on the metric while the exact name stays in the trace. Provider version strings collapse to an approved model family on metrics, with the exact model ID kept in the trace ^[14].

Traces get limits too. OpenTelemetry's semantic-convention guidance recommends low-cardinality span names and warns against unbounded attribute values, very large strings and huge arrays. A span named with the full prompt is hard to aggregate and can leak data ^[7]. The post's preferred span is named agent.tool.execute, with the tool name, workflow, outcome and error type as attributes ^[8]. Retrieval gets the same treatment: count documents and bytes, and keep queries, titles, URLs and chunk text off metric labels ^[18].

The split also draws an access line. A correlation ID can be acceptable in a restricted trace store and still be wrong as a metric label exported broadly ^[15]. In my view this is the right tradeoff for any team whose metrics are read by more people than its traces. The cost is process. Registry additions get reviewed like schema changes, and a remote tool name or a model-produced reason cannot expand the list without that review ^[16].

The post does not include a measured series count or a bill from a production system, and it scopes its time-series claim to "many metric systems" ^[2]. What the budget saves in money depends on how a given backend charges for active series. The post's instruction is to monitor active series growth and to reject or truncate oversized fields at the instrumentation boundary ^[17].