eG Administration
 

Adding new components / Modifying existing components

Adding a new component

This page illustrates the parameters that have to be specified by an administrator when adding a new component for monitoring by the eG system.

  1. Category: In eG Enterprise, components are grouped into categories based on their functionality - for instance, Oracle and Microsoft SQL servers are grouped under the category Database servers and VMware vSphere and Citrix XenServers are grouped under the category Virtualization Platforms. If a specific Category is chosen, then only those component types that belong to the selected category will be available for selection in the Component type list. By default, All is chosen as the Category, which is why all component-types monitored out-of-the-box by eG Enterprise are by default available for selection in the Component type list.

  2. Component type: Select the type of component to be managed from the Component type list. By default, the Component type list includes all those component types that are supported out-of-the-box by the eG Enterprise Suite. To filter the Component type list, you can use the Show managed component types only check box. By default, this check box will be unchecked, indicating that the Component type drop-down will by default list all component types that are supported out-of-the-box by the eG Enterprise Suite. Select the Show managed component types only check box if you want the Component type drop-down to list only those component types with at least one managed component. This way, you can filter out all those component types for which not even one component is managed.

    For each type of component chosen from the Component type list, the administrator can add a new component for monitoring by choosing the Add New Component option.

  3. Host IP:In the Host IP text box, specify the IP address IP address or the “fully qualified host name” of the component being added.

    Note:

    If you choose to specify the IP address of a component against Host IP/Name, then remember that this IP address can be an IPv4 or an IPv6 address.

  4. Nick name: You need to specify a Nick name for the component in the Nick name text box. The nick name specified here should match the ones specified while installing the eG agent.

    Note:

    • While specifying a nick name for a component, ensure that you do not use the same name as that of the internal name of the component-type. For instance, you cannot add a component of type Generic_server with the nick name Generic_server.

    • If required, both the Host IP/Name and Nick name parameters of a component can be configured with the IP address of that component. However, if the Host IP/Name parameter has been configured with the target component's IPv6 address, then you cannot configure the Nick name parameter also with that IPv6 address; in this case, the Nick name should be some other logical name by which you want to identify the component.

  5. Port number: The default port on which the component listens will be displayed. You can change this, if required. If a component type has multiple default ports, then the first port in the comma-separated list displayed/configured against the component type will be displayed here. For components that are not associated with ports, the port number has to be specified as NULL.

  6. Agentless: By selecting/deselecting the Agentless checkbox, indicate whether the component being added is to be monitored in an agentless or agent-based manner. By default, this will be set to No.

    The agent-based approach to monitoring requires one internal agent per system that is to be monitored. As operating systems and applications have evolved, they have incorporated newer instrumentation mechanisms that allow monitoring of these environments from remote locations - i.e., external to the system or application that is to be monitored. The main advantage of this remote monitoring approach is that it does not require an agent to be installed on every system that is to be monitored - hence, the name “agentless monitoring” for this approach. The table below summarizes the tradeoffs between agentless and agent-based monitoring.

    Agentless Monitoring Agent-based Monitoring
    Easier to implement, maintain, and upgrade as there is no need to deploy agents on all the servers More difficult to implement as it requires agents on critical servers
    The nature of statistics that can be reported depends on the instrumentation levels and on the access rights provided for monitoring from a remote location Typically, used to collect a wealth of availability, performance, usage metrics; can provide tight integration with the operating system and applications monitored
    Mostly used for problem detection and alerting; provides limited information for diagnosis Can provide critical information for problem diagnosis and remote control/problem correction
    Significant network overheads; all the monitoring is done over the network This configuration optimizes network usage; most of the data collection and analysis is done on the servers and only processed metrics are transmitted; hence, this approach is very efficient in its network usage
    Higher security risk - monitoring from a remote location must be allowed; some ports (e.g., Netbios/SSH) need to be opened for remote access No security risk - the agent does not listen on a port, no firewall rules need to be changed, no new ports need to be opened for the monitoring

    Unlike many existing solutions, eG Enterprise does not require that IT administrators choose between one of these contrasting approaches at the time of installing/deploying eG Enterprise. Instead, when adding any new application/system for monitoring, administrators have a choice of whether to use agent-based or agentless monitoring for the application or system under consideration. For instance, an administrator can choose to monitor the most critical servers in an agent-based manner, and to monitor the less critical servers in the staging/development environment in an agentless manner.

    Note:

    If two components have the same IP-nickname combination but different monitoring modes, then eG will not be able to monitor those components properly - i.e., if one component is managed as agent-based and the other, agentless, then eG will not be able to monitor both the components.

    If Agentless is set to Yes, then the following steps will apply:

    • Select the operating system of the component from the OS list box. Agentless monitoring is implemented in the eG Enterprise suite using Remote Agents. A remote agent is an agent that is capable of monitoring a number of systems and applications remotely, in an agentless manner. For monitoring Microsoft Windows systems and applications, a remote agent uses Netbios/perfmon to communicate with the operating system/applications.

    • Therefore, if a Windows platform is chosen from the OS list box, then automatically, Perfmon will be displayed against Mode.

      • Note:

      • Before attempting to monitor a Windows system in the agentless mode, ensure that the target system consists of the default share named ADMIN$. If this share does not exist on a target, then the remote agent will not be able to connect to that system or collect metrics from it. To check whether ADMIN$ pre-exists, do the following:

        • Login to the target system and go to the command prompt.

        • Type the command net share; this command will list all the default and user-configured shares on the system

        • If ADMIN$ is not listed, it is a definite indicator that the system does not consist of the ADMIN$ share.

        The way forward is to manually configure the ADMIN$ share on the target system. To do so, issue the command net share ADMIN$ from the command prompt of the system. This will create the ADMIN$ share. For more information on net share, check out the URL: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/net_share.mspx?mfr=true

      • The remote agent connects to the Windows host to be monitored using NetBIOS - a protocol that allows applications on different computers to communicate within a local area network. If NetBIOS is not enabled on a Windows host, then eG Enterprise cannot monitor that host in an agentless manner.

    • For monitoring Unix systems, by default, Rexec is used. Accordingly, upon choosing a Unix platform from the OS list box, the Mode displayed will be Rexec. Rexec executes commands remotely on a Unix host. The default port number of the Rexec command is 512, which will be displayed against the Remote port field. The rexec command requires a valid user name and password at the remote host to connect to it. Therefore, provide the necessary login credentials against the User and Password text boxes.

      • Note:

      • While connecting to a remote host, Rexec sends passwords in clear text, and hence can be used only in secure environments. SSH is a more secure alternative.

      • If the remote agent is unable to connect to a Unix host, then check the /etc/inetd.conf file to verify whether the rexecd daemon on the target host is started. This daemon provides the server function for the rexec command. If the rexecd line in the /etc/inetd.conf file is uncommented, it indicates that the daemon has been started. If the line is commented, then uncomment it, save the inetd.conf file, and then run the refresh -s inetd command or the kill -1 InetdPID command to inform the inetd daemon of the changes to its configuration.

    • Alternatively, SSH can be chosen as the Mode. Also, the port number for secure shell access has to be specified against the Remote port field. By default, 22 is the port at which the SSH server listens. SSH allows access to only authorized users of the Unix host. Therefore, provide a valid User name and Password for authentication.

    • In order to monitor any other operating system (such as, AS400) in an agentless manner, select the Other option from the OS list box. In such a case, the MODE displayed will be SNMP.

      • Note:

      • For specific applications, the remote agent uses application-specific protocols to communicate with the application (e.g., SQLNet for Oracle databases, HTTP for WebLogic and WebSphere application servers, JDBC for Sybase, etc.).

      • When deploying a remote agent, it is essential to ensure that the remote agent can communicate using multiple of these agentless mechanisms with the target environment (appropriate firewall rules must be configured for this purpose).

      • For monitoring a Microsoft Windows environment, typically, the remote agent must be installed and running with the permissions of the domain administrator. Hence, typically, at least one remote agent is necessary for each independent domain being monitored.

      • The following capabilities of the eG Enterprise suite are not available for servers or applications that are managed in an agentless manner:

        • Detailed diagnosis

        • Automatic corrective script execution

        • Remote control actions

        • The eG web adapter for in-depth web server monitoring on Unix and Microsoft environments - i.e., web transaction monitoring for web servers is not available with agentless monitoring.

    • Next, from the list of Remote agent that have been configured in the environment , select the remote agent that will monitor the component being added.

      • Note:

      A remote agent can monitor a maximum of 10 targets only.

    • Then, from the External agents box that lists all the external agents that have been configured in the environment, select the external agent(s) that will monitor the component being added from an external perspective.

    • Finally, click on the Update button to add the new component details to the eG system.

      • Note:

      • Like other agent types, remote agents too communicate with the eG manager through HTTP/HTTPS.

      • The same agent can function as a remote agent as well as an external agent. However, an external agent for which client emulation has been enabled cannot function as a remote agent.

      • The same agent package will be used to install a remote agent.

    On the other hand, if Agentless is set to NO, the following steps will apply:

    • By default, if a host has multiple IP addresses, the eG system requires one agent license for each IP address that is managed internally. Likewise, if multiple nicknames are used for the same IP address, a separate internal agent license is used for each unique nickname that has been specified. In many large environments, a single server has many IP addresses, each with different nicknames. The agent per system capability is intended to optimize the internal agent license usage in such large infrastructures. If this capability is enabled by the eG license, the administrator has the option of overriding the default eG agent licensing policy. For example, suppose a server A has two IP addresses 192.168.10.7 and 10.10.10.1, and that the first IP address 192.168.10.7 has already been managed in the eG system. When adding the second IP address, 10.10.10.1, using this page, the administrator has the option of overriding eG's default internal agent licensing policy. To achieve this, the administrator will first have to select the MANUAL option from the Internal agent assignment field (the default selection here is Auto).

    • Upon choosing Manual option, an additional Internal agent list box will appear. From this list box, select the internal agent that needs to be associated with the IP being created. For the IP address 10.10.10.1 that is being created in our example, the administrator can select the internal agent that has already been associated with the IP address 192.168.10.7. By doing so, the administrator can ensure that a single agent license is sufficient to manage all the IP addresses and applications executing on a host.

    • Finally, associate one or more External agent with the component, and click the Update button to complete the configuration.

    Note:

    The Internal agent assignment field will appear only if the following conditions are fulfilled:

    • The eG license enables the Agent per system flag

    • The Agentless flag is set to NO.

  7. If the Component type is Oracle Database, an additional field SID is provided. This field indicates the specific Oracle instances associated with the host IP address and port number specified above.

  8. Moreover, where cluster monitoring is supported, eG Enterprise enables users to indicate at the time of component addition, whether the component being added is an active or passive server in the cluster. Currently, eG Enterprise is capable of monitoring the following cluster services: Oracle, MS SQL, Active Directory, and Exchange 2000/2003. This is why, while adding an Oracle database, Microsoft SQL, Active Directory, or Exchange 2000/2003 component, this page includes an additional Is passive flag. This flag is set to No by default, which implies that the component being added is an active server in a cluster, by default. If this flag is set to Yes, it indicates that the server being added is a passive server in a cluster. In this case, no alerts will be generated if the server is not running. Measures will be reported as "Not applicable' by the agent if the server is not up.

  9. If the Component type corresponds to one of the Microsoft web servers (e.g., IIS web server or IIS ssl server), an additional field called MTS enabled appears. The eG system's discovery process does not automatically discover Microsoft Transaction Servers (MTSs). Using the MTS enabled option, an administrator can specify whether an MTS server is executing on the same host as a Microsoft web server (IIS or IIS ssl). Using the Yes option, an administrator can associate an MTS server with the host that executes the Microsoft IIS web server or SSL server. If the administrator does not want to associate an MTS server with the IIS web server or SSL server host, he/she can choose the No option.

