pyroscope

用途

Grafana Pyroscope 是一个开源、可水平扩展、高可用、多租户的持续性能分析（continuous profiling）平台，用于在代码级别分析应用性能。它持续采集性能剖析数据，开销较低（约 2-5% CPU），提供源代码行级别的可见性，并将压缩后的剖析数据存储到对象存储中，同时可与 Grafana 集成，把剖析数据与指标、日志和链路追踪关联起来。

主要能力

持续采集剖析数据，开销约 2-5% CPU。
提供源代码行级别的代码可见性。
将压缩后的剖析数据存储到对象存储（S3、GCS、Azure Blob）。
与 Grafana 集成，可将剖析数据与指标、日志、链路追踪关联。
支持多种语言：Go、Java、Python、.NET、Ruby、Node.js、Rust。

支持的剖析类型包括：CPU（所有语言）、内存（Go、Java、.NET）、Goroutine（Go）、Mutex（Go、Java、.NET）、Block（Go）、Exceptions（Python）。

架构

核心组件：

Distributor：校验并将传入的剖析数据路由到 ingester。
Ingester：在内存中缓冲剖析数据，压缩后写入存储。
Querier：检索并处理剖析数据以供分析。
Query Frontend：处理查询请求、缓存与调度。
Query Scheduler：管理按租户的查询队列。
Store Gateway：提供对长期剖析存储的访问。
Compactor：合并块、管理保留期、处理删除。

写入路径：SDK/Alloy → Distributor → Ingester → 对象存储（Blocks + Indexes）。

读取路径：Query → Query Frontend → Query Scheduler → Querier → Ingesters + Store Gateway。

部署模式

单体模式（-target=all）：所有组件在单个进程中运行，适合开发和小规模部署，查询 URL 为 http://pyroscope:4040/。
微服务模式（生产）：各组件独立运行，可水平扩展，查询 URL 为 http://pyroscope-querier:4040/。

使用方式

Kubernetes Helm 快速开始

添加仓库：

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

安装单二进制：

kubectl create namespace pyroscope
helm install pyroscope grafana/pyroscope -n pyroscope

安装微服务模式：

curl -Lo values-micro-services.yaml \
  https://raw.githubusercontent.com/grafana/pyroscope/main/operations/pyroscope/helm/pyroscope/values-micro-services.yaml

helm install pyroscope grafana/pyroscope \
  -n pyroscope \
  --values values-micro-services.yaml

客户端接入方式

方式一：SDK 埋点（推送模式），提供 Go、Java、Python 等 SDK 示例。

方式二：Grafana Alloy（拉取模式），通过注解自动埋点，并提供 Alloy 配置示例。

方式三：eBPF 剖析（Linux），适用于编译型语言（C/C++、Go、Rust）。

存储配置

支持 Azure Blob Storage、AWS S3、Google Cloud Storage，均提供对应配置示例。

Grafana 集成

提供数据源配置示例，并支持 Trace-to-Profile 关联（span profiles），要求最小 span 时长 20ms，支持 Go、Java、.NET、Python、Ruby。

API 端点

写入：POST /push.v1.PusherService/Push、POST /ingest。
查询：SelectMergeProfile、SelectMergeStacktraces、LabelNames、ProfileTypes、GET /pyroscope/render。
系统：GET /ready、GET /config、GET /metrics。

适用场景

适用于需要在代码级别持续分析应用性能、将剖析数据与指标/日志/链路追踪关联、并在 Kubernetes 上部署持续性能分析平台的场景。

限制与注意事项

每个应用的剖析采样率：繁忙服务上 100Hz 会带来不可忽视的开销，建议先在金丝雀环境剖析。
存储压缩在合并期间会阻塞新写入，大型压缩会导致写入停顿，需要调整块大小和压缩窗口。
标签基数爆炸：按请求打标签会使存储膨胀，需显式限制标签值。
链路集成：span → profile 关联需要端到端匹配 traceparent 头传播，任一环节未埋点会静默丢失关联。
eBPF 剖析器与 SDK 剖析器归因方式不同，有时会冲突，不要对同一服务同时运行两者。
gRPC 与 HTTP 推送：数据相同，但 ingester 处的速率限制不同，HTTP 推送在高负载下被限流更严格。

资源需求、常见 Helm values、故障排查命令等详见资料。