base on The production-scale datacenter profiler (C/C++, Go, Rust, Python, Java, NodeJS, .NET, PHP, Ruby, Perl, ...) # Introduction This repository implements a whole-system, cross-language profiler for Linux via eBPF. ## Core features and strengths - Implements the [experimental OTel profiling signal](https://github.com/open-telemetry/opentelemetry-proto/pull/534) - Very low CPU and memory overhead (1% CPU and 250MB memory are our upper limits in testing and the agent typically manages to stay way below that) - Support for native C/C++ executables without the need for DWARF debug information (by leveraging `.eh_frame` data as described in [US11604718B1](https://patents.google.com/patent/US11604718B1/en?inventor=thomas+dullien&oq=thomas+dullien)) - Support profiling of system libraries **without frame pointers** and **without debug symbols on the host**. - Support for mixed stacktraces between runtimes - stacktraces go from Kernel space through unmodified system libraries all the way into high-level languages. - Support for native code (C/C++, Rust, Zig, Go, etc. without debug symbols on host) - Support for a broad set of HLLs (Hotspot JVM, Python, Ruby, PHP, Node.JS, V8, Perl), .NET is in preparation. - 100% non-intrusive: there's no need to load agents or libraries into the processes that are being profiled. - No need for any reconfiguration, instrumentation or restarts of HLL interpreters and VMs: the agent supports unwinding each of the supported languages in the default configuration. - ARM64 support for all unwinders except NodeJS. - Support for native `inline frames`, which provide insights into compiler optimizations and offer a higher precision of function call chains. ## Building We are working towards integrating the profiling functionality into the [OTel Collector](https://opentelemetry.io/docs/collector/) as a receiver, which will be the supported configuration going forward. In the meantime, we also offer a standalone profiling agent binary named `ebpf-profiler`, to aid with development and debugging. The expectation is that this will go away once the integration with the [OTel Collector](https://opentelemetry.io/docs/collector/) is complete. ## Platform Requirements The agent can be built with the provided make targets. Docker is required for containerized builds, and both amd64 and arm64 architectures are supported. For **Linux**, the following steps apply: 1. Build the agent for your current machine's architecture: ```sh make agent ``` Or `make debug-agent` for debug build. 2. To cross-compile for a different architecture (e.g. arm64): ```sh make agent TARGET_ARCH=arm64 ``` The resulting binary will be named `ebpf-profiler` in the current directory. ## Other OSes Since the profiler is Linux-only, macOS and Windows users need to set up a Linux VM to build and run the agent. Ensure the appropriate architecture is specified if using cross-compilation. Use the same make targets as above after the Linux environment is configured in the VM. ## Supported Linux kernel version [7ddc23ea](https://github.com/open-telemetry/opentelemetry-ebpf-profiler/commit/7ddc23ea135a2e00fffc17850ab90534e9b63108) is the last commit with support for 4.19. Changes after this commit may require a minimal Linux kernel version of 5.4. ## Alternative Build (Without Docker) You can build the agent without Docker by directly installing the dependencies listed in the Dockerfile. Once dependencies are set up, simply run: ```sh make ``` or ```sh make debug ``` This will build the profiler natively on your machine. ## Running You can start the agent with the following command: ```sh sudo ./ebpf-profiler -collection-agent=127.0.0.1:11000 -disable-tls ``` The agent comes with a functional but work-in-progress / evolving implementation of the recently released OTel profiling [signal](https://github.com/open-telemetry/opentelemetry-proto/pull/534). The agent loads the eBPF program and its maps, starts unwinding and reports captured traces to the backend. ## Development To understand how this project works and learn more about profiling, check out [Profiling internals](doc/internals.md) # Legal ## Licensing Information This project is licensed under the Apache License 2.0 (Apache-2.0). [Apache License 2.0](LICENSE) The eBPF source code is licensed under the GPL 2.0 license. [GPL 2.0](support/ebpf/LICENSE) ## Licenses of dependencies To display a summary of the dependencies' licenses: ```sh make legal ``` ", Assign "at most 3 tags" to the expected json: {"id":"9369","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"