議論： 本番環境での継続的プロファイリング: 常時稼働のサンプリングプロファイルが何に答えるか

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'.