Settings for discovering Components using eG Agents
The AGENT DISCOVERY SETTINGS page depicts how the eG agents discover the components.
Typically, an agent is installed on a host only when an administrator is interested in monitoring one/more applications executing on that host. In large IT environments characterized by tens of components, it is often difficult for administrators to manually track where agents are installed, and manage only the corresponding hosts and applications. In such environments therefore, administrators might prefer to run a discovery procedure that automatically discovers only those components that they are “interested in monitoring” - i.e., an auto-discovery procedure that can discover only those applications which are executing on the hosts where agents are installed; this ensures that the eG administrative interface is not crowded with a wide variety of applications that an administrator might not even be interested in monitoring. This can be achieved only if discovery is performed using the eG agents.
Like manager discovery, agent discovery is also port-based. The agents use a port scanning technique to discover the applications executing on the hosts on which they are installed. Since every agent performs the discovery and communicates the results to the eG manager, the location of the eG manager will not in any way impact the discovery process - i.e., even if the eG manager is behind a firewall and is not able to access the components in the target environment, the eG agent will be able to promptly detect the additions/removals in the environment everytime it rediscovers, and will be able to update the eG manager with this knowledge.
However, a key limitation here is that since no agent can be installed on network devices, they cannot be discovered by the eG agents.
To configure the settings that govern component discovery by eG agents, do the following:
Click the General option under the Settings sub-node of the Agent Discovery node in the discovery tree. The AGENT DISCOVERY - GENERAL SETTINGS page will then appear. In the Agent Discovery Settings section of the page, the Enable agent discovery flag is set to No, by default. To allow the eG agents to perform discovery, set this flag to Yes. 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. In the Agent discovery startup delay (Mins) text box, indicate the duration (in minutes) for which the agent needs to wait before beginning discovery. To indicate how frequently the agent should rediscover components, set a time period (in minutes) against the Agent rediscovery period (Mins) field. 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. When monitoring Citrix infrastructures, administrators often prefer to manage the Citrix 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 XenApp servers it manages. To achieve this, administrators often have to painstakingly identify the XenApp servers in a delivery group, manage each of these XenApp serveres 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 XenApp 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 XenApp servers in each group. The eG manager uses the details so discovered to accurately identify the delivery group to which a managed XenApp server belongs. With this knowledge, the eG manager then automatically creates a component group in eG, adds the managed XenApp server to it, and also assigns the delivery group's name (by default) to that component group. If later, XenApp 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, set the following flags:
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.
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). 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.
Settings for automatically Discovering Topology Using eG Agent
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 ablity 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, the Topology discovery flag is also enabled.
If Topology discovery is enabled, 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.
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. 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. 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 exist 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 exist 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.
|