Skip to content
Start free

Find the code that burns your CPU

The collector's eBPF profiler samples every process on your Linux hosts and Kubernetes nodes, with no code changes or restarts. Explore flame graphs, top functions and stack traces for the whole fleet or one service, and compare any window with the one before it.

Start freeBook a demoRead the profiling docs
  • eBPF on Linux · no code changes
  • pprof scrape or push
  • CPU profiles

How it works

From one policy setting to a fleet-wide flame graph

Profiles are sampled time on the CPU, attributed to the host, process, container and service that spent it.

  1. 01Turn it onAdd the profiling integration to a Linux collector policy. No second agent and no restarts.
  2. 02SampleThe eBPF profiler samples each CPU 20 times a second by default, from kernel and native frames to the runtime.
  3. 03AttributeSamples carry the host, executable, container and thread, and in Kubernetes the service of the pod.
  4. 04ExploreRead stack traces, a flame graph or top functions, filtered by service, host, executable, container or thread.
  5. 05CompareCompare any window with the one before it to see which functions gained or lost CPU.
  6. 06Add other platformsScrape pprof endpoints, or push pprof files from CI jobs and hosts the profiler cannot run on.

Top functions

Rank your code by the CPU it uses

The functions view ranks every function across the fleet by the samples it holds itself and with everything it calls. Turn on the comparison and each row shows how far it moved since the previous period.

  • The flame graph shades each frame by whether it used more or less CPU than in the previous period
  • Each function shows an estimated annual cost and CO2, from per-core factors you can change for one host
  • Search by function, file or executable, then open the match in the flame graph

Collection

Profiling without touching your code

The profiler is the OpenTelemetry eBPF profiler, built into the Tracix Collector. It runs on Linux hosts and Kubernetes nodes, and pprof profiles from other platforms land in the same views.

  • Whole system

    Every process on the host, with kernel, native and Go frames and the JVM, Python, Node.js and .NET runtimes.

  • Kubernetes aware

    Samples map to pods by container ID, then to the service the pod declares or the workload it belongs to.

  • pprof scrape

    Pull CPU profiles from Go's /debug/pprof, async-profiler or py-spy, every 60 seconds by default.

  • pprof push

    Post pprof or collapsed stacks to the collector from CI jobs and air-gapped hosts.

Breakdowns

See which service, host or thread spends the CPU

Stack traces group the samples by thread, host, service, container or executable over time, and any group opens as a flame graph. Samples with no declared service stay unattributed, so nothing is credited to the wrong team.

  • Each service's page in APM has a Profiles tab scoped to the pods it runs in
  • A span in a trace opens its host's flame graph, top functions and stack traces
  • Known Linux idle threads are left out unless you choose to include them

Better together

CPU time, next to the request that spent it

Profiles share a workspace with your traces, pods and software inventory, so a hot function is one click from the service, node and package behind it.

Profile sources

Three ways CPU profiles reach Tracix

All three land in the same flame graphs, functions and stack traces, on the same time range and filters.

SourceRuns onWhat it profilesService name from
eBPF profilerLinux hosts and Kubernetes nodesEvery process on the hostThe pod in Kubernetes, or the declared service.name
pprof scrapeAny endpoint the collector can reachOne target, such as Go's /debug/pprofThe name you give the target
pprof pushAnything that can reach the collectorUploaded pprof files or collapsed stacksThe service in the upload

Profiles are CPU samples only. Shares describe sampled time on the CPU, not host utilization, and cost and CO2 are estimates.

FAQ

Questions developers ask first

Talk to an engineer
Does Tracix profile memory or allocations?
No. Tracix collects and stores CPU profiles only. Heap use, allocations, lock contention and time spent off the CPU are not profiled today.
Which platforms can be profiled?
The eBPF profiler runs on Linux hosts and Kubernetes nodes. On other platforms, expose a pprof endpoint for the collector to scrape, or push pprof files to it.
Which runtimes show their own frames?
Native code, the kernel and Go, plus the JVM, .NET, Python, Node.js, Ruby, PHP and Perl through the profiler's interpreter support. Some interpreter builds are not unwound yet, such as Node.js and Python on Alpine images, so their samples show native frames only.
How are the cost and CO2 figures worked out?
They are estimates. Tracix annualizes sampled CPU time with standard per-core factors for power, data center efficiency, carbon intensity and cost per core-hour. You can change the factors in your browser, for the fleet or for one host.

See your first flame graph in minutes

Turn on profiling in a Linux collector policy, and the first samples arrive within about a minute.

Start freeRead the profiling guide