Once these details are specified, clicking on the Update button will add this component to the list of components being managed and monitored by the eG system.

Modifying  component details

This page is obtained by clicking the Modify button against the component name in the ADD/MODIFY page and enables the user to change the details of an existing component. This page depicts the current details of the component.

  1. Component type: This field indicates the type of the component (e.g., Web server, Database server, etc.).

  2. Host IP: This box depicts the host IP or host name of the component under consideration. To change this specification, do the following:

    • First, click on the Change IP button. If the AllowQualifiedHostNames flag in the eg_services.ini file is set to “yes”, then the “Change IP” button will change to become the “Change IP/Name” button.

    • The page that appears next will display the current IP of the component and its nick name. Specify the New Host IP in this page, and click the Update button to save the changes. If the AllowQualifiedHostNames flag in the eg_services.ini file is set to “yes”, then you can specify the “New Host IP/Name” here.

    • Doing so lists all components that share the original IP/host name of the component. To update one/more of the listed components with the new IP/host name, select the check boxes corresponding to the required components. Then, click the Update button to apply the change to all selected components. To return to COMPONENTS page, click the Cancel button.

    Note:

    • If the Host IP and Nick name of a component are the same, then you will not be allowed to change the Host IP. In this case therefore, the Change IP button will not be available in the MODIFY COMPONENT DETAILS page.

    • If the AllowQualifiedHostNames flag in the eg_services.ini file is set to yes, then, in the Modify mode, the IP address can be changed to a host name and vice versa.

    • If you do not want the option to change the IP address or host name of a managed component, then you can disable this capability using the steps discussed below:

      • Edit the eg_services.ini file in the {EG_INSTALL_DIR}\manager\config directory.

      • Set the isAllowIPChange flag in the [MISC_ARGS] section to no (default is yes).

      • Save the file.

      When this is done, the Change IP button will not be available while modifying the details of any managed component in the environment.

  3. Nick name: The nick name of the compoent can be modified in this text box. A nick name is a logical name that is associated with the host being monitored. When installing an agent, the nick name specified must match the name specified in this page. When a host name or nick name is specified, the eG manager checks the existing IP address to host name mapping. If the specified host name or nick name does not exist in the existing mapping, the user is alerted to ensure that additional care is taken while specifying the host name.

    4. Note:

    While specifying a host/nick name for a component, ensure that you do not use the same name as that of the component-type. For instance, you cannot add a component of type AIX with the host/nick name AIX.

  4. eG Enterprise provides monitoring support to Oracle, Exchange, MS SQL, and Active Directory clusters. While adding an Oracle, Exchange, MS SQL, or Active Directory server therefore, this page prompts you to indicate whether the server being added is an active or passive server of a cluster. By default, the Is passive flag is set to No indicating that the server being added is an active server in a cluster. Set this flag to No if a passive server is being added. In such a case, no alerts will be generated by the eG agent if the server is not running. Measures will be reported as "Not applicable' by the agent if the server is not up. However, the agent will continue to alert the administrator of operational issues with the server such as too many open sessions to the server, unusual lock behavior, etc.

  5. Port number:The port number (if any) on which the component is listening is displayed here. This cannot be changed.

  6. If the Component type is Oracle database, an additional field SID is provided. This field indicates the specific Oracle instances associated with the the host IP address and port number specified above.

  7. Moreover, where cluster monitoring is supported, eG Enterprise enables users to indicate at the time of component addition, whether the component being added is an active or passive server in the cluster. Currently, eG Enterprise is capable of monitoring the following cluster services: Oracle, MS SQL, Active Directory, and Exchange 2000/2003. This is why, while adding an Oracle database, Microsoft SQL, Active Directory, or Exchange 2000/2003 component, this page includes an additional Is passive flag. This flag is set to No by default, which implies that the component being added is an active server in a cluster, by default. If this flag is set to Yes, it indicates that the server being added is a passive server in a cluster. In this case, no alerts will be generated if the server is not running. Measures will be reported as "Not applicable' by the agent if the server is not up.

  8. If the Component type corresponds to one of the Microsoft web servers (e.g., IIS web server or IIS ssl server), an additional field called MTS enabled appears. The eG system's discovery process does not automatically discover Microsoft Transaction Servers (MTSs). Using the MTS enabled option, an administrator can specify whether an MTS server is executing on the same host as a Microsoft web server (IIS or IIS ssl). Using the Yes option, an administrator can associate an MTS server with the host that executes the Microsoft IIS web server or SSL server. If the administrator does not want to associate an MTS server with the IIS web server or SSL server host, he/she can choose the No option.

  9. Enable/disable agentless support for a component by choosing the Yes or the No option (as the case may be) from Agentless. If Yes is chosen, proceed to choose the OS. If the OS is a flavor of Unix, indicate whether your choice of Mode is Rexec or SSH, and accordingly, proceed with the configuration. Then, select the Remote agent that will monitor the component being modified.

    10. Note:

    A remote agent can monitor a maximum of 10 targets only.

  10. If Agentless is set to No, then, select either Auto or Manual from the Internal agent assignment field. Upon selecting Manual, you will be allowed to assign an internal agent to the specified Host/Nick name, by selecting an agent from the Internal agent list box.

  11. Finally, associate one or more External agent with the host, and click the Update button to register the changes.

    12. Note:

    When the SID of an existing server is changed, such changes need to be manually updated across the system. For example, if the SID of an Oracle server is changed and if that server is already a part of a segment topology, then you need to manually reconfigure the segment topology, so that the change takes effect.

  12. An ADDITIONAL INFORMATION section will appear when Manual option is chosen against the Virtual Topology mapping flag that appears in the VIRTUAL TOPOLOGY page. When one/more hypervisors are already monitored, you will have to explicitly indicate whether/not the application being added is executing on a virtual host, by checking the check box against the Virtual environment option. If you have checked the check box, you will have to additionally pick the managed virtual host with which that application is associated from the Virtual servers list.