Discovering Components Using the eG Agents

Enabling/Disabling Component Discovery by eG Agents

By default, it is the eG manager which discovers components in the target environment. To enable the eG agents to perform component discovery instead, do the following:

  1. Select the Enable/Disable option under the Actions sub-node of the Agent Discovery node of the discovery tree of Figure 8.

  2. The right panel will then change as shown by Figure 1.

    Enabling Agent Discovery

    Figure 1 : Enabling agent discovery

  3. To enable agent discovery, just click the check box against Agent discovery.

  4. Doing so brings up the message box depicted by Figure 2, which prompts you to confirm whether/not you want to enable component discovery by eG agents. Click Yes to confirm enabling.

    Confirmation for Enabling Agent-based Discovery

    Figure 2 : A message box requesting your confirmation to enable component discovery using eG agents

  5. Click Yes in the message box to enable agent-based component discovery, or No to disable it. If agent discovery is enabled, you can also enable the agents to auto-discover inter-application dependencies - in other words, the capability to auto-discover the ‘topology’. Accordingly, as soon as Yes is clicked in the message box above, a Topology discovery flag will appear (as shown by ).  

  6. If you want to enable topology discovery, just select the Topology discovery check box in . Figure 4 will then appear requesting your confirmation to enable topology discovery.

    Confrmation for Topology Discovery

    Figure 3 : A message box prompting you to confirm whether/not to enable topology discovery

  7. Click Yes in Figure 4 to enable topology discovery, and No to disable it.
  8. At any given point in time, you can disable agent-based component discovery by deselecting Agent discovery check box in Figure 1. Note that once ‘Agent discovery’ is disabled, ‘Topology discovery’ will automatically be switched off.

Configuring General Settings for Agent Discovery

