From grafana
Extract all metric names referenced in Grafana dashboards using the Grafana API, with incremental caching so only changed dashboards are re-parsed on subsequent runs. Use this skill when the user wants to know which metrics are used in Grafana, cross-reference Grafana dashboards with TSDB ingestion data, find metrics that are ingested but not used in any dashboard, identify broken dashboard panels referencing missing metrics, or prepare for a metric cleanup by getting the full list of Grafana-referenced metrics. Also trigger when the user mentions "dashboard metrics", "metrics used in Grafana", "grafana metric list", "cross-reference Grafana", or "which metrics does Grafana use".
How this skill is triggered — by the user, by Claude, or both
Slash command
/grafana:grafana-metrics-extractionThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Discover every metric name used across all Grafana dashboards, with smart caching that avoids re-processing unchanged dashboards on subsequent runs.
Discover every metric name used across all Grafana dashboards, with smart caching that avoids re-processing unchanged dashboards on subsequent runs.
CRITICAL: NEVER read, display, or log the contents of .env files or the values of credential environment variables. The script auto-loads .env from the working directory (or any parent). You do not need to read, source, or inspect .env — just run the script.
To verify credentials are configured without exposing them:
test -n "$GRAFANA_TOKEN" && echo "GRAFANA_TOKEN is set" || echo "GRAFANA_TOKEN is NOT set"
The script auto-loads variables from the nearest .env file (walking up from CWD). You can also set them as shell environment variables.
# $GRAFANA_URL - Grafana base URL (required)
# export GRAFANA_URL="https://grafana.example.com"
#
# Authentication (one of the following is required):
#
# $GRAFANA_TOKEN - Grafana service account token (recommended)
# export GRAFANA_TOKEN="glsa_xxxxxxxxxxxx"
#
# $GRAFANA_AUTH_HEADER - Alternative: full auth header
# export GRAFANA_AUTH_HEADER="Authorization: Basic dXNlcjpwYXNz"
#
# Optional:
# $GRAFANA_SKIP_TLS_VERIFY - set to "true" to skip TLS certificate verification
Creating a Grafana service account token:
glsa_... valueexport GRAFANA_TOKEN="glsa_..."If the user hasn't set these variables, ask them for the Grafana URL and API token before proceeding. Never ask the user to paste credentials in chat — instruct them to add values to .env directly.
The extraction script uses the Grafana API to fetch dashboard JSON and parse PromQL/MetricsQL expressions from:
panels[].targets[].expr) — the main query expressionstemplating.list[].query) — label_values(), query_result(), and raw PromQLannotations.list[].expr) — annotation queriesFor each metric, the script also extracts label names used alongside it:
{job="api", method=~"GET|POST"} label matchersby(method, status), without(instance), on(job), ignoring(le) clauseslabel_values(metric, label_name) template variable queriesThis label data enables downstream optimization: identifying labels that are ingested but never referenced in any dashboard for a given metric.
Only targets using Prometheus-compatible datasources (prometheus, victoriametrics-datasource) are processed. Panels using Elasticsearch, Loki, CloudWatch, etc. are skipped.
Results are cached per-dashboard as individual files in <skill_base_dir>/scripts/cache/:
scripts/cache/
meta.json — Grafana URL + last updated timestamp
dashboards/
<uid>.json — one file per dashboard
Each dashboard file contains:
{
"version": 42,
"title": "API Monitoring",
"folder": "Production",
"metrics": {
"http_requests_total": ["job", "method", "status"],
"http_request_duration_seconds_bucket": ["job", "le", "method"]
},
"cached_at": "2026-03-25T10:00:00+00:00"
}
Each metric stores its associated label names (from selectors, aggregation clauses, and label_values() calls). Dashboard files are written immediately after extraction — if the script is interrupted, already-processed dashboards are preserved. When a dashboard is deleted from Grafana, its cache file is removed. Existing single-file caches (dashboard-metrics.json) are automatically migrated on first load.
On each run:
/api/search (single API call)/api/dashboards/uid/:uidversion with cached entry — if unchanged, skip PromQL parsingThis means the first run processes everything, but subsequent runs only re-parse dashboards that were actually modified in Grafana.
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py
This outputs a human-readable summary: total dashboards, total metrics, per-dashboard breakdown, changes since last run, and the full metric list.
# Default: fetch from Grafana, use cache for unchanged dashboards
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py
# Force re-fetch and re-parse everything (ignore cache)
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --force-refresh
# Report from cache only (no API calls)
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --cached-only
# Output as JSON (for programmatic use)
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output json
# Output just the metric names, one per line (for piping)
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output metrics-only
# Output metrics with their labels in TSV format (metric<TAB>label1,label2,...)
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output metrics-with-labels
# Custom cache directory
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --cache-dir /tmp/my-cache
The summary output shows:
After extracting Grafana metrics, you can cross-reference with your TSDB (e.g. VictoriaMetrics, Prometheus, Thanos) to find optimization opportunities.
# Get Grafana metrics list
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output metrics-only > /tmp/grafana_metrics.txt
# Get ingested metrics from your TSDB (Prometheus-compatible API)
curl -s ${TSDB_AUTH_HEADER:+-H "$TSDB_AUTH_HEADER"} \
"$TSDB_URL/api/v1/label/__name__/values" | \
jq -r '.data[]' > /tmp/tsdb_metrics.txt
# Find metrics ingested but not in any dashboard
comm -23 <(sort /tmp/tsdb_metrics.txt) <(sort /tmp/grafana_metrics.txt)
# Find metrics in dashboards but not being ingested (broken panels)
comm -13 <(sort /tmp/tsdb_metrics.txt) <(sort /tmp/grafana_metrics.txt)
Use the --output metrics-with-labels format to find label optimization opportunities:
# Get metrics with their Grafana-referenced labels
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output metrics-with-labels > /tmp/grafana_metrics_labels.tsv
# Or use JSON output for programmatic access to all_metrics_with_labels
python3 <skill_base_dir>/scripts/extract_grafana_metrics.py --output json | jq '.all_metrics_with_labels'
Cross-reference with actual ingested labels to find:
metric_relabel_configs dropUse the Grafana metrics list alongside TSDB query statistics to distinguish between:
$metric_name) may produce incomplete metric names. The script strips variables but cannot predict their runtime values.label_join() or recording rule outputs may not be detected.Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.
npx claudepluginhub sergeyshevch/skills --plugin grafana