OpenResty XRay profiles your application language, underlying system libraries, and the kernel in a single call stack. Below is the full tech stack support matrix with analysis depth annotated for each stack.
Request a Demo| Tech Stack | CPU Flame Graphs | Memory Analysis | More |
|---|---|---|---|
| LuaJIT / Lua (OpenResty, Nginx, Kong) | SupportedIncl. Lua↔C mixed stacks | Reference-chain level — GC object references, allocation paths | Related posts → |
| C / C++ | SupportedDown to source line | Allocator level — leak detection, memory fragmentation | Related posts → |
| Rust | Supported | Allocator level | Related posts → |
| Java | Supported | Reference-chain level — GC reference analysis with no stop-the-world pauses | Related posts → |
| Go | Supported | Reference-chain level | Related posts → |
| Python | SupportedDeep into interpreter internals | Reference-chain level | Related posts → |
| Node.js | Supported | Reference-chain level | Related posts → |
| PHP | Supported | Reference-chain level | Related posts → |
| Erlang | Supported | Workload-dependent † | Related posts → |
| Perl | Supported | Reference-chain level | Related posts → |
| Ruby | Supported | Workload-dependent † | — |
| OS Kernel | SupportedDedicated kernel flame graphs | Network stack, process scheduler, syscall analysis | Related posts → |
Reference-chain level = OpenResty XRay walks GC object reference graphs, pinpoints which object is holding the leaked memory, and provides the allocation code path. Allocator level = leak detection, fragmentation, and allocator behavior analysis without object reference chains — the former locates "which object is retaining memory that should have been freed," while the latter detects "total memory is growing continuously."
Erlang and Ruby are fully supported for CPU profiling. Memory analysis depth depends on the specific workload and runtime version. Tell us about your stack and we will clarify the exact analysis depth achievable for your environment before deployment.
OpenResty XRay attaches externally to running processes — no code changes, no restarts, no library preloading. Each sample unwinds and symbolizes across all three layers, producing a single, continuous call stack.
OpenResty XRay directly parses the internal data structures of the runtime itself — LuaJIT, CPython, JVM, Go, PHP, Node.js, Erlang, Perl, Ruby — resolving your source files and line numbers instead of only showing the interpreter's native C function frames.
C, C++, and Rust frames — Nginx, OpenSSL, glibc, and your own modules — are symbolized even for stripped production binaries, using the central symbol store.
The scheduler, network stack, memory management, and syscalls appear in the same call stack, so off-CPU time blocked in the kernel can be attributed back to the application code that initiated the wait.
pkey_rsa_decrypt in libcrypto was consuming nearly half a core. OpenResty XRay traced the call path through the JWT library all the way back to line 93 of a Lua plugin — a cross-language call chain that perf cannot surface.
The JVM heap kept growing after multiple full GC cycles. OpenResty XRay walked the GC object reference chain on the live JVM, pinpointing the data structure holding the memory — no heap dump required, no stop-the-world pause.
Read the diagnosis →During a production incident at Bilibili, all worker processes hit 100% CPU. The analysis was performed directly against the live processes during the incident, not in a post-mortem reproduction environment.
Read the incident report →No. For packages from mainstream distributions, OpenResty XRay resolves symbols from its central package database. For self-compiled open-source software and your own proprietary binaries, the agent automatically indexes the debug symbols it finds on any machine where they are installed, so they never need to stay on your production servers. Your production builds stay untouched.
Yes. Every sample produces a call stack that is unwound and symbolized across all three layers, so a single flame graph contains your application frames, the C frames beneath them, and the kernel frames below that. This is why a CPU-intensive C function can be attributed back to the exact line of application code that called it.
The OpenResty XRay Agent runs on the host as a standalone daemon with root privileges. Your application processes are never modified: no code injection, no library preloading, no restarts. When no analysis task is running, there is zero contact with the application process. Linux servers only; in containerized environments, the Agent on the host can profile processes in any container on that host.
Tell us about your stack and we will clarify the exact analysis depth achievable for your environment before deployment.
Request a DemoWe use cookie to make your experience better. By clicking 'I agree' or continuing to use this website you're giving permission for cookies to be stored.
Learn more.