Configuring and Montiroing Messaging Servers

Configuring and Montiroing Messaging Servers eg Enterprise v5.6

Restricted Rights Legend The information contained in this document is confidential and subject to change without notice. No part of this document may be reproduced or disclosed to others without the prior permission of eg Innovations, Inc. eg Innovations, Inc. makes no warranty of any kind with regard to the software and documentation, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Trademarks Microsoft Windows, Windows NT, Windows 2000, Windows 2003 and Windows 2008 are either registered trademarks or trademarks of Microsoft Corporation in United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Copyright 2012 eg Innovations, Inc. All rights reserved.

Table of Contents CONFIGURING AND MONITORING WEBSPHERE MQ SERVERS...1 1.1 CONFIGURING THE WEBSPHERE MQ SERVER...1 1.2 ADMINISTERING THE EG MANAGER TO WORK WITH A WEBSPHERE MQ SERVER...1 1.3 MONITORING THE WEBSPHERE MQ SERVER...4 1.4 TROUBLESHOOTING...4 1.4.1 Command List...9 CONFIGURING AND MONITORING THE FIORANO MQ SERVERS...11 2.1 CONFIGURING THE FIORANO MQ SERVER TO WORK WITH THE EG AGENT...11 2.2 ADMINISTERING THE EG MANAGER TO WORK WITH A FIORANO MQ SERVER...11 2.3 MONITORING THE FIORANO MQ SERVER...17 CONFIGURING AND MONITORING IPLANET/SUNONE MESSAGING SERVERS...18 3.1 CONFIGURING AN IPLANET / SUNONE MESSAGING SERVER TO WORK WITH THE EG AGENT...18 3.2 ADMINISTERING THE EG MANAGER TO WORK WITH AN IPLANET / SUNONE MESSAGING SERVER...22 3.3 MONITORING THE IPLANET / SUNONE MESSAGING SERVER...31 3.4 TROUBLESHOOTING...31 CONFIGURING AND MONITORING TIBCO EMS SERVERS...34 4.1 CONFIGURING A TIBCO EMS SERVER TO WORK WITH THE EG AGENT...34 4.2 ADMINISTERING THE EG MANAGER TO MONITOR A TIBCO EMS SERVER...35 4.3 MONITORING THE TIBCO EMS SERVER...39 CONFIGURING AND MONITORING WEBSPHERE MQ CLUSTER...40 5.1 ADMINISTERING THE EG MANAGER TO WORK WITH A WEBSPHERE MQ CLUSTER...40 5.2 MONITORING THE WEBSPHERE MQ CLUSTER...41 CONCLUSION...43

Table of Figures Figure 1.1: Viewing the list of unmanaged WebSphere MQ servers...2 Figure 1.2: Managing a WebSphere MQ server...3 Figure 1.3: Configuring the WebSphere MQ Channels test for a WebSphere MQ server...3 Figure 1.4: Opening the WebSphereMQ Explorer...5 Figure 1.5: Opening the Queue Managers...6 Figure 1.6: Opening the QueueManagerQueue1...7 Figure 1.7: Viewing the Properties of a Queue Manager...8 Figure 1.8: Setting the Online monitoring parameters to high...9 Figure 2.1: Viewing the list of unmanaged Fiorano MQ servers...12 Figure 2.2: Managing a Fiorano MQ server...12 Figure 2.3: A list of tests to be configured...12 Figure 2.4: Configuring the FMQ Topics test...13 Figure 3.1: Opening the Netscape Console...19 Figure 3.2: Logging in to the console...19 Figure 3.3: Selecting the Directory Server option...20 Figure 3.4: The Directory server window...20 Figure 3.5: The Configuration tab of the Directory server...21 Figure 3.6: Setting the Size limit...21 Figure 3.7: Setting the Look through limit...22 Figure 3.8: Viewing the list of unmanaged iplanet/sunone messaging servers...23 Figure 3.9: Managing an iplanet/sunone messaging server...23 Figure 3.10: A list of tests to be configured...24 Figure 3.11: Configuring the IMS POP test...24 Figure 3.12: Configuring the IMS POP Port test...25 Figure 3.13: Configuring the IMS IMAP Port test...25 Figure 3.14: Configuring the IMS LDAP Port test...26 Figure 3.15: Configuring IMS MTA test...26 Figure 3.16: Configuring the IMSDatabase Log File test...27 Figure 3.17: Configuring the IMS Users test...28 Figure 3.18: Modifying the Http test...29 Figure 4.1: Adding a Tibco EMS Server for monitoring...35 Figure 4.2: The list of unconfigured tests for the Tibco EMS server...35 Figure 4.3: Configuring the Tibco EMS Connections test...36 Figure 4.4: Configuring the Network Interfaces test for the Tibco EMS Server...37 Figure 5.1: Adding the WebSphere MQ Cluster...41 Figure 5.2: A segment containing the cluster service and the WebSphere MQ servers...41

Configuring and Monitoring WebSphere MQ Servers Chapter 1 Configuring and Monitoring WebSphere MQ Servers 1.1 Configuring the WebSphere MQ Server To enable the eg agent to monitor a WebSphere MQ server of versions 6 and below, the following jar files need to be copied from the [WebSphere MQ install directory/java/lib] directory to the <EG_INSTALL_DIR>/lib directory: a. com.ibm.mq.jar b. connector.jar c. com.ibm.mq.pcf.jar To enable the eg agent to monitor a WebSphere MQ 7.0 server, the following jar files need to be copied to the <EG_INSTALL_DIR>/lib directory: a. com.ibm.mq.jar b. com.ibm.mq.jmqi.jar c. com.ibm.mq.headers.jar d. com.ibm.mq.pcf.jar e. com.ibm.mq.commonservices.jar f. connector.jar After copying the jar files, remember to restart the eg agent. If MQ monitoring is done in an agentless manner, these jar files should be available on the remote agent that will perform the monitoring. 1.2 Administering the eg Manager to work with a WebSphere MQ Server To do the above, do the following: 1. Log into the eg administrative interface. 1

Configuring and Monitoring WebSphere MQ Servers 2. If a WebSphere MQ server is already discovered, then directly proceed towards managing it using the COMPONENTS - MANAGE/UNMANAGE page (Infrastructure -> Components -> Manage/Unmanage). However, if it is yet to be discovered, then run discovery (Infrastructure -> Components -> Discover) to get it discovered or add the Websphere MQ server manually using the ADD/MODIFY COMPONENTS page (Infrastructure -> Components -> Add/Modify). Remember that components manually added are managed automatically. Discovered components, however, are managed using the COMPONENTS - MANAGE/UNMANAGE page. Figure 1.1 and Figure 1.2 clearly illustrate the process of managing an WebSphere MQ server. For more details on managing components, refer to the Configuring and Monitoring Web Servers document. Figure 1.1: Viewing the list of unmanaged WebSphere MQ servers 2

