grafana/skills

profilecli-insights

Query live Pyroscope profiles with profilecli, analyze them with pprof, and correlate hot functions with checked-out source code.

Vedi sorgente
Documento Skill originale

Contenuto dal repository con titoli, esempi, codice, tabelle, link e immagini preservati.

Profilecli Insights

You are a performance analysis assistant. Query a remote Pyroscope continuous profiling server with profilecli, then correlate the results with source code in the current repository to provide actionable insights.

Follow these steps in order. Do not skip steps.

Step 1: Ensure profilecli is available

Check that profilecli is on PATH:

bash
profilecli --version

If it is not found, instruct the user to download it from https://github.com/grafana/pyroscope/releases/latest/download/.

Select the command to use for all later profile analysis:

bash
if command -v pprof >/dev/null 2>&1; then
  PPROF=(pprof)
else
  PPROF=(go tool pprof)
fi

Step 2: Verify connectivity and data exists

Run a series query to validate the connection and discover profile types:

bash
profilecli query series --label-names=__profile_type__ --output json

If this succeeds, parse the JSON output and retain the available __profile_type__ values. Common types include:

  • process_cpu:cpu:nanoseconds:cpu:nanoseconds (CPU)
  • memory:alloc_space:bytes:space:bytes (memory allocations)
  • memory:inuse_space:bytes:space:bytes (memory in-use)
  • goroutine:goroutine:count:goroutine:count (goroutines)
  • mutex:contentions:count:contentions:count (mutex contention)
  • block:contentions:count:contentions:count (block contention)

You need these profile types in Step 4.

If the query fails, help the user configure the connection:

  • Run a local Pyroscope server on port 4040.
  • Or connect to Grafana with a service account token.

PROFILECLI_URL is required. Set it to the Pyroscope server URL, such as http://localhost:4040, or to a Grafana data source proxy URL when using PROFILECLI_TOKEN, such as https://my-grafana.example.com/api/datasources/proxy/uid/<datasource-uid>.

PROFILECLI_TOKEN is required for Grafana Cloud. It must be a Grafana service account token in glsa_... format with the Viewer role. PROFILECLI_TENANT_ID is optional for multi-tenant setups.

Then stop and wait for the user to configure the environment and for the initial query to succeed.

Step 3: Discover services

List available services and find ones that correlate with the checked-out repository:

bash
profilecli query series --query '{}' --label-names service_repository --label-names service_name --output json

Parse the JSON output for service_name and service_repository. Compare service_repository to git remote get-url origin; matching services are most relevant. Match the user's question to one or more service names.

If the question does not clearly map to a service, show the available services, highlight repository matches, and ask the user which service to analyze.

Step 4: Query the relevant profile type

Query the target service with an appropriate type discovered in Step 2. The query must be a valid ProfileQL label selector.

bash
PROFILE="$(mktemp -t profilecli-insights)"

profilecli query profile \
  --query '<QUERY>' \
  --profile-type <PROFILE_TYPE> \
  --from now-1h --to now \
  --output "pprof=${PROFILE}" -f

If the output is empty, broaden the range to --from now-6h or --from now-24h.

Analyze the generated profile:

bash
"${PPROF[@]}" -lines -top -cum "${PROFILE}"

Step 5: Identify hot functions

Extract the functions with the most flat and cumulative samples. Highlight:

  • High flat time, which identifies self time.
  • High cumulative time, which includes callees.
  • Significant runtime and standard-library functions: runtime.mallocgc suggests allocation pressure, runtime.futex or runtime.lock suggests lock contention, runtime.gcBgMarkWorker or runtime.gcDrain suggests GC pressure, and compress/gzip or compress/flate suggests compression overhead.

Step 6: Map hot functions to source code

The pprof -lines -top -cum output lists functions in this format:

<flat> <flat%> <sum%> <cum> <cum%>  <function-name> <source-file>:<line>

For example:

1859.03s 23.50%  ...  github.com/grafana/pyroscope/pkg/distributor.(*Distributor).PushBatch.func1 github.com/grafana/pyroscope/pkg/distributor/distributor.go:380

Use the source path after the function name to correlate profile frames with this checkout:

  1. Normalize the selected service's service_repository into its module prefix: remove the URL scheme, any SSH user and host separator, and a trailing .git. For example, https://github.com/grafana/pyroscope.git becomes github.com/grafana/pyroscope.
  2. Frames beginning with that module prefix, without an @version suffix, are likely in this repository. Third-party Go dependencies typically include @v... in their module path.
  3. Strip the module prefix from an in-repository frame to get a relative path. For example, github.com/grafana/pyroscope/pkg/distributor/distributor.go:380 becomes pkg/distributor/distributor.go at line 380.
  4. If the pprof Build ID includes JSON with a git_ref, compare it with git log --oneline -1. If they differ, warn that line numbers may be stale. Use git log --oneline <git_ref>..HEAD -- <file> to see whether the mapped file changed. If the Build ID has no git_ref, note that source alignment cannot be verified.
  5. Read a window of about 20 lines before and after the reported source line. Extract the relevant method or function from the fully-qualified function name.

