Supported runtimes
Coralogix Continuous Profiling supports a broad set of native and managed runtimes through the OpenTelemetry eBPF profiler. The matrix below summarizes supported versions and available profile types. Expand a language for symbolization details, runtime caveats, and troubleshooting.
Supported runtimes
| Language | Type | Versions | Profile types | Symbol upload | Notes |
|---|---|---|---|---|---|
| JVM (Java, Scala, Kotlin) | Managed | JDK 7 - JDK 25 | CPU, Memory | ❌ No | |
| Node.js | Managed | 14.x - 23.x | CPU, Memory | ❌ No | ARM64 requires Node 16+ |
| Python | Managed | 3.6 - 3.14 | CPU | ❌ No | |
| .NET | Managed | 6.0 - 10 | CPU | ❌ No | |
| Ruby | Managed | 2.5 - 4.0 | CPU | ❌ No | |
| PHP | Managed | 7.3 - 8.4 | CPU | ❌ No | |
| Perl | Managed | 5.28 - 5.42 | CPU | ❌ No | |
| Go | Native | — | CPU, Memory | ❌ No (embedded) | Memory via net/http/pprof scraping |
| Rust | Native | — | CPU | ✅ Yes | |
| C/C++ | Native | — | CPU | ✅ Yes | |
| Zig | Native | — | CPU | ✅ Yes |
Native binaries (Rust, C/C++, Zig) require debug symbols to be uploaded to Coralogix for human-readable stack traces — see Upload debug symbols. Go binaries embed their symbols and are symbolized automatically. Memory profiles are available for JVM services through the Async Profiler, for Node.js services through the Coralogix OpenTelemetry profiling SDK, and for Go services by scraping the runtime's net/http/pprof endpoints — see Monitor memory consumption.
Language-specific reference
Go binaries are profiled for CPU by the OpenTelemetry eBPF profiler and are symbolized automatically from the symbols embedded in the binary—no upload required.
Memory (heap) profiling uses a different path: the Go runtime's built-in heap profiler, exposed through the standard net/http/pprof endpoints and scraped by the Coralogix collector. See Set up memory profiling in Go services.
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.
CPU profiles are collected automatically by the eBPF profiler. Memory (heap) profiling requires the Coralogix OpenTelemetry profiling SDK — see Monitor memory consumption.
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.
Next steps
Learn how to visualize and analyze CPU usage across your services in Monitor CPU consumption.