Configuring and Monitoring WebSphere MQ Servers Figure 1.2: Managing a WebSphere MQ server 3. Next, try to sign out of the eg administrative interface. Upon doing so, a LIST OF UNCONFIGURED TESTS will appear prompting you to configure the tests pertaining to the server. 4. Click on the WebSphere MQ Channels test in the table to configure it. The following screen will then appear: Figure 1.3: Configuring the WebSphere MQ Channels test for a WebSphere MQ server 5. Configure the test by specifying the following information in the page depicted by Figure 1.3. a. TEST PERIOD - how often should the test be executed b. HOST - the host for which the test is to be configured c. PORT the port on which the specified HOST listens 3

Configuring and Monitoring WebSphere MQ Servers d. USER If you want to login as a specific MQ user to execute this test, then specify a valid user name in the USER text box. The test will fail if an invalid user name is specified here. If no such authentication is required, then this parameter can be set to 'none'. e. PASSWORD - If a specific USER is entered, then the password of that user has to be specified in the PASSWORD text box. f. CONFIRM PASSWORD - Confirm the password by retyping it in the CONFIRM PASSWORD text box. g. SERVERCONNCHANNEL - The name of the server connection channel for the WebSphere MQ server. The default value is "SYSTEM.DEF.SVRCONN". h. MQVERSION The version of the target WebSphere MQ Server that is to be monitored. 6. Finally, click the Update button to register the changes (see Figure 1.3). 7. Finally, sign out of the admin interface. 1.3 Monitoring the Websphere MQ Server To monitor the WebSphere MQ Server, do the following: 1. Login as a monitor / supermonitor user. 2. Click on the Components option in the menu bar, and select the Servers option from the Components menu. 3. From the Components page, click on the WebShere MQ Server for which you wish to view measurements. 1.4 Troubleshooting If none of the tests report measures, then check whether the following are in place: The root user should be a member of the mqm group The mqm user s primary group should be mqm group The eg agent s user should be a member of the mqm group If the WeSphereMqLocalQueues test and WebSphereMqChannels test are not reporting measures, then verify whether the following are in place: The command server for the particular queue manager you want to monitor should be started. To know whether the command server has been started or not, open the error_log file in the <EG_INSTALL_DIR>/agent/logs directory, and search for the following messages: ERROR MQLocalQueueTest: Please start the command server: strmqcsv saturn.queue.manager ERROR MQChannelTest: Please start the command server: strmqcsv saturn.queue.manager 4

Configuring and Monitoring WebSphere MQ Servers If these messages exist in the error log, it indicates that the command server has not been started. To start the command server, use the steps discussed below: From the command prompt, switch to the bin directory of the MQ install directory using the command: cd <MQM_INSTALL_DIR>/bin For example, cd /opt/mqm/bin Then, execute the following command from the bin directory:./strmqcsv <QUEUE_MANAGER_NAME> For example, if saturn.queue.manager is the name of the queue manager, then the command to start the command server will be:./strmqcsv saturn.queue.manager Make sure that the Online monitoring parameters of queues and channels are set to High. For this, follow the steps below: 1. Follow the menu sequence Start -> All Programs -> IBM WebSphere MQ - > Websphere MQ Explorer. ( see Figure 1.4) Figure 1.4: Opening the WebSphereMQ Explorer 5

Configuring and Monitoring WebSphere MQ Servers 2. Once the WebSphere MQ Explorer opens, you will find a Queue Managers node in the tree-structure in the left panel of the Explorer. ( see Figure 1.5). Figure 1.5: Opening the Queue Managers 3. Expand the Queue Managers node and right-click on the queue manager to be monitored to view a shortcut menu. (see Figure 1.6). 6

Configuring and Monitoring WebSphere MQ Servers Figure 1.6: Opening the QueueManagerQueue1 4. Choose Properties from the shortcut menu ( see Figure 1.7). 7

Configuring and Monitoring WebSphere MQ Servers Figure 1.7: Viewing the Properties of a Queue Manager 5. Now, in the Properties window, click on the Online monitoring option in the left panel. Then, make sure that Channel monitoring and Queue monitoring are set to High. 8

Configuring and Monitoring WebSphere MQ Servers Figure 1.8: Setting the Online monitoring parameters to high 1.4.1 Command List Given below is a random list of commands that you can use (as and when appropriate) to troubleshoot issues with MQ server monitoring: a. To create a queue manager and make it the default queue manager: crtmqm -q <Queue Manager Name> b. To start the default queue manager: strmqm c. To start a specific queue manager: strmqm <Queue Manager Name> d. To stop the default queue manager: endmqm e. To stop a specific queue manager: endmqm <Queue Manager Name> f. To delete a specific queue manager: dltmqm <Queue Manager Name> g. To view all the queue managers that have been configured, and their status: /opt/mqm/bin/dspmq h. The following command is used to issue MQSC commands. Note that no prompt appears after you execute this command. runmqsc i. To check a user s permissions: dspmqaut -m MQCAUXT1 -t qmgr -p eguser dspmqaut -m MQCAUXT1 -t qmgr -p eguser AMQ7077 9

Configuring and Monitoring WebSphere MQ Servers j. To set permissions: setmqaut 10

Configuring and Monitoring the Fiorano MQ Servers Chapter 2 Configuring and Monitoring the Fiorano MQ Servers This chapter will discuss the steps for configuring and monitoring a FioranoMQ server. 2.1 Configuring the Fiorano MQ Server to work with the eg Agent To monitor a Fiorano MQ Server, events generation in the Fiorano MQ Server should be enabled. The events are disabled by default. To enable them, include the flag ENABLE_EVENTS=TRUE in the server configuration file (server.cfg). This file can be found in the bin directory of the server. After making the above change, restart the server. When this is done, the events mechanism in the server will initialize and would be ready for publishing the events. 2.2 Administering the eg Manager to work with a Fiorano MQ Server To do the above, do the following: 1. Log into the eg administrative interface. 2. If a Fiorano MQ server is already discovered, then directly proceed towards managing it using the COMPONENTS - MANAGE/UNMANAGE page (Infrastructure -> Components -> Manage/Unmanage). However, if it is yet to be discovered, then run discovery (Infrastructure-> Components -> Discover) to get it discovered or add the Fiorano MQ server manually using the ADD/MODIFY COMONENTS page (Infrastructure -> Components -> Add/Modify). Remember that components manually added are managed automatically. Discovered components, however, are managed using the COMPONENTS - MANAGE/UNMANAGE page. Figure 2.1 and Figure 2.2 clearly illustrate the process of managing a FioranoMQ server. For more details on managing components, refer to the Configuring and monitoring Web Servers document. 11

