Supported Languages
This document provides language-specific details for Continuous Profiling, including supported runtime versions and symbolization behavior across different runtimes.
Go
Go executables are fully supported out of the box and are symbolized automatically without any additional configuration or setup.
Rust
Rust binaries are profiled by the OpenTelemetry eBPF profiler out of the box, with no runtime version limitations and no required compiler flags or special configuration.
Symbolization
To see fully symbolized stack traces (function names and line numbers), upload Rust debug symbols to Coralogix. This is required even if the binary itself was built with debug information. Symbol files can be uploaded using the Coralogix symbol upload tool.
Compiling with debug symbols
To generate debug symbols, configure the debug setting in your Cargo.toml file The value must be higher than line-tables-only:
Uploading symbols
As part of your CI pipeline, compile the binary with debug symbols and upload them to Coralogix:
After uploading, you may deploy the same binary to production with debug symbols included. While this increases the binary size, it does not impact application performance.
In case you want to remove the debug symbols from the binary after uploading them to Coralogix, use either strip or objcopy tool:
Note
You cannot run two separate builds—one development build with debug symbols and another production build without them—and upload symbols only from the development build to Coralogix. These builds produce different binaries with different function addresses and GNU build IDs, which prevents correct symbolization.
JVM
Symbols for JVM Languages (for example, Java, Scala, Kotlin) are supported out of the box without any additional configuration or setup.
Supported versions
JDK7 - JDK25
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
- Node.js is fully supported only on AMD64.
- ARM64 is supported from Node.js 16.0.0 and later.
- Symbols for Node.js are supported out of the box without any additional configuration or setup.
Supported versions
Node.js 12.x - 23.x
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 note useful for profiling analysis.
Known limitations
Profiling async functions
Like most Node.js CPU profilers, 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
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
Python applications work out of the box with OpenTelemetry eBPF profiler.
Supported versions
Python 3.6 - Python 3.13
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.
