Documentation forAppOptics

Code profiling (legacy agent)

The following content pertains to code profiling for the legacy AppOptics Java Agent.

AppOptics agents are no long receiving updates. The new SolarWinds Observability libraries can send APM data in AppOptics and are regularly updated with new features and improvements. If you are still relying on the AppOptics agents and your components are supported by the new libraries, consider transitioning to the SolarWinds Observability libraries for your APM needs. For more information about the benefits of migrating to the SolarWinds Observability libraries. Alternatively, you can use SolarWinds Observability as your primary APM solution.

If you have already transitioned to the new SolarWinds Observability Java Library, see the SolarWinds Java Library documentation for code profiling information.

SolarWinds Observability libraries are not compatible with AppOptics agents. Do not use a mix of SolarWinds Observability libraries and AppOptics agents to instrument applications that are part of a distributed trace.

Code profiling provides extra insight into code level execution time that is otherwise not captured by auto-instrumentation. See code profiling for general information.

AppOptics Java agent version 6.8.0 or later is required for code profiling.

What profiling information is collected by the Java agent?

  • Currently only traced Servlet requests and SDK initiated traces are profiled. The frequency breakdown is based on the main handling thread hence asynchronous operation is not captured, nor would a non-blocking entry point such as Akka HTTP or Netty generate profiling information.
  • Profiling information has granularity base on profiling interval (default is 20ms), and is configurable in profiler settings.
  • Java class name, method name, base file name and line number will be collected. However, native method calls do not have line number.
  • By default low-level java libraries are excluded (package "java", "javax", "com.sun" etc). This could be changed in profiler settings.

Why don't all traces have profiling information?

  • Profiler is disabled by default, please refer to enabling code profiling.
  • Traces with duration shorter than the configured profiling interval (default is 20ms) might not have profiling information.
  • Traces are not servlet based nor SDK initiated.
  • Profiles might be omitted if the profiling circuit breaker (more below) is triggered. When triggered, the agent would print INFO level log message similar to:
    Pause profiling for ... secs. Previous profiling operation took ... ms. That's total of ... consecutive profiling operation(s) that exceeded the circuit breaker duration threshold ... ms

What are the overhead concerns?

  • Overhead might be more noticeable in systems with high number of threads. To reduce overhead, increase code profiling interval such that the agent would take snapshots less frequently.
  • A circuit breaker is in place to prevent extra overhead when the JVM is under heavy load. Profiling will be paused when system load is too high.

What is the "Unknown" path shown in the profiles?

  • "Unknown" accounts for occasions where the agent failed to obtain snapshots on the given interval. Various conditions can trigger missing snapshots, for example long Garbage Collection operation or high CPU load.