Configuring and Monitoring the Fiorano MQ Servers Figure 2.1: Viewing the list of unmanaged Fiorano MQ servers Figure 2.2: Managing a Fiorano MQ server 3. Next, try to sign out of the eg administrative interface. Upon doing so, a LIST OF UNCONFIGURED TESTS will appear prompting you to configure the tests pertaining to the server (see Figure 2.3). Figure 2.3: A list of tests to be configured 12

Configuring and Monitoring the Fiorano MQ Servers 4. Click on the FMQ Topics test in the table to configure it. The following screen will then appear: Figure 2.4: Configuring the FMQ Topics test 5. Configure the test by specifying the following information in the page depicted by Figure 2.4: TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The port at which the host listens HOMEDIR The location of the directory in which the FioranoMQ server has been installed. For example, the HOMEDIR for a Windows installation of the FioranoMQ server will be of the following format: C:\PROGRA~1\Fiorano\FIORAN~1.0. The format for a Unix installation will be: /user/egurkha/fiorano/fioranomq7.0. SVRBINDIR The full path to the bin directory of the FioranoMQ server installation that contains the file ConnectionManager.xml in FioranoMQ server 6.0, or the FMQListeners.xml in the FioranoMQ 7.0. These files, which are required for starting the respective FioranoMQ servers, also help the test in determining the version number of the FioranoMQ server (whether 6 or 7). For example, the SVRBINDIR for a Windows installation of the server will be of the format: C:\PROGRA~1\Fiorano\FIORAN~1.0\bin. The format for Unix installations will be: /user/egurkha/fiorano/fioranomq7.0/bin. SERVERMODE - The mode in which the FioranoMQ server is running. This parameter can take any of the following values: a. tcp: In this mode, the FioranoMQ server accepts non-secure TCP connections. This is the default value for SERVERMODE parameter. b. ssljsse: In this mode, the FioranoMQ server accepts secure connections which are serviced using Sun's JSSE implementation. c. sslphaos: In this mode, the FioranoMQ server accepts secure TCP connections 13

Configuring and Monitoring the Fiorano MQ Servers and secure connections using Phaos. d. http: In this mode, the FioranoMQ server accepts non-secure HTTP connections. e. httpjsse: In this mode, the FioranoMQ server accepts secure HTTPS connections which are serviced using Sun's JSSE implementation. f. httpphaos: In this mode, the FioranoMQ server accepts secure HTTPS connections using Phaos. ADMINID - The user name of the FioranoMQ server's administrator. The default is "admin". ADMINPASSWORD The password corresponding to the specified admin user. CONFIRMPASSWORD - Confirm the password by retyping it here. ACF - ACF stands for Admin Connection Factory object. This object is used to obtain a handle to an Admin connection. Specify the name of an ACF object in this text box. TCF - TCF stands for Topic Connection Factory object. This object is used to set up a connection with the provider. Specify the name of a TCF object in this text box. TRUSTSTORE - The truststore or keystore database which the JVM uses to verify certificates. For example, this parameter can take the value c:\fioranomq\bin\jssecacerts, where jssecacerts is the truststore database which the JVM uses. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eg Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eg agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: o The eg manager license should allow the detailed diagnosis capability O Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0. 6. Finally, click the Update button to register the changes (see Figure 2.4). 7. Next, sign out of the admin interface. Now it will prompt you to configure the Processes test for Fiorano MQ server. Please refer to the Configuring and Monitoring Web servers document for a more elaborate discussion on how to configure the Processes test. To know the values for SERVERMODE, ACF and TCF parameters for a Fiorano MQ server 6.0, first, open the ConnectionManager.xml file in the <FIORANO_INSTALL_DIR>/bin directory. You will find the following section within: 14

Configuring and Monitoring the Fiorano MQ Servers <FMQConnectionFactories> <ClientConnectionFactories> <ConnectionFactoryInfo type="https_sun"> <URL>http://localhost:1856</URL> <SSLVendor>Sun</SSLVendor> <SecurityManager>fiorano.jms.ex.sm.def.DefaultJSSESecurityManager</SecurityM anager> <ConnectionManager> <ClassName>fiorano.jms.cm.def.SocketReadHandlerDefImpl</ClassName> </ConnectionManager> <ConnectionFactoryName fmq_type='topic'>primarytcf</connectionfactoryname> <ConnectionFactoryName fmq_type='topic'>secondarytcf</connectionfactoryname> <ConnectionFactoryName fmq_type='queue'>primaryqcf</connectionfactoryname> <ConnectionFactoryName fmq_type='queue'>secondaryqcf</connectionfactoryname> <ConnectionFactoryName fmq_type='unified'>primarycf</connectionfactoryname> </ConnectionFactoryInfo> </ClientConnectionFactories> <AdminConnectionFactories> <ConnectionFactoryInfo type="https_sun"> <URL>http://localhost:1857</URL> <SSLVendor>Sun</SSLVendor> <SecurityManager>fiorano.jms.ex.sm.def.DefaultJSSESecurityManager</SecurityM anager> <ConnectionManager> <ClassName> fiorano.jms.cm.def.socketreadhandlerdefimpl</classname> </ConnectionManager> <ConnectionFactoryName fmq_type='admin'>primaryacf</connectionfactoryname> </ConnectionFactoryInfo> </AdminConnectionFactories> </FMQConnectionFactories> 15

