Dynatrace AppMon 6.5 Documentation

Other Doc Versions & KB

Skip to end of metadata
Go to start of metadata

Define name patterns to match differently named Agents to a specific Agent Group.

The Agent name may be sufficient to assign an Agent to the Agent Group, but in some cases it may be useful to use, for example, the Agent's host to assign an Agent to an Agent Group.

To match agent names and host names, use starts, ends, contains, equals and also regex, to specify a Java-style regular expression that is evaluated against the Agent name to decide if the Agent matches this system profile.

How Agent Mapping Works

If a new AppMon Agent connects to the AppMon Server, all System Profiles are searched for matching Agent Mapping definitions. The following cases may occur:

No matching System Profile found
(e.g. disabled or not existing).

The AppMon Agent is connected but instrumentation is disabled.
An incident is raised: *AppMon Self Monitoring - Ambiguous Agent Mapping*

One matching System Profile found.

The AppMon Agent is connected and the matching System Profile is applied.

More than 1 matching System Profiles found
(e.g. overlapping Mapping definitions).

The AppMon Agent is connected and the first matching System Profile is applied.
An incident is raised: *AppMon Self Monitoring - Ambiguous Agent Mapping*

Advanced Settings

You can dynamically configure Agents that match this Agent Mapping:

  • Buffer Saturation Threshold: If the Agent's communication buffer is filled above this threshold, no new PurePaths are added to the buffer until the buffer empties below the threshold. This increases the amount of correct PurePaths in certain Agent overload scenarios.
  • Buffer Size & Count: Define the overall size of the Agent communication buffer. Overall size is about equal to size * count.
  • Agent Log Level: Override the Agent's default log level.
  • Hot Sensor Placement : Enable/Disable Hot Sensor Placement. If set to Automatic the Agent enables Hot Sensor Placement automatically if supported by the underlying VM (e.g. older JVM's do not support Hot Sensor Placement or certain JVM versions contain bugs that prohibit the usage of Hot Sensor Placement).
  • Resource Exhausted Notifications (only available when Java is enabled for System Profile): Enable/Disable automatic generation of a Leak Analysis Memory Snapshot in case a Java 6 VM reports an Out-of-Memory notification. This option is not visible if you didn't select Java on the General pane of the System Profile, and enabling it only affects Java agents.
  • .NET Trending/Leak-Analysis Memory Snapshot: Enable/Disable creating Trending / Leak Analysis Memory Snapshots for .NET CLRs. By default, this is set to Automatic. This means that this is determined by the CLR version, but is off by default with any version. Off means no Memory Snapshots are possible and no additional overhead due to CLR notifications is necessary for Memory Snapshots. If you switch this to Always On, runtime overhead increases, even if no Memory Snapshot is created. Memory Snapshots for CLRs can be created.
    If you change this setting, restart the SUD. In case of ASP.NET, the AppPool must be recycled.
    When you see Agent configuration may cause high runtime overhead in the Start Center, take the appropriate action.

When you enable this feature, it introduces a significant amount of overhead (GC times will go up). We do not recommend it in a production environment.

  • Extended PurePath Information: Enable or disable Auto Sensors for the given Agent Group. You can select the granularity of the information provided by Auto Sensors. Auto Sensors must be enabled to have sync and wait times.
    You can enable / disable Extended PurePath information and adjust tolerable overhead vs. desired resolution dynamically at runtime. For overhead and detail numbers and defaults in Editions, see Sensors > Auto Sensor Resolution Settings.

For additional details, see Usage of Agent Groups.