To configure the settings that govern component discovery by eG agents, do the following:

  1. Click the General option under the Settings sub-node of the Agent Discovery node in the discovery tree of .

  2. An Agent Discovery Settings page will then appear in the right panel (see Figure 4).

    Defining Settings for Agent Discovery

    Figure 4 : Defining settings for agent discovery

  3. By default, the eG agent will discover only those applications that are running in the local system. Accordingly, the Discover local applications flag is set to Yes by default. If you do not want the eG agent to discover local applications, set this flag to No. Likewise, by default, the eG agent will not discover related applications running on remote hosts. This is why, the Discover remote applications flag is set to No by default. If you want the eG agent to discover remote applications, set this flag to Yes. If you set both flags to No, then agent discovery will not take place, even if the discovery capability is explicitly enabled.
  4. In the Agent discovery startup delay (Mins) text box in the right panel, indicate the duration (in minutes) for which the agent needs to wait before beginning discovery.
  5. To indicate how frequently the agent should rediscover components, set a time period (in minutes) against the Agent rediscovery period (Mins) field.
  6. You can also instruct the eG agent to timeout if no components are discovered from an agent host beyond a specified duration. This duration needs to be mentioned in the Discovery timeout (Millisecs) text box.

  7. When monitoring Citrix infrastructures, administrators often prefer to manage the Citrix Virtual Apps (XenApp) servers in a delivery group as a single 'aggregate' component. This enables them to easily assess the load on and resource usage of a delivery group, across all the Virtual Apps servers it manages. To achieve this, administrators often have to painstakingly identify the Virtual Apps servers in a delivery group, manage each of these Virtual Apps servers using eG Enterprise, and manually stitch them together to create an aggregate component. This requires significant administrative time and effort. To ease the burden of administrators, you can now configure the eG agent monitoring a Citrix delivery controller to automatically discover the Citrix Virtual Apps servers in every delivery group managed by the controller, and auto-create an aggregate component in eG Enterprise for each delivery group. To enable this capability for the eG agents, set the Auto-manage aggregates flag to Yes.

    Note:

    When monitoring Citrix infrastructures, administrators often prefer to manage delivery groups on a Citrix Delivery Controller as Component Groups in eG Enterprise. Previously however, to achieve this, administrators had to manually create a component group in eG for every delivery group managed by the controller. This meant that every time the delivery group configuration changed, the configuration of the corresponding component group had to be manually changed. eG Enterprise saves the time and effort involved in this exercise by completely automating this cumbersome process!

    If an eG agent is installed on a Citrix Delivery Controller and is monitoring it, then this agent can now auto-discover all the delivery groups managed by that controller and the Virtual Apps servers in each group. The eG manager uses the details so discovered to accurately identify the delivery group to which a managed Virtual Apps server belongs. With this knowledge, the eG manager then automatically creates a component group in eG, adds the managed Virtual Apps server to it, and also assigns the delivery group’s name (by default) to that component group. If later, Virtual Apps servers are added/removed from a delivery group, eG Enterprise auto-detects this change and updates the corresponding component group configuration accordingly. This eliminates the need for any manual intervention in component group maintenance.

    To enable this capability, two new flags have been introduced in this version:

    • AutoCreateGroups: Available in the [DISCOVERY_SETTINGS] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory). The flag is set to false by default. If set to true, then eG Enterprise will check whether/not a managed XenApp server is part of any of the auto-discovered delivery group. If so, then eG will auto-create a component group corresponding to that delivery group, and will add the XenApp server to it.

    • PrefixForAutoCreatedGroupNames: Available in the [DISCOVERY_SETTINGS] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory). By default, the component groups that eG auto-creates will be named after the delivery groups they represent. If you want the auto-created component group names to be prefixed by any string, then specify that string here.

      Note:

      If a delivery group is removed, then eG Enterprise will automatically remove the corresponding component group, only if that component group is not part of any segment/service configuration. Also, even if a delivery group is removed, eG Enterprise will NOT remove/unmanage the managed XenApp servers in that group.

  8. By default, if agent discovery is enabled, the eG agent on a system discovers the operating system and the applications running on the system. This is why, the Discover only operating systems flag is set to No by default. If you want eG agents to only discover the operating systems on which they operate, then set this flag to Yes. In this case, only OS-specific components (eg., Microsoft Windows, IBM Linux) will be auto-discovered and made available for management (provided they are not configured for auto-management).

  9. When monitoring Citrix infrastructure, ff agent discovery is enabled, the eG agent installed on a Citrix Delivery Controller auto-discovers all the Citrix Virtual Apps servers even if they are not part of any of the Delivery Groups managed by that controller. This is why, the Discover Virtual Apps servers that are part of Delivery Groups flag is set to No by default. However, if you want the eG agent to discover only the Virtual Apps servers that are part of the Deliver Groups, then set this flag to Yes.

  10. Finally, click the Update button.

Based on these settings, the eG agents then proceed to perform discovery.

Note:

Typically, if environment discovery is performed using the eG agent, then the agent is first installed and started so as to initiate the discovery procedure. The discovered components are then pushed to the eG manager by the agent. When this happens, the agent also checks the manager for applications that require monitoring. However, since the administrator would not have managed any component at this stage, the agent will have no information to download. Therefore,  the agent remains inactive for 1 minute, after which it polls the manager yet again for downloadable information. The eG agent determines this poll frequency using an exponential backoff algorithm - this is typically 1.5 times the previous poll period - for instance, if the agent polls the manager on the 3rd minute but finds nothing to download, then it will sleep and poll the manager again on the 4.5th minute (3*1.5). At this rate, if no component is managed by the administrator for a long time, it would be over 1 hour before the agent starts reporting metrics to the manager

To avoid this, by default, during the first 2 days after an eG agent is started, the agent polls the manager more frequently, so that administrators can start viewing performance results soon after configuration of the agent. During this default period (2 days), the agent checks every 10 minutes (approximately) for instructions from the manager. After this period, the sleep time begins to grow in the same manner mentioned previously. This default behavior is governed by the IncreaseAgentSleepTimeAfter flag in the [agent_settings] section of the eg_tests.ini file (in the <EG_INSTALL_DIR>\manager\conf directory). By default, this is set to 2 (days) from the agent start time. To ensure that the agent poll frequency remains at 10 minutes for a more number of days since agent startup, change the value of the IncreaseAgentSleepTimeAfter flag.

Automatically Discovering the Topology Using the eG Agent

