Continuous Profiling

Find the code path behind production latency

Guance Continuous Profiling samples CPU, memory allocation, locks, I/O, slow queries, and function calls in production. Developers can move from a slow APM span to the flame graph and runtime evidence that explains which method, thread, or resource is responsible.

Find the code path behind production latency

What Continuous Profiling helps you solve

When a trace shows where latency accumulated, profiling explains why

A trace can isolate a slow service or span without exposing the inefficient code underneath. Guance adds sampled runtime evidence so teams can compare function calls, CPU, allocations, locks, I/O, and queries for the same service, version, and time window.

A request is slow, but the trace stops at service time. Continue into the code
Use sampled profiles to identify expensive function calls, CPU work, memory allocation, lock contention, slow queries, and I/O waits behind a production regression. This narrows “the endpoint is slow” to a method or runtime behavior an engineer can change.
View documentation
A request is slow, but the trace stops at service time. Continue into the code
Use flame graphs to compare CPU, memory, locks, and I/O
Use flame graphs to compare CPU, memory, locks, and I/O
Inspect call stacks and relative resource use at method level, then segment the evidence by language, service, version, host, and time window. Teams can prioritize the code path that consumes real production resources instead of optimizing from intuition.
View documentation
Move from an affected span to the matching profile window
Correlate an APM span with profile data from the same service and period. Compare hotspots, call stacks, and resource use to determine whether latency comes from business logic, a dependency, runtime contention, or an expensive query.
View documentation
Move from an affected span to the matching profile window

Frequently asked questions

What is Continuous Profiling?

Continuous Profiling samples how production code uses CPU, memory, locks, I/O, queries, and function calls over time. It helps teams find code-level performance bottlenecks that aggregate service metrics and traces may not explain.

How is profiling different from an APM trace?

An APM trace shows how a request moves through services and how long each span took. A profile shows what the code and runtime were doing, such as CPU work, allocations, locks, I/O, and function calls, during the relevant period.

Which issues can production profiling help investigate?

Common investigations include slow endpoints, high CPU, unexpected allocation, memory pressure, lock contention, I/O waits, slow queries, and performance regressions after a release.

Can Guance correlate profiles with traces?

Yes. Guance supports trace-to-profile analysis for documented runtimes and configurations, helping teams move from an affected span to code hotspots in the corresponding service and time window.

Connect code-level evidence to application and runtime context

Explore APM, logs, OpenTelemetry, observability guides, documentation, and pricing.

Get started > View documentation > View pricing >