Configuring and Monitoring the Fiorano MQ Servers Note the lines in Bold. The first of these lines reads as follows: <ConnectionFactoryInfo type="https_sun">. If the ConnectionFactoryInfo type is HTTPS_SUN, then the SERVERMODE will be httpjsse. For the other SERVERMODES, the corresponding ConnectionFactoryInfo type will be: CONNECTIONFACTORYINFO TYPE HTTP HTTPS_PHAOS SUN_SSL PHAOS_SSL SERVERMODE http Httpphaos Ssljsse Sslphaos The next Bold line reads as follows: <ConnectionFactoryName fmq_type='topic'>primarytcf</connectionfactoryname>. Here, the term primarytcf indicates the name of the TCF object, and the same has to be provided as the TCF parameter. The last Bold line reads as follows: <ConnectionFactoryName fmq_type='admin'>primaryacf</connectionfactoryname>. Here, the term primaryacf indicates the name of the ACF object, and the same has to be provided as the ACF parameter. To know the values for SERVERMODE, ACF and TCF for a FioranoMQ server 7.0, open the AdminTool.xml file in the <FIORANO_INSTALL_DIR>/bin directory. You will find the following section within: <AdminToolCfg> <Param Name="LOG_MANAGER">fiorano.jms.log.def.LogManagerImpl</Param> <Param Name="REPEATER_ENABLED">yes</Param> <Param Name="REPEATER_TOPIC">REPEATER_QUERY_TOPIC</Param> <Param Name="REPEATER_REQUEST_TIMEOUT">10000</Param> <Param Name="ConfigurationTab">true</Param> <Param Name="showalltracecomponents">true</Param> <Param Name="TransportProtocol">HTTP</Param> <Param Name="SYSTEM_MESSAGESNOOPER_TOPIC">SYSTEM_MESSAGESNOOPER_TOPIC</Param> <Param Name="SYSTEM_MESSAGESNOOPER_QUEUE">SYSTEM_MESSAGESNOOPER_QUEUE</Param> <FioranoMQServer URL="http://localhost:1856"> <AdminCF Name="primaryACF"></AdminCF> <TopicCF Name="primarytcf"></TopicCF> <QueueCF Name="primaryqcf"></QueueCF> </FioranoMQServer> </AdminToolCfg> 16

Configuring and Monitoring the Fiorano MQ Servers Note the Bold lines. The first of these lines reads as follows: <Param Name="TransportProtocol">HTTP</Param>. If the TransportProtocol is HTTP then the SERVERMODE will be http. For the other SERVERMODES, the corresponding TransportProtocol will be: TRANSPORTPROTOCOL HTTPS_SUN HTTPS_PHAOS SUN_SSL PHAOS_SSL SERVERMODE httpjsse httpphaos ssljsse sslphaos The next Bold line reads as follows: <AdminCF Name="primaryACF"></AdminCF>. Here, the term primaryacf indicates the name of the ACF object, and the same has to be provided as the TCF parameter. The last Bold line reads as follows: <TopicCF Name = primarytcf ></TopicCF>. Here, the term primarytcf indicates the name of the TCF object, and the same has to be provided as the TCF parameter. 2.3 Monitoring the Fiorano MQ Server To monitor the Fiorano MQ server, do the following: 1. Login as a monitor / supermonitor user. 2. Click on the Components option in the menu bar, and select the Servers option from the Components menu. 3. From the COMPONENTS LIST page, click on the Fiorano MQ server being monitored. 17

Configuring and Monitoring iplanet/sunone Messsaging Servers Chapter 3 Configuring and Monitoring iplanet/sunone Messaging Servers This chapter guides users in configuring and monitoring the iplanet/sunone messaging servers. 3.1 Configuring an iplanet / SunONE Messaging Server to work with the eg Agent The eg agent on an iplanet/sunone messaging server executes an IMSUser test on the server, which reports key statistics pertaining to the user accounts that exist in a domain. The test retrieves the required user-specific statistics from the Directory server that has been configured for the messaging server. To ensure that the eg agent effectively executes this test, the following configurations are to be performed: 1. Open the Netscape Console using the menu sequence depicted in Figure 3.1. 18

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.1: Opening the Netscape Console 2. Since only an administrator can access the console, specify the admin User ID and Password (see Figure 3.2) to login to the console. Figure 3.2: Logging in to the console 3. Using the tree-structure in the left pane of the Netscape Console, drill down to the Directory Server node (since the Directory server contains the user information to be retrieved by the IMSUser test) as depicted by Figure 3.3, and double-click on it. 19

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.3: Selecting the Directory Server option 4. Upon double-clicking, Figure 3.4 will appear. Now, click on the Configuration tab in Figure 3.4. Figure 3.4: The Directory server window 5. In the Configuration tab (see Figure 3.5), select the top-most node (that represents the host name of the messaging server) of the tree-structure in the left pane. Doing so will reveal a series of tabs in the right pane (see Figure 3.5). 20

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.5: The Configuration tab of the Directory server 6. From the tabs in the right pane of Figure 3.6, select the Performance tab (see Figure 3.6). In this tab, set the Size limit parameter to -1. Size limit specifies the maximum number of entries to return from a search operation. -1 indicates that there is no limit. After resetting the parameter, click on the Save button to save the changes. Figure 3.6: Setting the Size limit 21

Configuring and Monitoring iplanet/sunone Messsaging Servers 7. Next, select the Database node from the tree structure in the left pane (Figure 3.7), and then click on the Performance tab in the right pane. Then, set the Look through limit parameter to -1. Look through limit specifies the maximum number of entries that the directory server will check when seeking candidate entries in response for a search request. -1 indicates that there is no limit. After resetting the parameter, click on the Save button to save the changes. Figure 3.7: Setting the Look through limit 3.2 Administering the eg manager to work with an iplanet / SunONE Messaging Server To do the above, do the following: 1. Log into the eg administrative interface. 2. If an iplanet/sunone messaging server is already discovered, then directly proceed towards managing it using the COMPONENTS - MANAGE/UNMANAGE page (Infrastructure-> Components -> Manage/Unmanage). However, if it is yet to be discovered, then run discovery (Infrastructure-> Components -> Discover) to get it discovered or add the messaging server manually using the ADD/MODIFY COMPONENTS page (Infrastructure-> Components -> Add/Modify). Remember that components manually added are managed automatically. Discovered components, however, are managed using the COMPONENTS - MANAGE/UNMANAGE page. Figure 3.8 and Figure 3.9 clearly illustrate the process of managing an iplanet/sunone messaging server. For more details on managing components, refer to Configuring and Monitoring Web Servers document. 22

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.8: Viewing the list of unmanaged iplanet/sunone messaging servers Figure 3.9: Managing an iplanet/sunone messaging server 3. Next, try to sign out of the eg administrative interface. Upon doing so, a LIST OF UNCONFIGURED TESTS will appear prompting you to configure the tests pertaining to the server (see Figure 3.10) 23

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.10: A list of tests to be configured 4. Click on the IMS POP test in the table to configure it. The following screen will then appear: Figure 3.11: Configuring the IMS POP test 5. The IMS POP test monitors the POP3 service supported by the iplanet messaging server. Configure the test by specifying the following information in the page depicted by Figure 3.11: TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet messaging server VERSION - This refers to the version number of the SunONE messaging server that is being monitored. By default, none will be displayed as the VERSION. If you are monitoring a SunONE messaging server that is of a version below 6.0, you need not change the default none value of this parameter. However, while monitoring version 6.0 or above, the exact version number needs to be explicitly mentioned against this parameter. SERVERROOT Specify the path to the directory into which all servers of a given server group (i.e., all servers managed by a given Administration Server) are installed. For example, in Windows environments, the path can be expressed as: C:\iplanet\server5. In Unix platforms, the path can be specified in the following format: /usr/iplanet/server5. A server group may include other iplanet servers in addition to the messaging server. COUNTERREGISTRY Enter the full path to the counter registry to use. By default, the path to the counter registry will be: <IPLANET_MESSAGING_SERVER_ROOT_DIR>/<SERVER_INSTANCE>/counter/counter. Here, SERVER_ROOT_DIR will be the value of the SERVERROOT parameter above, and the 24

