持续剖析：Pyroscope、Parca 与生产环境低开销采样

指标（Metrics）：聚合数字，便宜、适合告警，但丢失个体信息
链路（Traces）：单次请求的路径与耗时，能定位到服务/函数，但采样稀疏
日志（Logs）：离散事件，信息全但成本高、无聚合视图
剖析（Profiles）：调用栈聚合，能定位到函数与代码行，维度是"时间"

偶发剖析（Ad-hoc）：出问题时手动开 pprof → 问题往往已消失、无法复现
持续剖析：常驻低采样 → 任意时刻可回溯，故障窗口的栈被保留
关键差异：持续剖析让"上周三 14:23 那波 CPU 尖刺"变得可查

CPU 优化：发现热点函数，去掉无谓的 JSON 序列化 / 正则回溯
内存排查：区分真实泄漏与缓存膨胀，定位分配点
成本优化：把 CPU 密集逻辑改对，直接降机器成本
回归检测：版本间火焰图差异对比，发现新引入的热点

采样剖析（Sampling）：
  周期性中断/信号，抓取当前调用栈，按次数估算耗时占比
  开销极低（1~5%），无需改代码，统计意义足够

插桩剖析（Instrumentation）：
  在每个函数入口/出口打点，精确计数
  开销高、需改代码或重编译，生产慎用

Go：runtime/pprof 通过 SIGPROF 定时采样，天然支持
Java：JFR（JDK Flight Recorder）或 async-profiler
eBPF：perf_event_open + bpf_get_stackid，跨语言统一

采集到的是"地址序列"，需要符号化才能变成函数名：
  - 有调试信息（DWARF）→ 解析出函数/行号
  - 无符号 → 显示为 0x7f... ，需要保留 .debug 或上传符号表
聚合模型：{(stack_id, labels)} → 采样计数
  stack_id 去重存储，labels 承载 service/pod/version 等维度

Agent（SDK / ebpf-agent）：在进程内或宿主机侧采集栈
Server：接收、存储、查询 profile
Store：块存储（本地磁盘或对象存储 S3/MinIO）
UI：火焰图展示与标签筛选

helm repo add pyroscope-io https://pyroscope-io.github.io/helm-chart
helm install pyroscope pyroscope-io/pyroscope \
  --set pyroscope.structuredConfig.storage.backend=s3 \
  --set pyroscope.structuredConfig.storage.s3.bucketName=pyroscope-data \
  --set pyroscope.structuredConfig.storage.s3.endpoint=minio.observability:9000

import "github.com/grafana/pyroscope-go"

pyroscope.Start(pyroscope.Config{
    ApplicationName: "checkout-service",
    ServerAddress:   "http://pyroscope.observability:4040",
    ProfileTypes: []pyroscope.ProfileType{
        pyroscope.ProfileCPU,
        pyroscope.ProfileAllocObjects,
        pyroscope.ProfileInuseSpace,
        pyroscope.ProfileGoroutines,
    },
    Logger: pyroscope.StandardLogger,
    Tags:   map[string]string{"env": "prod", "region": "cn-hangzhou"},
})

必须携带的标签（否则无法下钻）：
  service_name      服务名（与指标、链路对齐）
  env               环境（prod/staging）
  version           版本号（做版本间差异对比）
  region / zone     地域（定位区域性差异）
  pod / instance    实例（定位单实例异常）

标签基数控制：不要塞 request_id / user_id，会爆炸

Parca = 无侵入持续剖析平台
核心组件：
  parca-agent   基于 eBPF 的采集器，宿主机级部署，无需改代码
  parca         服务端，兼容 pprof 格式，原生对接 PromQL 生态
优势：语言无关（Go/Java/C++/Rust/Python 统一），零代码改动
代价：依赖内核版本（建议 5.4+），符号化需要栈展开能力

1. 需要特权容器或 hostPID + CAP_BPF/CAP_PERFMON
2. 内核版本：5.4+ 稳定，5.10+ 支持更好
3. 符号表：容器内二进制需保留 DWARF，或用 debuginfod 拉取
4. 采样频率：默认 19Hz，调高更精细但 CPU 开销线性上升
5. 内存：agent 每个被追踪进程有栈缓存，注意上限

# parca-agent DaemonSet 关键片段
spec:
  containers:
  - name: parca-agent
    securityContext:
      privileged: true
      readOnlyRootFilesystem: true
    args:
    - --node=my-node
    - --remote-store-address=parca.observability:7070
    - --profiling-cpu-sampling-frequency=19

横轴 = 采样占比（不是时间顺序！）
纵轴 = 调用栈深度（从下到上：main → ... → 叶子函数）
宽度 = 该函数及其子调用消耗的资源占比

读图三问：
  1. 哪个"宽块"最宽？→ 热点函数
  2. 它的父调用是谁？→ 谁在调用它
  3. 叶子节点是什么？→ 真正消耗资源的地方

对比两个版本 / 两个时间窗口：
  红色 = 新版本新增的开销（回归）
  蓝色 = 新版本减少的开销（优化）
  无色 = 无变化

典型用途：
  发布后对比 → 立刻发现"这个版本多了 15% 的 JSON 解析"
  时间对比 → 定位"昨晚开始 CPU 上涨"的引入点

宽而深的"平顶山"：单函数自耗高 → 算法问题
大量窄条重复出现：循环内调用 → 批量优化机会
意外的序列化栈：如 encoding/json.Marshal 占比高 → 换更快的库
锁等待栈：sync.(*Mutex).Lock 占比高 → 锁竞争
GC 栈：runtime.gcBgMarkWorker 占比高 → 分配过多

场景：CPU 使用率告警 → 想看是哪段代码
做法：告警面板加"查看剖析"链接，带 service + 时间窗口参数
      Grafana 中通过 data link 跳转到 Pyroscope 面板
关键：标签（service_name / version / pod）必须在两侧完全一致

场景：某 trace 慢，想看它调用的服务在慢什么
做法：trace 详情里带上 service.name + 时间戳，
      跳转到对应服务的火焰图，时间窗口对齐到该请求前后
局限：剖析是聚合视图，无法精确到单次请求，但能定位热点

用途：日志里出现"GC pause 800ms"，去火焰图看 GC 栈占比
做法：日志时间戳与剖析时间窗口对齐，联合排查
注意：剖析数据有聚合延迟（通常 10~60s），不要期待秒级对齐

所有信号共用的标签集：
  service.name      服务标识（OTel 语义约定）
  service.version   版本
  deployment.environment  环境
  k8s.pod.name / k8s.node.name
只要标签一致，四类数据就能在 Grafana 中互相跳转

□ 默认开启常驻低采样剖析，不要等故障才开
□ 采样频率按语言与开销设定，Go 100Hz、eBPF 19Hz 起步
□ 标签与指标/链路严格对齐，禁用高基数标签
□ 容器镜像保留或单独上传符号表，保证可符号化
□ 发布后必做版本间差异火焰图对比
□ 同时采集 CPU、内存（alloc/inuse）、协程/线程剖析
□ 剖析面板加数据链接，支持从指标与链路一键跳转
□ 设定分层保留策略（近期高精度、长期降采样）
□ 监控剖析采集器自身开销，避免"观测影响被观测"
□ 建立"看火焰图"的排障习惯，纳入性能问题 SOP

持续剖析 = 常驻低采样 + 语言/eBPF 双通道 + 统一标签 +
火焰图与差异对比，让"代码哪里慢"随时可查。