토론: 프로덕션에서의 지속적 프로파일링: 상시 가동되는 샘플링 프로파일과 이를 통해 답할 수 있는 것

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

Two sources worth naming next to Go's endpoint. OpenTelemetry added profiles as a signal (an OTLP profiles data type, still marked development) and took over the eBPF profiler donated by Elastic, so the eBPF-agent path is converging on a vendor-neutral wire format; for interpreted and managed runtimes the sampling happens in-process instead (async-profiler and JFR on the JVM, py-spy from outside a Python process, the Pyroscope and Parca SDKs), with overheads that differ from the eBPF case and need the staging measurement the article asks for. For per-request attribution in Go, `pprof.Do(ctx, pprof.Labels("route", r), fn)` tags the samples taken inside `fn` with labels the profile stores, so a CPU profile can be sliced by route or tenant; Go's CPU profiler samples at 100 Hz by default (`runtime.SetCPUProfileRate`), which is the resolution behind 'short-lived processes and rare events are under-represented'.