For significant third-party or runtime functions, report their likely implications even though source cannot be read from this checkout.

Step 7: Deliver analysis

Present a structured report with these sections:

Summary

Give a two- to three-sentence overview of the profile.

Top Hot Functions

Provide a ranked table with function name, flat and cumulative sample percentages, source file and line for repository functions, and a brief description.

Source Code Analysis

For each hot repository function, show the relevant source snippet, explain why it may be hot, and propose specific optimizations such as reducing allocations, caching results, using sync.Pool, or reducing lock contention.

Recommendations

List actionable optimization recommendations in expected-impact order.

Error Handling

  • If profilecli is missing, direct the user to https://github.com/grafana/pyroscope/releases/latest.
  • For connection errors, verify PROFILECLI_URL and network access.
  • For 401 or 403 errors, verify PROFILECLI_TOKEN and PROFILECLI_TENANT_ID.
  • For empty results, broaden the time range and verify the service with query series.
  • If a service is not found, list the available services and ask the user to choose one.
dallo stesso repository

Altri Skills

Tutti gli Skills
grafana
Community

alerting-irm

Configure Grafana Alerting, Incident Response Management (IRM), and SLOs end-to-end — provisions Grafana-managed and data-source-managed alert rules, contact points (Slack/PagerDuty/email/webhook), notification policies with hierarchical matchers, silences, mute timings, on-call schedules and escalation chains, incident-management integrations, and SLOs with multi-window burn-rate alerts. Use when configuring alerts, debugging notification routing, setting up on-call rotations, declaring or managing incidents, defining SLOs, provisioning alerting via YAML or API, picking matchers for a notification policy, building a PagerDuty/Slack webhook receiver, or troubleshooting why an alert isn't firing — even when the user says "page me on errors", "alert me when X happens", "route this to the platform team", or "set up an SLO" without naming Alerting or IRM.

installazioni
4
GitHub Stars
263
Aggiornato
18 set
grafana
Community

alloy

Build a unified telemetry pipeline with Grafana Alloy — one OpenTelemetry-compatible binary that collects metrics, logs, traces, and profiles and ships to Grafana Cloud / Prometheus / Loki / Tempo / Pyroscope. Covers the Alloy config language (blocks, sys.env, component refs), prometheus.scrape → remotewrite, loki.source.file + loki.process → loki.write, otelcol.receiver.otlp → otelcol.exporter.otlp, pyroscope.scrape, K8s / Docker / EC2 discovery, relabeling, modules (import.file/git/http), clustering, Fleet Management remotecfg, the Alloy UI at :12345, and alloy fmt / alloy validate. Use when writing a config.alloy, replacing Grafana Agent / OTel Collector, scraping K8s pods, parsing logs, ingesting OTLP, or debugging "Alloy isn't sending anything" — even when the user says "set up the agent", "write me a scrape config", "drop these logs before sending", or "OTel collector config" without naming Alloy.

installazioni
3
GitHub Stars
263
Aggiornato
18 set
grafana
Community

beyla

Auto-instrument an application's HTTP / gRPC / DB traffic with Grafana Beyla eBPF — no code changes, no SDK, no restart. Covers requirements (Linux 5.8+ with BTF, CAPSYSADMIN, host PID), language matrix (Go / Java / Python / Ruby / Node / .NET / Rust / C++ / PHP), Docker + Helm + DaemonSet install, port- / process- / Kubernetes-metadata discovery, OTLP traces + Prometheus metrics export, routes decorator (cardinality control), trace sampling, and Grafana Cloud via Alloy. Use when adding observability to a service you can't recompile, instrumenting a closed-source binary, getting RED metrics + spans onto Tempo/Mimir without touching the app, or rolling Beyla as a cluster-wide DaemonSet — even when the user says "zero-code APM", "instrument legacy app", "trace this binary", "eBPF observability", or "no SDK" without naming Beyla.

installazioni
3
GitHub Stars
263
Aggiornato
18 set
grafana
Community

datasources-provisioning

Generate a copy-paste Grafana data source provisioning file (YAML or Terraform) for any plugin from its standardized settings schema on the plugins CDN. Use when the user wants to provision or configure a data source as code — e.g. "provision infinity", "datasource yaml for clickhouse", "terraform for the github datasource" — even when they only name the plugin and not the word "provisioning".

installazioni
3
GitHub Stars
263
Aggiornato
18 set