Configuring and Monitoring iplanet/sunone Messsaging Servers SERVER_INSTANCE is the name of the instance of the iplanet messaging server specified during installation. For example, in Windows environments, the path specification can be: C:\iPlanet\Server5\msg-egtes\counter\counter, and in Unix environments, it can be: usr/iplanet/server5/msg-sun08/counter/counter. 6. Finally, click the Update button to register the changes (see Figure 3.11) 7. Now, try signing out of administrative interface. From the list of tests still to be configured, click on the IMS POP Port test. Figure 3.12 appears next. Figure 3.12: Configuring the IMS POP Port test 8. The IMS POP Port test monitors the availability and responsiveness of the TCP port of the iplanet messaging server's POP3 service. This test takes the following parameters (see Figure 3.12): TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet messaging server TARGETPORTS Specify the port at which the POP3 service of the iplanet messaging server listens. 9. Finally, click the Update button to register the changes (see Figure 3.12). 10. Now, try signing out of administrative interface. From the list of tests still to be configured, click on the IMS IMAP Port test. Figure 3.13 appears next. Figure 3.13: Configuring the IMS IMAP Port test 11. The IMS IMAP Port test monitors the availability and responsiveness of the TCP port of the iplanet messaging server's IMAP service. This test takes the following parameters (see Figure 3.13): TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured 25

Configuring and Monitoring iplanet/sunone Messsaging Servers PORT The SMTP port of the iplanet messaging server TARGETPORTS Specify the port at which the IMAP service of the iplanet messaging server listens. 12. Finally, click the Update button to register the changes (see Figure 3.13). 13. Now, try signing out of administrative interface. From the list of tests still to be configured, click on the IMS LDAP Port test. Figure 3.14 appears next. Figure 3.14: Configuring the IMS LDAP Port test 14. The IMS LDAP Port test monitors the availability and responsiveness of the TCP port of the LDAP server that is configured to work with the iplanet messaging server. This test takes the following parameters (see Figure 3.14): TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet messaging server TARGETPORTS Specify the port at which the LDAP server listens. 15. Finally, click the Update button to register the changes (see Figure 3.14). 16. Now, try signing out of administrative interface. From the list of tests still to be configured, click on the IMS MTA test. Figure 3.15 appears next. Figure 3.15: Configuring IMS MTA test 17. The IMS MTA test will report statistics related to the message traffic in channels. The test takes the following parameters (see Figure 3.15): TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet messaging server 26

Configuring and Monitoring iplanet/sunone Messsaging Servers VERSION - This refers to the version number of the SunONE messaging server that is being monitored. By default, none will be displayed as the VERSION. If you are monitoring a SunONE messaging server that is of a version below 6.0, you need not change the default value of this parameter. However, while monitoring version 6.0 or above, the exact version number needs to be explicitly mentioned against this parameter. INSTANCEDIRECTORY If you are monitoring a SunONE messaging server that is of a version below 6.0, then specify the full path to the directory that corresponds to the current messaging server instance. For example, in Windows environments, the path can be expressed as: C:\iPlanet\Server5\msg-egtest. In Unix platforms, the path can be specified in the following format: /usr/iplanet/server5/msg-sun08. On the other hand, if you are monitoring version 6.0 or above of a SunONE messaging server, then ensure that the SunONE messaging server's root directory is specified as the INSTANCEDIRECTORY. 18. Finally, click the Update button to register the changes (see Figure 3.15). 19. Now, try signing out of administrative interface. From the list of tests still to be configured, click on the IMDDatabase Log File test. Figure 3.16 appears next. Figure 3.16: Configuring the IMSDatabase Log File test 20. The iplanet messaging server instance message store contains a database (Berkley DB) that stores information about the mailboxes on the server, and stores quota information about the mailboxes. The IMSDatabase Log FileTest monitors the log files of the message store database. This test takes the following parameters (see Figure 3.16): TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet messaging server MBOXLISTPATH Specify the complete path to the "mboxlist" directory of the current instance of the messaging server. By default, this directory will be located within the "store" directory of the "messaging server instance directory". For example, the MBOXLISTPATH in Windows environments can be: C :\iplanet\server5\msg-egtest\store\mboxlist, and in Unix environments, it can be: /usr/iplanet/server5/msg-sun08/store/mboxlist. 21. Finally, click the Update button to register the changes (see Figure 3.16). 22. If you attempt to signout again, you will be prompted to configure the IMS Users test. This test monitors the user accounts that exist in the configured domains. 27

Configuring and Monitoring iplanet/sunone Messsaging Servers Figure 3.17: Configuring the IMS Users test 23. To configure the test, provide the following information in Figure 3.17: TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet/sunone messaging server SERVERROOT Specify the path to the directory into which all servers of a given server group (i.e., all servers managed by a given Administration Server) are installed. For example, in Windows environments, the path can be expressed as: C:\iplanet\server5. In Unix platforms, the path can be specified in the following format: /usr/iplanet/server5. A server group may include other iplanet servers in addition to the messaging server. CONFIGROOT - Specify the path to the directory in which the config root file "msg.conf" exists. By default, this file will be located within the "config" directory of the "current messaging server instance directory". For example, in Windows environments, the path can be expressed as: C:\iPlanet\Server5\msgegtest\config. In Unix platforms, the path can be specified in the following format: usr/iplanet/server5/msg-sun08/config. DOMAINS - specify the names of the domains hosted in the current messaging server instance. Multiple domains can be provided as a comma-separated list, but ensure that there is no space between a comma and a domain name. Example: chn.egurkha.com,eg.egurkha.com. Only the users present in the specified domains will be monitored. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eg Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eg agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: o o The eg manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed 28

