Agent Groups

What are Agent Groups?

Use Agent Groups to automatically assign Agents to groups that share the same configuration settings for Sensor Placement, Sensor Configuration, and Measure Subscription. Use Agent Mappings to map Agents based on name or host.

What are the benefits of Agent Groups?

AppMon is initially deployed and configured in a test or pre-production environment. These environments are similar to their production counterparts but with fewer SUDs and fewer Agents: two application servers in preproduction versus four in production.

When AppMon is deployed in production, the AppMon configuration must be migrated. Use a layout of Agent Groups and Agent Mappings to simplify this process. The production Agents are dynamically mapped to Agent Groups as they connect to the AppMon Server. They share the same Sensor Placement and Sensor Configuration. The Measure Subscriptions are shared on-the-fly with zero configuration.

Configure Agent Groups

An Agent Group defines:

  • Which Sensors to place, including Knowledge Sensor Packs and Method and Memory Sensor Rules.
  • How the Sensors are configured, such switch on/off parameter capturing for the Servlet Sensor.
  • Which Measures are subscribed: either for the specific Agent Group, a set of Agent Groups or all Agent Groups.

The Agent Mapping specifies which Agents belong to an Agent Group based on Agent Name and optionally the Agent Host. Additionally, you must configure an alias and use it throughout the AppMon Client for user-friendly visualization, since Agents are similarly named to the SUD or infrastructure, for example node42 or prod-100-xserver.

Agent mapping workflow

It is important to understand how Agents are mapped to Agent Groups and assigned to System Profiles. Consider the following example:

The System Profile easyTravel Alice has a single Agent Group All Agents configured. It contains two Agent Mappings, CustomerFrontend_easyTravel and BusinessBackend_easyTravel, which map all AppMon Agents starting with CustomerFrontend_easyTravel and BusinessBackend_easyTravel from all hosts (the Agent Host setting is empty) to this Agent Group and System Profile.

In contrast, easyTravel Bob has two Agent Groups Customer Web Frontend (Java) and Business Backend Server (Java). Each contains one Agent Mapping CustomerFrontend_easyTravel and BusinessBackend_easyTravel respectively, which map Agents named CustomerFrontend _easyTravel to the Agent Group Customer Web Frontend (Java). Analogously, Agents named BusinessBackend_easyTravel map to Business Backend Server (Java).

Putting it all together

When an Agent initially connects, the AppMon Server (Collector) iterates over all System Profiles in alphabetical order. Then it evaluates all Agent Groups and their respective Agent Mappings one after another, from top to bottom (as they have been defined), preferring Agent Mappings that match both name and host over name-only matches.

Let's deploy both System Profiles easyTravel Alice and easyTravel Bob to the same AppMon Server and examine the mechanics when various Agents connect:

Example 1: An Agent named CustomerFrontend_easyTravel1 connects from host staging

It initially matches to easyTravel Alice's Agent Group All Agents. Since the host value is empty, there may be a better match to one of the other Agent Mappings; the search continues. The Agent Mappings of easyTravel Bob match AppMon Agents starting with CustomerFrontend _easyTravel but also staging has been explicitly specified, and a better match was found. Thus, the Agent is associated with easyTravel Bob's Agent Group Customer Web Frontend (Java).

Example 2: An Agent named BusinessBackend_easyTravel32 connects from host testing

It initially matches to easyTravel Alice's Agent Group All Agents. Since no host value is specified, the search continues. easyTravel Bob's Agent Groups explicitly match Agents connecting from staging; no better match is found. The Agent is associated with easyTravel Alice's Agent Group All Agents.

Example 3: An Agent named myAgent connects from staging

It neither matches to any of easyTravel Alice's nor easyTravel Bob's Agent Mappings; it is not associated with any of the System Profiles' Agent Groups. Nevertheless, the Agent shows up in the Agent Overview and System Overview dashlets of all System Profiles to increase the user awareness because this typically indicates misconfiguration. After appropriate Agent Mappings are created, the Agent must be restarted.

Disabling System Profiles

Multiple System Profiles with similar Agent Mappings are confusing. In big deployment scenarios, use meaningful names for all Agents and map them into clearly defined Agent Groups. You cannot do this if you copy or import a System Profile.

You can disable System Profiles to find configuration problems easier. When disabled, the System Profile is skipped during the evaluation of Agent Mappings for all incoming Agents. Additionally, any Scheduled Tasks or Monitors are not executed until the System Profile is activated again.

See Enable or Disable a System Profile.

What happens to assigned Agents?

An Agent that is assigned to a System Profile is bound to it until it is restarted. If the System Profile is disabled or its Agent Mappings are modified so that it no longer matches the Agent, the Memory/Method Sensors and Sensor Configuration/Placement stay the same, even though the Agent is not assigned to this System Profile anymore.

This guards against incorrect configuration, but you have to restart the Agent to match to a different System Profile.