Whether an infrastructure is virtual or physical, inter-dependencies exist between applications. For example, a web server uses a middleware application server, and an application server relies on a database server. eG Enterprises uses this inter-dependency information for root-cause diagnosis – so administrators can determine where exactly the problem lies and where the effects are.

eG Enterprise includes the capability to auto-discover inter-application dependencies. This auto-discovery reduces the time and effort involved in setting up the performance monitoring solution and also reduces the human errors that can be involved in manual specification of inter-application dependencies.

In the eG Enterprise system, segment/service topology definitions embed the inter-application dependencies. Discovery of this topology information is initiated by the agents.

By default, the ability of the eG agent to automatically discover topology is enabled. However, this default setting will take effect only if the eG agent has the ability to automatically discover components. This is because, topology discovery cannot be performed without component discovery. This is why, as soon as the Agent discovery flag is turned on (see ), the Topology discovery flag is also enabled.

If Topology discovery is enabled, then, in the right panel of Figure 4, a Topology Discovery Settings section will appear below the Agent discovery settings section. The settings that can be defined in the Topology Discovery Settings section are depicted by Figure 5.

Defining Topology Discovery Settings

Figure 5 : Defining topology discovery settings

Once automatic topology discovery is enabled, the eG agent will run the netstat command on the target host every 45 minutes (by default) to determine which applications are operating on the host and which port they listen to. This default frequency can be overridden using the Delay between successive dependency discovery attempts (Mins) parameter in Topology Discovery Settings section of Figure 5. By default, this parameter is set to 45 by default, indicating that the default discovery frequency is 45 minutes. To override this default frequency, specify a different duration (in minutes) against the Delay between successive dependency discovery attempts (Mins) parameter.

Whenever the eG agent on a host runs netstat, it retrieves a list of ports that are operating on that host. While some of these TCP ports may be standard listening ports - i.e., TCP ports at which the applications executing on that host listen for requests from remote hosts/applications - a few other TCP ports may be local ports created dynamically on the host for a temporary purpose. To clearly differentiate between listening ports and local ports, the eG agent does the following:

  • By default, the eG agent compares the ouput of four consecutive executions of the netstat command on a host. If a port number is repeated in all the four netstat outputs by default, then that port number is counted as a 'server listening port'. This default behavior is governed by the Dependencies must be present and the Number of dependency discovery attempts parameters in the Topology Discovery Settings section of Figure 5. As can be inferred from Figure 5, both these parameters are set to 4 by default. The 4 against the Number of dependency discovery attempts parameter indicates the maximum number of consecutive netstat outputs to be considered for identifying the server listening ports. The 4 against the Dependencies must be present parameter indicates the minimum number of netstat outputs in which a port number should appear for it to be considered as a 'server listening port'. You can change this if you need. For instance, if you set the Dependencies must be present parameter to 3 and let the Number of dependency discovery attempts parameter to remain at 4, then the eG agent will count the port numbers that appear in at least 3 out of 4 consecutive netstat outputs as active listening ports.
  • Once the listening ports are identified, the agent then closely observes traffic to and from a 'server listening port', identifies the remote applications that frequently connect via this port, and thus automatically discovers the inter-relationships that exist between applications in an IT infrastructure. The interdependencies that are so discovered are then sent to the eG manager. On the other hand, all those port numbers that do not conform to the specification governed by the Dependencies must be present and the Number of dependency discovery attempts parameters are counted as local ports. All traffic to local ports are hence disregarded for the purpose of topology auto-discovery.

By default, the whole cycle of operations - beginning with isolating the listening ports to discovering inter-dependencies to reporting the discovery to the eG manager - takes 180 minutes (as indicated by the default value 4 against the Dependencies must be present setting) to complete. After which, the eG agent will wait for another 60 minutes (i.e., 1 hour, by default) to rediscover the topology. In other words, all the aforesaid activities will be performed again by the eG agent every hour after the first cycle is complete. Like other default settings, you can also override the frequency with which topology is rediscovered by the eG agent. For this, use the Topology rediscovery period (Mins) parameter, which is set to 360 by default.