ptrace is too low level and will freeze your process. it cant be used for production debugging i feel. we work at the application layer by hooking into product

ptrace is too low level and will freeze your process. it cant be used for production debugging i feel. we work at the application layer by hooking into production grade tooling if available (inspector in v8, sys.monitoring in python) or bytecode manipulation(jvm) since we arent controlling the application for a different process, we dont need to freeze the app to get the current app state requirements we had in mind in order of importance 1. safety -> user app needs to function as usual no matter what happens, there shouldnt be an error in the user's app because of us 2. zero idle footprint -> if no probe is active, cpu/memory differency in the user app should be immeasurable 3. zero latency footprint at non probe paths while other probes are active 4. measure mem/cpu footprint directly or via a proxy like eventloop lag and have guardrails around it. suspend probes or even lose snapshot data if guardrail conditions meet 5. minimal mem/cpu footprint for active probes 6. minimal latency foot print for active probe paths