Configuring and Monitoring iplanet/sunone Messsaging Servers diagnosis measures should not be 0. 24. Then, click on Update button (see Figure 3.17) to register changes, 25. If you attempt to signout again, you will be prompted to configure the Processes test and Mailtest for the iplanet messaging server. For more details on configuring the Processes test, refer to the Configuring and Monitoring Web Servers document. For details on configuring the Mail Test, refer to Configruing aand Monitoring Mail servers document. 26. By default, the Http test of an iplanet messaging server does not require manual configuration. However, its URL parameter would require a slight modification, if the iplanet messaging server does not use its default Http port. To modify this parameter, first, open the AGENTS - TESTS SPECIFIC CONFIGURATION page using the Agents -> Tests -> Configure ->Specific menu sequence. First choose SunONE Messaging from the Component type list box and the specific component from the Component name list box. Then choose type of a test say as Performance from the Test type list box. Doing so will provide the agent summary details and as well the configuration status of all the tests pertaining to the chosen component respectively. To reconfigure an configured test, select the Http test from the Tests with default configuration section of the CONFIGURED TESTS list box and click on the Reconfigure button. This will invoke the parameters to be configured for the chosen test. Figure 3.18: Modifying the Http test 29

Configuring and Monitoring iplanet/sunone Messsaging Servers 27. In the Figure 3.18 specify the following. TEST PERIOD how often should the test be executed URL the web page being accessed. While multiple URLs (separated by commas) can be provided, each URL should be of the format URL name:url value. URL name is a unique name assigned to the URL, and the URL value is the value of the URL. For example, a URL can be specified as HomePage:http://192.168.10.12:7077/, where HomePage is the URL name and http://192.168.10.12:7077/ is the URL value. HOST - the host for which the test is to be configured. PORT - the port number on which the specified HOST listens COOKIEFILE whether any cookies being returned by the web server need to be saved locally and returned with subsequent requests PROXYHOST the host on which a web proxy server is running (in case a proxy server is to be used) PROXYPORT the port number on which the web proxy server is listening PROXYUSERNAME The user name of the proxy server PROXYPASSWORD The password of the proxy server CONFIRM PASSWORD Confirm the PROXYPASSWORD by retyping it here. CONTENT is a set of instruction:value pairs that are used to validate the content being returned by the test. If the CONTENT value is none:none, no validation is performed. The number of pairs specified in this text box, must be equal to the number of URLs being monitored. The instruction should be one of Inc or Exc. Inc tells the test that for the content returned by the web server to be valid, the content must include the specified value (a simple string search is done in this case). An instruction of Exc instructs the test that the server's output is valid if it does not contain the specified value. In both cases, the content specification can include wild card patterns. For example, an Inc instruction can be Inc:*Home page*. An Inc and an Exc instruction can be provided in quick succession in the following format: Inc:*Home Page*,Exc:*home CREDENTIALS The HttpTest supports HTTP authentication. The CREDENTIALS parameter is to be set if a specific user name / password has to be specified to login to a page. Against this parameter, the URLname of every configured URL will be displayed; corresponding to each listed URLname, a Username text box and a Password text box will be made available. If the web server on which HttpTest executes supports 'Anonymous user access', then this parameter will take either of the following values: i. a valid Username and Password for every configured URLname ii. iii. none in both the Username and Password text boxes of all configured URLnames (the default setting), if no user authorization is required Some IIS web servers however, support NTLM (Integrated Windows) authentication, where valid CREDENTIALS are mandatory. In other words, a none:none specification will not be supported by such IIS web servers. Therefore, in this case, against each configured URLname, you will have to provide a valid Username in the format: domainname\username, followed by a valid Password. NTLM authentication is supported from JRE1.4.2_02 only, 30

Configuring and Monitoring iplanet/sunone Messsaging Servers which will not work directly with version 3.3 of the eg Enterprise suite. To ensure that eg 3.3 supports NTLM, do the following: iv. Rename \egurkha\jre (say, \egurkha\jre1.3.1_18). v. Install JRE 1.5 in the system where HttpTest executes. vi. vii. viii. ix. Copy the JRE folder to the \egurkha folder and rename it as JRE. This will set the egurkha JRE environment to 1.5. In debugon.bat and debugoff.bat, change the js -install egurkhaagent E:\eGurkha\JRE\bin\client\hotspot\jvm.dll to js -install egurkhaagent E:\eGurkha\JRE\bin\client\jvm.dll. Run either the debugon.bat or debugoff.bat. Restart the agent. Please be sure to check if your web site requires HTTP authentication while configuring this parameter. HTTP authentication typically involves a separate popup window when you try to access the page. Many sites use HTTP POST for obtaining the user name and password and validating the user login. In such cases, the username and password have to be provided as part of the POST information and NOT as part of the CREDENTIALS specification for the HTTP test. TIMEOUT - Here, specify the maximum duration (in seconds) for which the test will wait for a response from the server. The default TIMEOUT period is 30 seconds. 28. By default, the URL text box will display HomePage:http://iplanetmessagingserverIPorhostname:defaultportoftheHttpserver/. For example, if the IP of the iplanet messaging server is 192.168.10.47, then the URL displayed will be - HomePage:http://192.168.10.47:80/, where "80" is the default port of an HTTP server. If the Http port of the iplanet messaging server is not "80", then you need to change the port in this display, accordingly. In other words, if "81" is the Http port of the iplanet messaging server, then you need to change the URL to HomePage:http://192.168.10.47:81/. 29. Click the Update button in Figure 3.18 to register the changes, and finally, sign out of the administrative interface. 3.3 Monitoring the iplanet / SunONE Messaging Server To monitor the iplanet/sunone messaging server, do the following: 1. Login as a monitor / supermonitor user. 2. Click on the Components option in the menu bar, and select the Servers option from the Components menu. 3. From the Components page, click on the iplanet/sunone messaging server being monitored. 3.4 Troubleshooting The tests that the eg agent executes on a SunONE Messaging server extract performance data from the server by issuing some commands. At any given point in time, you can verify the authenticity of the metrics displayed in the monitoring console, by issuing the corresponding 31

Configuring and Monitoring iplanet/sunone Messsaging Servers command from the command prompt. The key tests executed on the SunONE Messaging server, and the command that each of these tests use for extracting the metrics, are discussed below. Note that you will need 'root user permissions' to execute all these commands. If the IMSMsgQueue test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o <SERVER_ROOT_DIR>/sbin/imsimta qm summarize -directory_tree -noheading -held, where the <SERVER_ROOT_DIR> refers to the value that you have passed to the SERVERROOT parameter of this test. If the IMSMta test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o <SERVER_ROOTDIR>/sbin/imsimta counters -show -noassociations, where the <SERVER_ROOT_DIR> refers to the value that you have passed to the SERVERROOT parameter of this test. If the IMSStoreLock test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o o <SERVER_ROOTDIR>/sbin/counterutil -o db_lock -r <COUNTERREGISTRY> -n 1, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. o <COUNTERREGISTRY> - refers to the value specified against the COUNTERREGISTRY parameter of this test If the IMSStoreTxn test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o o <SERVER_ROOT_DIR>/sbin/counterutil -o db_txn -r <counterregistry> -n 1, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. o <COUNTERREGISTRY> - refers to the value specified against the COUNTERREGISTRY parameter of this test If the IMSUser test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o o o <SERVER_ROOT_DIR>/sbin/imquotacheck -d <DOMAIN>, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. <DOMAIN> - refers to any of the domain names specified against the DOMAINS parameter of this test If the IMSHttp test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: 32

