wu-sheng opened a new pull request, #873: URL: https://github.com/apache/skywalking-website/pull/873
Part 9 of the **Meet Horizon UI** series — SkyWalking's five profilers and how Horizon surfaces them. ### Content - **The headline:** four of the five profilers (Trace, Async/JVM, eBPF, Go pprof) normalize to one stack shape and render through **one shared flame-graph component**; the **Tree** stack-table toggle is available on Trace + eBPF. - **What each catches** — the per-profiler task models: Trace (slow-segment sampling), Async (async-profiler events), eBPF (ON_CPU/OFF_CPU via Rover), pprof (one Go event per task). - **Network Profiling — the deliberate exception:** no flame graph; a process **honeycomb** with protocol-colored edges and sampling-rule tasks, sharing the 3D map's process-relation data. - **One task model, two permissions:** the `profile:enable` (create) vs `profile:read` (view) split, and per-layer tab availability gated on OAP-reported support. ### Figures (4, WebP) 1. The shared flame graph (hover card: signature / dump count / duration ± children / % of root) 2. The same result as a **Tree** stack table — one toggle away (the "one renderer, two views" pair) 3. The **pprof** tab — one Go event per task (GOROUTINE / MUTEX / CPU as separate tasks, each with its own duration + rate) 4. The **network honeycomb** — in-pod processes inside the dashed pod boundary, external peers ringing it, protocol-colored edges Prose cross-checked against the 0.7.0 render code + CHANGELOG; doc handoff links the real `operate/profiling` page. Dated 2026-06-26. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
