Discovering Components

eG Enterprise is capable of automatically discovering the components in the target environment. To perform this discovery, administrators can use either the central eG manager or the eG agents installed on the target hosts. Both these discovery methodologies are briefly discussed below:

  • Discovering Components in a Configured IP Range using the eG Manager:

    The eG manager performs discovery using one/more of the following approaches:

    • Using a novel port scanning algorithm on systems in configured IP address ranges ; this is the most common technique and is ideal for discovering port-based components;
    • Using the SNMP community string; this is ideal for discovering network devices/storage systems in a configured IP range, as they do not listen on any port;
    • Using proprietary APIs provided by the target applications/infrastructure - eg., virtual platforms such as VMware vSphere, public cloud platforms such as Amazon AWS etc.
    • By making sample requests to servers and receiving responses - eg., ICA Connect
    • By analyzing responses to sample requests - e.g., HTTP Header in the response indicates type of web server
    • Using TTL of ping responses - Unix vs. Windows
    • Using banners when it connects to the telnet port
    • Using traceroute to discover network devices

    The eG manager-based discovery is most suitable for Enterprise deployments of the monitoring solution. This is because, in such deployments, the eG manager will have full access to all components in the environment, thus making discovery easy. On the flip side however, in environments where no direct access to components is available - eg., cloud-based infrastructures, servers in private networks or demilitarized zones, environments secured by strict firewall rules - the eG manager cannot perform discovery.

    Also, with the eG manager performing discovery, you need not deploy an eG agent on every target for discovery. This means that where agentless monitoring is preferred - typically, monitoring network devices, or servers in high-security environments - manager-based discovery is the right pick. The trade-off here is that agentless monitors of servers cannot provide the deep dive performance insights that agent-based monitors can.

    Moreover, for performing discovery, the eG manager relies only on default configurations - meaning, if an application listens on a port other than its default/standard port, or if the TCP port of the application is dynamic the manager will not be able to discover that application. Likewise, using the eG manager you cannot discover additional information such as the version of applications, SID of an Oracle database server, etc.

  • Discovering Components Using the eG Agents: The eG agent performs discovery using one/more of the following techniques:

    • By scanning the ports on agent hosts;
    • By making sample requests to servers and receiving responses - eg., ICA Connect
    • By analyzing responses to sample requests - e.g., HTTP Header in the response indicates type of web server
    • By checking for the existence of specific services/processes on the targets; service name helps differentiate between versions of applications (e.g., XenApp 6 vs 7)
    • By scanning the values of registry entries and environment variables; the install directory of applications can also be discovered in the process
    • Using OS commands - eg., netstat to check if a port is open or if a process is running
    • Using application configuration files
    • Using applications APIs and commands
    • If APM monitoring is configured for an application, then the eG APM Monitor can also be used for discovery

    Agent-based discovery is ideal for the SaaS deployment model of eG Enterprise. This is because, in SaaS/cloud-based environments, the eG manager will not have direct access to the monitored servers, and hence cannot perform discovery. Since the eG agents are deployed on the servers to be monitored, they have unrestricted access to the targets. Moreover, using the eG agents, more information can be discovered from the servers - eg., application versions, SIDs etc. Also, with eG agents, accurate discovery is possible - for instance, if eG APM is installed and configured on an Oracle WebLogic server, then the eG agent can automatically discover all the WebLogic server instances operating on the server.

    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.

    Besides individual components, the agent can also be used to automatically discover the component topology - i.e., the physical/logical inter-relationships that exist between discovered components. This ability, when enabled, helps administrators draw an almost accurate segment topology with minimal user intervention and time! Also, since the auto-discovered topology depicts the 'real' dependencies that prevail in a 'real' environment, it consequently enhances the eG Enterprise system's innate ability to auto-correlate performance and proactively detect performance issues.