What are Instrumentation exclude rules and why would you use them?

Instrumentation exclude rules tell an App Agent to skip applying byte-code instrumentation to specific classes, packages, or methods that would otherwise match its normal detection logic — effectively an opt-out list layered on top of automatic and configured instrumentation.

<exclude-classes>
  <class name="com.internal.legacy.HighVolumeCache"/>
  <package name="com.thirdparty.vendor.*"/>
</exclude-classes>

Teams reach for exclude rules in a few recurring situations: an extremely hot, high-call-volume internal method where instrumentation overhead measurably matters more than visibility into it; a vendor or legacy library whose bytecode is fragile or incompatible with instrumentation and causes startup errors; or simply a code path that produces noisy, low-value data cluttering transaction snapshots without helping anyone troubleshoot.

The trade-off is obvious but worth stating plainly: anything excluded becomes invisible to AppDynamics, so exclude rules should be scoped as narrowly as possible — excluding one problematic class is very different from excluding an entire package that happens to contain both the noisy method and several methods someone will eventually need visibility into.