inspectit-ocelot
inspectit-ocelot copied to clipboard
inspectIT
inspectIT Ocelot - Java agent for collecting application performance, tracing and behavior data
Changing an instrumentation rule without changing scopes forces retransformation of involved classes
In theory, a class only needs to be retransformed if (a) the special sensors changed or (b) a method got hooked or unhooked. A classes' bytecode does not need to...
We currently use javassists for turning action "code snipptes" to executable java classes. The built-in compielr has several issues, such as that no autoboxing is supported, no nested classes and...
Currently, the agent is using the `RuleTracingSettings ` class for storing the tracing settings which are being loaded. Unfortuently, the same class is also used for storing the resolved tracing...
**Is your feature request related to a problem? Please describe.** The configuration schema implemented for https://github.com/inspectIT/inspectit-ocelot/issues/1726 just supports code-completion for YAML/JSON. It would be awesome, if we could also get...
**Is your feature request related to a problem? Please describe.** The current concept of staging configurations in Git over multiple stages is quite complex and inconvenient. **Describe the solution you'd...
This issue tries to solve the problem that the number of rules can easily explode and be hard to manage. For example, for each combination of functionality (tracing, servicegraph, http-metrics)...
**Is your feature request related to a problem? Please describe.** Currently, it is not possible to use Java code snippets, which contain lambda expressions for actions. This is probably the...
As a result of discussions done in #556 we decided to ignore the replace regex for the data obfuscation. Any obfuscation simply returns `***` for now. We need to find...
At the moment we have a special sensor for the `ExecutorService` andoen for the `ScheduledExecutorService`. We could combine these two special sensors into a single one which accepts `scopes` as...
Currently we use `Thread.getAllStackTraces` for stack trace collection. This is done over `Thread.getStackTrace` because `Thread.getStackTrace` wopuld stop ALL threads anyway (safepoint). However, at least on OpenJDK and OracleJDK there is...