Supported runtimes

To get symbolized Rust stack traces, compile with debug symbols and upload them to Coralogix. In your Cargo.toml, set the debug profile setting to a value higher than line-tables-only:

[profile.release]
debug = "full"

For the upload workflow (CLI install, build-ID pairing, dynamic libraries), see Upload debug symbols.

C and C++ binaries are profiled by the OpenTelemetry eBPF profiler. Because they compile to Native machine code, you must upload debug symbols to Coralogix to see fully symbolized stack traces. Symbol files can be uploaded using the Coralogix symbol upload tool.

Zig binaries are profiled by the OpenTelemetry eBPF profiler. As a Natively compiled language, Zig requires debug symbols to be uploaded to Coralogix for fully symbolized stack traces. Symbol files can be uploaded using the Coralogix symbol upload tool.

Symbols for JVM languages (for example, Java, Scala, Kotlin) are supported out of the box without any additional configuration or setup.

JVM frames

Most JVM services start with a few unsymbolized frames like the example below. These frames belong to the JVM runtime itself and typically are not useful for profiling analysis.

Node.js is fully supported on AMD64 across the entire version range above. On ARM64, support starts at Node.js 16.0.0. Symbols for Node.js are supported out of the box without any additional configuration or setup.

Node.js frames

Most Node.js services start with a few unsymbolized frames like the example below. These frames belong to the Node.js runtime itself and typically are not useful for profiling analysis.

Known limitations

Profiling async functions

Like most Node.js CPU profilers, the OpenTelemetry eBPF profiler has limitations when profiling asynchronous functions. Reconstructing asynchronous call stacks requires accessing the Node.js (V8) heap, which introduces significant overhead. As a result, asynchronous call stacks are currently recorded separately, without reconstructing the full end-to-end call stack.

Troubleshooting

Named anonymous functions appear as <anonymous> with ESBuild

When using ESBuild to bundle your Node.js application, named anonymous functions might appear as <anonymous> in the profiling data instead of their actual names. This happens when using the keepNames option in ESBuild, which doesn't correctly reset the function names of anonymous (arrow) functions after minification.

Python applications work out of the box with the OpenTelemetry eBPF profiler.

Python frames

Most Python services start with a few unsymbolized frames like the example below. These frames belong to the Python runtime itself and typically are not useful for profiling analysis.