tsuga-audit-metrics

Audit OpenTelemetry metrics for naming, instrument type, and cardinality risks.

2|Updated May 28, 2026
One-click install
npx skills add https://github.com/tsuga-dev/agent-plugins --skill tsuga-audit-metrics
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tsuga-audit-metrics
Source: https://github.com/tsuga-dev/agent-plugins/tree/main/plugins/telemetry/skills/tsuga-audit-metrics
Command: npx skills add https://github.com/tsuga-dev/agent-plugins --skill tsuga-audit-metrics

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you detect and fix metric quality issues by auditing what your service is actually emitting and how Tsuga receives and aggregates it.

Core Features & Use Cases

  • Metric naming convention audit: Checks metric names for OTel guideline violations such as service identity, environment/version, units in names, and incorrect delimiter/structure.
  • Instrument type validation: Flags likely counter/gauge/histogram mismatches based on observed metric shape and description heuristics.
  • Cardinality risk detection: Estimates high-cardinality attribute dimensions using time-bounded group-by aggregation queries.
  • Code-side evidence support: Optionally cross-references an OTel audit checklist for deeper SDK/instrumentation review when you provide a source code path.
  • Quality report correlation: Correlates findings with existing Tsuga quality rules and warns when reports are stale.

Quick Start

Use the skill to audit a service’s emitted metrics by telling it the service name (or a metric name filter) and, if available, the related source code path for additional code evidence.

Frequently Asked Questions about tsuga-audit-metrics

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit OpenTelemetry metrics for naming convention violations?

To audit OpenTelemetry metrics for naming conventions, provide a service or metric filter to check metric names against OTel guidelines. This detects violations like incorrect delimiters, embedded service identity, or units in metric names.

What is metric cardinality risk and how do I check it in production?

Metric cardinality risk is the potential for high-dimensional attributes to cause excessive system load. You can check it by running time-bounded group-by aggregation queries on live metrics to estimate high-cardinality attribute dimensions.

How can I validate if I am using the correct OpenTelemetry instrument type?

You can validate OpenTelemetry instrument types by analyzing observed metric shape and description heuristics from live evidence. This flags likely counter, gauge, or histogram mismatches based on actual metric behavior.

Can I cross-reference OpenTelemetry metric issues with my source code?

Yes, you can cross-reference metric issues with your source code by providing a source code path. This triggers an optional OpenTelemetry audit checklist for deeper SDK and instrumentation review to validate code-side evidence.

Does this metrics audit work without setting up external dependencies?

Yes, this metrics audit works without external dependencies. It requires only a service or metric filter input to perform CLI-driven metric listing, detail extraction, and cardinality proxy checks based on live Tsuga evidence.