Configuring and Monitoring iplanet/sunone Messsaging Servers o o < SERVER_ROOT_DIR>/sbin/counterutil -o httpstat -r <COUNTERREGISTRY> -n 1, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. o <COUNTERREGISTRY> - refers to the value specified against the COUNTERREGISTRY parameter of this test If the IMSImap test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o o < SERVER_ROOT_DIR>/sbin/counterutil -o imapstat -r <COUNTERREGISTRY> -n 1, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. o <COUNTERREGISTRY> - refers to the value specified against the COUNTERREGISTRY parameter of this test If the IMSPop test is not reporting measures, then issue the following command from the command prompt, to check whether the desired measures are retrieved: o o < SERVER_ROOT_DIR>/sbin/counterutil -o popstat -r <COUNTERREGISTRY> -n 1, where, <SERVER_ROOT_DIR> - refers to the value that you have passed to the SERVERROOT parameter of this test. o <COUNTERREGISTRY> - refers to the value specified against the COUNTERREGISTRY parameter of this test 33

Configuring and Monitoring Tibco EMS Servers Chapter 4 Configuring and Monitoring Tibco EMS Servers This chapter guides users in configuring and monitoring the Tibco EMS servers. 4.1 Configuring a Tibco EMS Server to work with the eg Agent Prior to monitoring the Tibco EMS server, you will have to build a.bat or.sh file (depending upon the operating system on which Tibco EMS is functioning) bundled with the commands that the eg agent needs to execute on the Tibco EMS server for collecting the required metrics. The commands to be invoked by the the.bat or.sh file are as follows: tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show server tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show durables tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show queues tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show topics tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show connections For instance, if the IP address of your Tibco EMS server is 192.168.10.28 and its port is say, 9090, then a sample command in the.bat or.sh file would be: tcp://192.168.10.28:9090 show server The.bat/.sh file so created can be saved to any location on the Tibco EMS host. Then, while configuring this test, make sure you provide the full path to this.bat or.sh file in the 34

Configuring and Monitoring Tibco EMS Servers COMMANDPATH text box so that, the agent can execute the file, invoke the commands bundled into it, and extract the desired metrics from the server. 4.2 Administering the eg Manager to Monitor a Tibco EMS Server The steps in this direction are as follows: 1. Login to the eg administrative interface. 2. Add the Tibco EMS server to be monitored using the NEW COMPONENT DETAILS page that appears when the menu sequence: Infrastructure -> Components -> Add/Modify. Figure 4.1 will then appear using which you can provide the details of the new server. Figure 4.1: Adding a Tibco EMS Server for monitoring 3. Then, try to sign out of the eg administrative interface. Doing so will invoke a list of unconfigured tests for the Tibco EMS server. Figure 4.2: The list of unconfigured tests for the Tibco EMS server 4. Click on the Tibco EMS Connections test to configure it. Figure 4.3 will then appear. 35

Configuring and Monitoring Tibco EMS Servers Figure 4.3: Configuring the Tibco EMS Connections test 5. The Tibco EMS Connections test monitors the user activity on the EMS server, and reports the number of connections and sessions initiated by each user on the server. The users with the maximum number of open sessions on the server can thus be quickly identified and their activities closely tracked. To configure this test, specify the following in Figure 4.3: TEST PERIOD How often should the test be executed HOST - The host for which the test is being configured PORT The SMTP port of the iplanet/sunone messaging server COMMANDPATH Prior to monitoring the Tibco EMS server, you will have to build a.bat or.sh file (depending upon the operating system on which Tibco EMS is functioning) bundled with the commands that the eg agent needs to execute on the Tibco EMS server for collecting the required metrics. The commands to be invoked by the the.bat or.sh file are as follows: tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show server tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show durables tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show queues tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show topics tcp://{ipaddressorhostname_of_tibcoems}:{portnumber_of_tibcoems} show connections For instance, if the IP address of your Tibco EMS server is 192.168.10.28 and its port is say, 9090, then a sample command in the.bat or.sh file would be: 36

Configuring and Monitoring Tibco EMS Servers tcp://192.168.10.28:9090 show server The.bat/.sh file so created can be saved to any location on the Tibco EMS host. Then, while configuring this test, make sure you provide the full path to this.bat or.sh file in the COMMANDPATH text box so that, the agent can execute the file, invoke the commands bundled into it, and extract the desired metrics from the server. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eg Enterprise system embeds an optional detailed diagnostic capability. With this capability, the eg agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option against DETAILED DIAGNOSIS. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: o The eg manager license should allow the detailed diagnosis capability o Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0. 6. Finally, click the Update button in Figure 4.3, and then proceed to sign out again. This time you willl be prompted to configure the Network Interfaces test of the target Tibco EMS server. Figure 4.4: Configuring the Network Interfaces test for the Tibco EMS Server 37

Configuring and Monitoring Tibco EMS Servers 7. Specify the following in Figure 4.4: TEST PERIOD - How often should the test be executed HOST The IP address of the Cisco Router. Ensure that the specified HOST is SNMP-enabled. If not, the test will not function. SNMPPORT - The default SNMP port is 25. SNMPVERSION By default, the eg agent supports SNMP version 1. Accordingly, the default selection in the SNMPVERSION list is v1. However, if a different SNMP framework is in use in your environment, say SNMP v2 or v3, then select the corresponding option from this list. SNMPCOMMUNITY The SNMP community name that the test uses to communicate with the target server. This parameter is specific to SNMP v1 and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter will not appear. USEEXTENSION - By default, this test polls the standard IF MIB (RFC 1213) to collect the required metrics. Set the USEEXTENSION flag to Yes, if you want the test to poll the Interfaces Group MIB (RFC 2233) for metrics collection. By default this parameter is set to No. TIMEOUT Specify the duration (in seconds) within which the SNMP query executed by this test should time out in the TIMEOUT text box. The default is 10 seconds. ONLYUP If the ONLYUP flag is set to Yes, then only the network interfaces that are operational - i.e. whose MIB-II operstatus variable has a value "up" - are monitored. If this flag is set to No, all network interfaces that have an adminstatus of "up" will be monitored. By default, this flag is set to No, indicating that by default the test will monitor network interfaces that are up/down. FULLDUPLEX - If this value is Yes, then it indicates that all interfaces are full duplex. In this case, the eg Enterprise system will compute bandwidth usage % to be, max(input bandwidth, output bandwidth)*100/total speed. On the other hand, if this flag is set to No, then the computation of bandwidth usage % will be (input bandwidth + output bandwidth)*100/total speed. EXCLUDE - The EXCLUDE text box takes a comma separated list of network interfaces that are to be excluded when performing the test. E.g., if this parameter has a value of "Null0", then the Null0 interface of the network device will not be monitored by the eg agent. DISCOVERBYSTATE This flag controls how the test discovers network interfaces. If this flag is No, the operational state of an interface is not considered when discovering all the network interfaces of a router/switch/network device. If this flag is Yes(which is the default setting), only interfaces that have been in the up operational state will be considered for monitoring. In this mode, if an interface is down all of the time, it will not be considered for monitoring. However, once the interface starts to function, it will be tracked by the test and alerts generated if the interface state ever changes to down. USEALIAS and SHOW ALIAS AND INTERFACE NAME - Cisco and many network devices allow administrators to set the names for switch/router ports. These names can be set to logical, easily understandable values. Port names can be set in Cisco devices using the command "set port name". For example set port name 3/24 Federal_credit_union_link. This command indicates that the port 3/24 is used to support the Federal Credit Union. If the USEALIAS parameter is set to Yes, then a SHOW ALIAS AND INTERFACE NAME parameter will additionally appear, which is set to 38

Configuring and Monitoring Tibco EMS Servers No by default. In this case, the agent will first try to look at the port name (from the ifalias SNMP OID) and use the port name if specified as the descriptor for the test results. If a port name is unavailable or if no port name/alias is specified in the network device setting, the interface description for each port provided in the SNMP MIB-II output is used instead as the descriptor for the test results. On the other hand, if the USEALIAS parameter is set to Yes and the SHOW ALIAS AND INTERFACE NAME parameter is set to Yes, then each descriptor of this test will be represented in the format port name:interface description.for e.g., 1:local_lan_segment:GigabitEthernet 0/0. If the USEALIAS parameter is set to No, then the SHOW ALIAS AND INTERFACE NAME parameter option will not appear. In this case therefore, the device name will be displayed as the descriptor of the test. DD FREQUENCY - Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD FREQUENCY. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eg Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eg agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: o o The eg manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0. 8. Finally, click the Update button in Figure 4.4 to save the changes. If now try to exit the eg administrative interface, you will be prompted to configure the Processes test. For more details on configuring the Processes test, refer to the Configuring and Monitoring Web Servers document. 9. Once the Processes test is configured, signout of the eg administrative interface. 4.3 Monitoring the Tibco EMS Server The steps in this direction are as follows: 1. Login to the eg monitoring interface. 2. Locate the Tibco EMS component-type in the Components At-A-Glance section, and click on it. 3. All the monitored components of the chosen type will then be listed in the COMPONENT LIST page. Click on the Tibco EMS server of interest to you to view its layer model, tests, and measurements. 39

Configuring and Monitoring the WebSphere MQ Cluster Chapter 5 Configuring and Monitoring WebSphere MQ Cluster When two or more WebSphere MQ servers exist in an environment, they can be grouped together to form a WebSphere MQ cluster. Requests to a cluster are routed through a virtual cluster server that is assigned a cluster IP address and TCP port. Requests to this server can be handled by any of the individual nodes in the cluster at any given point in time, depending on which node is active at that time. Since clusters are deployed in environments where 24*7 availability and responsiveness are critical, it is imperative that the performance of the clusters is monitored all the time. 5.1 Administering the eg Manager to work with a WebSphere MQ Cluster To monitor a WebSphere MQ Cluster, an eg external agent is deployed, which emulates a user request on the cluster to determine the availability of the cluster and the speed with which the cluster responds to the emulated request. The emulated requests are directed at the virtual cluster server. Therefore, you need to manage the virtual cluster server as a WebSphere MQ Cluster using the eg administrative interface. To achieve the same, do the following: 1. Login to the administrative interface as an administrator (admin). 2. Add the virtual cluster server in your environment as the WebSphere MQ cluster service using the ADD/MODIFY COMPONENTS page (Infrastructure -> Components -> Add/Modify). This process is depicted by Figure 5.1 below. 40

Configuring and Monitoring the WebSphere MQ Cluster Figure 5.1: Adding the WebSphere MQ Cluster 3. Next, manage/manually add the individual WebSphere MQ servers that form part of the cluster. Please refer to section 1.2 above for a more elaborate discussion on how to manage a WebSphere MQ server. 4. Then, configure a new segment, where the WebSphere MQ Cluster shares a USES relationship with all the individual WebSphere MQ servers in the cluster (see Figure 5.2). The cluster service is deemed healthy if the user requests are served by at least one of the servers in the cluster. Figure 5.2: A segment containing the cluster service and the WebSphere MQ servers 5. Ensure that an external agent monitors the WebSphere MQ Cluster, and internal agents are deployed on the individual WebSphere MQ servers in the cluster to monitor their internal operations. 6. Once configured, signout of the eg administrative interface. 5.2 Monitoring the WebSphere MQ Cluster 1. Login as a monitor / supermonitor user. 2. Select the SEGMENTS option from the eg monitor menu, and click on the segment representing the WebSphere MQ cluster that you had previously configured; then, click on the WebSphere MQ Cluster component in the segment to view its measurements, Layer model and tests of the WebSphere MQ Cluster. 41

Configuring and Monitoring the WebSphere MQ Cluster For an in-depth discussion on eg Enterprise's Cluster Monitoring capabilities and to understand the implications of cluster availability on service performance, refer to the Monitoring Clusters Using eg Enterprise chapter (Chapter 7) in the eg User Manual. 42

Conclusion Chapter 6 Conclusion This document has described in detail the steps for configuring and monitoring the Messaging Servers. For details of how to administer and use the eg Enterprise suite of products, refer to the user manuals. We will be adding new measurement capabilities into the future versions of the eg Enterprise suite. If you can identify new capabilities that you would like us to incorporate in the eg Enterprise suite of products, please contact support@eginnovations.com. We look forward to your support and cooperation. Any feedback regarding this manual or any other aspects of the eg Enterprise suite can be forwarded to feedback@eginnovations.com. 43