|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | TEC | Recommended Links | Selected Docs | Installation |
| Gateway Troubleshooting | Tivoli State Correlation Engine | Event Adapters | Humor | Etc |
The Tivoli Enterprise Console gateway can receive events from adapters (TME and non-TME) and forwards events to the event server. It communicates with the event server using the Tivoli Event Integration Facility. The Tivoli Enterprise Console gateway is comprised of the tec_gateway and the tec_gwr programs.
The tec_gateway program processes events from TME adapters. The tec_gateway program and all of the necessary adapter files for each endpoint operating system are installed when the Adapter Configuration Facility is installed on a managed node. The Adapter Configuration Facility must be installed on any managed node that is configured as a Tivoli Enterprise Console gateway. For more information about the Adapter Configuration Facility, refer to the IBM Tivoli Enterprise Console Adapters Guide.
The tec_gwr program receives events from non-TME adapters and sends them to the tec_gateway program. The tec_gwr program is installed when a Tivoli Enterprise Console gateway adapter configuration profile is distributed to an endpoint using the Adapter Configuration Facility. The tec_gwr program is essentially an endpoint adapter that receives events from non-TME adapters. The tec_gwr program uses the LCF (endpoint) transport type to send events to the tec_gateway program in a manner similar to that of the SNMP and logfile endpoint adapters. By default, the Tivoli Enterprise Console gateway does not receive events from non-TME adapters. You can configure the Tivoli Enterprise Console gateway to receive events from non-TME adapters using a keyword in the Tivoli Enterprise Console gateway configuration file.
You can use the Tivoli Enterprise Console gateway as installed, or you can create a gateway configuration file. Gateway configuration file is /etc/Tivoli/tec/tec_gateway_config
#
# tec_gateway Configuration
#
ServerLocation=@EventServer
GatewaySendInterval=5
GatewayQueueSize=40000
BufEvtPath=/etc/Tivoli/tec/tec_gateway.cache
Pre37Server=no
#
You might want to configure the Tivoli Enterprise Console gateway for the following reasons:
To configure the Tivoli Enterprise Console gateway, modify the keywords in the gateway configuration file as appropriate. Then create and distribute an adapter configuration profile that contains the tec_gateway or the tec_gateway_sce profile. Use the tec_gateway_sce profile if you want to use state correlation at the Tivoli Enterprise Console gateway. For information about the gateway configuration file, see Gateway configuration file. For more information about using an adapter configuration profile, refer to the IBM Tivoli Enterprise Console Adapters Guide.
The Tivoli Enterprise Console gateway configuration file is optional and does not exist on the managed node until an adapter configuration profile containing the gateway configuration information is distributed to the endpoint on that managed node. The Tivoli Enterprise Console gateway uses default values unless you modify the keywords in the Tivoli Enterprise Console gateway configuration file and distribute an adapter configuration profile containing the changed gateway configuration information. Also, if you do not specify a value for a keyword, the default value is used.
The Tivoli Enterprise Console gateway uses one of the following configuration files:
/etc/Tivoli/tec/tec_gateway.conf
The configuration file defines the behavior of the Tivoli Enterprise Console gateway. For information about the common keywords for the configuration file, refer to the IBM Tivoli Enterprise Console Adapters Guide or the Tivoli Event Integration Facility Reference. The configuration file can also use the following custom keywords:
UNIX:
APPEND_CLASSPATH=/my_product/my_java.class:/my_product/my_jar.jar
For the tec_gateway program, the specified string is appended to the list of jar files used for state correlation. For a C Adapter, the specified string is appended to the CLASSPATH environment variable.
Assume that the ServerLocation and the BufEvtPath keywords are specified as follows:
ServerLocation=@EventServer#tmr-central
BufEvtPath=/etc/Tivoli/tec/gateway_cache
The Tivoli Enterprise Console gateway creates the /etc/Tivoli/ tec/gateway_cache@EventServer#tmr-central buffer file.
If the Tivoli Enterprise Console gateway receives an event from an adapter that specified server location as @EventServer#tmr-east, the Tivoli Enterprise Console gateway also creates a buffer file named /etc/Tivoli/tec /gateway_cache@EventServer#tmr-east.
The default value is one of the following:
UNIX: /etc/Tivoli/tec/cache@EventServer#region
Windows: $DBDIR/cache.dat@EventServer#region (on managed nodes)
$TIVOLIHOME/tec/$(AC_TYPE).cache@ EventServer#region (on endpoints)
The minimum value for this keyword is 4096 bytes. If the GatewayQueueSize keyword is set to a value lower than 4096, this keyword is set to 40000, which is the default.
The default interval is five seconds.
myEventServerHost:5529
To send service status events from the tec_gwr program to the tec_gateway program, set this keyword to SAME as follows:
gwr_ServiceServer=SAME
UNIX:
PREPEND_CLASSPATH=/my_product/my_java.class:/my_product/my_jar.jar
Windows:
PREPEND_CLASSPATH=\my_product\my_java.class;d:\my_product\my_jar.jar
For the tec_gateway program, the specified string is prepended to the list of jar files used for state correlation. For a C Adapter, the specified string is prepended to the CLASSPATH environment variable.
The RetryInterval keyword enables adapters to send all events to the primary event server even if the primary event server is stopped briefly, such as when loading a new rule base. If you use this option to wait for the event server to restart, set the value for a period of time longer than needed for the event server to be stopped and restarted.
The RetryInterval keyword is optional.
The default value is @EventServer.
You can specify multiple event server names as a comma-delimited list. Event server names later in the list can be backup event servers when the Tivoli Enterprise Console gateway cannot contact its primary event server for an event and the interval specified by the RetryInterval keyword has expired without successfully contacting the primary server. You can specify a host name as you would for a non-TME adapter, and the events are then forwarded to that host using non-Tivoli communication. For more information, see the examples in the description of the ServerPort keyword.
When the Tivoli Enterprise Console gateway cannot contact the adapter-specified event server, the event server names specified in the list are backup event servers. If ServerLocation is not present in the Tivoli Enterprise Console gateway configuration file, the Tivoli Enterprise Console gateway uses the default @EventServer value as the backup event server.
To prevent event delivery to backup event servers, set the ServerLocation keyword to NONE.
The default value is 0, which causes the portmapper daemon on the specified host to determine the port on which the event server is listening for incoming events. If you are forwarding events to a Tivoli Availability Intermediate Manager, you cannot specify 0 as the port because the Tivoli Availability Intermediate Manager does not register itself with the portmapper daemon.
If you specify a value for the ServerPort keyword, the value must be either a single port number or a comma-delimited list of port numbers that correspond to the list of event servers specified in the ServerLocation keyword. If you specify a single port number and you have specified multiple event servers in the ServerLocation keyword, all event servers use the port number specified.
Assume that you have a Tivoli Availability Intermediate Manager running on hosts aim.xyz.com and aimbkup.xyz.com, and the ServerLocation and the ServerPort keywords are specified as follows:
ServerLocation=aim.xyz.com,aimbkup.xyz.com,@EventServer
ServerPort=5530,5531,0
Events are sent to port 5530 on the host aim.xyz.com using non-Tivoli communication. If that fails, events are sent to port 5531 on the host aimbkup.xyz.com. If that also fails, events are sent directly to the event server in the local Tivoli region using Tivoli communication. The port value of 0 specified for @EventServer is ignored because port numbers are not needed when using Tivoli communication.
To configure the tec_gwr program to receive events receive events from non-TME adapters, set the value of the gwr_Enable keyword in the gateway configuration file to YES. The tec_gwr program listens on a socket port for incoming events from non-TME adapters. The port used must not be in use by another application, such as the event server.
If an event sent from the tec_gwr program to the tec_gateway program fails, the tec_gwr program resends the event when the gwr_RetryCount keyword is set to a value greater than or equal to 1. The tec_gwr program resends the event after waiting for the time period specified by the gwr_RetryInterval keyword. The number of retry attempts is equal to the value specified for the gwr_RetryCount keyword.
To configure non-TME adapters to use the IBM Tivoli Enterprise Console gateway, set the ServerLocation/channelServerLocation and the ServerPort/channelPort keywords in the configuration file of the adapter to the host name and port number that the tec_gwr program uses. If the tec_gwr program is not running on the same host as the event server, you can register the tec_gwr program with the portmapper daemon. To do this, set the value of the gwr_ReceptionPort keyword in the Tivoli Enterprise Console gateway configuration file to 0.
The Tivoli Enterprise Console product uses the following files to receive events from non-TME adapters:
To decrease the number of events that are sent to the event server, you can configure the Tivoli Enterprise Console gateway for state correlation. Using state correlation at the Tivoli Enterprise Console gateway to perform advanced filtering, duplication detection, and event correlation closer to the source off-loads filtering and event correlation from the event server.
For information about writing rules for state correlation, refer to the IBM Tivoli Enterprise Console Rule Developer's Guide.
Before you activate the state machine, ensure that you have written your rules based on the information described in the IBM Tivoli Enterprise Console Rule Developer's Guide.
Follow this procedure to run a state machine:
UseStateCorrelation=YES # for Windows NT only StateCorrelationConfigURL=file:C:\tmp\test.xml # for all other INTERPs # StateCorrelationConfigURL=file:///tmp/test.xml # SendEventPort=1234 # ReceiveAckPort=4321 # ReceiveEventPort=5678 # SendAckPort=8765
After the state machine is running, you can test whether state correlation is properly filtering events in the following ways:
At certain times, the number of events coming from endpoint adapters can overwhelm the Tivoli Enterprise Console gateway, the event server, and even the network. You can control the rate at which the Tivoli Enterprise Console gateway sends events to the event server using the EventSendThreshold, the BufferFlushRate, and the MaxGWCacheSizeMegs keywords in the Tivoli Enterprise Console gateway configuration file. The example in this section shows how to determine the values for the BufferFlushRate and EventSendThreshold keywords in the Tivoli Enterprise Console gateway configuration file to improve event server performance.
This example assumes that the event server processes an average of 120 events per second without degrading its performance. The example environment contains two Tivoli Enterprise Console gateways, where gateway A is responsible for Web commerce servers and gateway B is responsible for the secretaries' systems.
The values provided in this example can vary greatly from installation to installation, depending on how many events, adapters, and Tivoli Enterprise Console gateways are in a particular environment. Use the worksheets provided in Worksheets and calculations to collect and calculate the data for your environment. All numerical values are expressed in events per second, except where noted.
120 ÷ 2 = 60
The resulting value of 60 indicates the average number of events each Tivoli Enterprise Console gateway can send without overwhelming the event server. Continue with step 3 to obtain the adjusted values for the Tivoli Enterprise Console gateway send rate.
The EventSendThreshold keyword sets the maximum number of events per second that the Tivoli Enterprise Console gateway sends to the event server. Because gateway A forwards events from mission-critical systems, more gateway A events should be sent to the event server than gateway B events. Thus, the EventSendThreshold keyword for gateway A is set to 80 events per second. Gateway B has the EventSendThreshold keyword set to 40 events per second. This way, more gateway A events get to the event server.
The sum of the values for gateway A and gateway B must be less than or equal to the 120 events that the event server can process:
80 + 40 <= 120
Any events above the value specified for the EventSendThreshold keyword are stored in the cache on the Tivoli Enterprise Console gateway. To regulate the number of events being sent to the event server, the BufferFlushRate keyword controls the number of events per minute to be sent from the cache, when the gateway recovers a lost connection to the event server.
For gateway A, the BufferFlushRate keyword is set to 5400 events per minute (90 events per second), and for gateway B the keyword is set to 3000 events per minute (50 events per second). Thus at peak traffic times, the event server is receiving 140 events per second from both Tivoli Enterprise Console gateways:
90 + 50 = 140
Although 140 events per second is greater than the average capacity of the event server (120 events per second), the event server has the capability to process excess events during brief, intermittent periods of time.
Tip: Remember to convert events per second to events per minute before setting the value for the BufferFlushRate keyword.
Depending on the number of Tivoli Enterprise Console gateways and endpoints in your environment, you need to carefully consider the rates you specify for the keywords. For instance, an improper configuration might have multiple Tivoli Enterprise Console gateways sending events at the same rate, thus flooding the event server at the same time. See Gateway configuration file for details about these keywords.
Table 10 and Table 11 summarize the values for this example. You can use these tables as worksheets to assemble the values you measure and calculate for your environment. All numerical values are expressed in events per second, except where noted.
| Average Receive Rate | Expected Peak Rate for High Traffic |
|---|---|
| 120 | 140 |
| Event Send Rate | Adjusted Rate | EventSendThreshold | BufferFlushRate | |
|---|---|---|---|---|
| Gateway A | 60 | 80 | 80 | 5400 events per minute
(90 events per second) |
| Gateway B | 60 | 40 | 40 | 3000 events per minute
(50 events per second) |
| Total Events Sent to Event Server | 120 | 120 | 120 | 140 events per second |
The following are the calculations to control event traffic:
event server average rate >= gateway A events + gateway B events
EventSendThreshold = adjusted send rate for gateway
gateway A gateway B BufferFlushRate + BufferFlushRate <= event server peak rate
By default, the tec_gwr program is automatically started when the host starts. The tec_gwr program is automatically started when an adapter configuration profile containing the tec_gateway or tec_gateway_sce entry is distributed using the Adapter Configuration Facility. You can also manually start the tec_gwr program. Starting the tec_gwr program causes the tec_gwr program to reread the tec_gateway.conf configuration file and restart the daemons.
The tec_gwr program is automatically stopped when you distribute an adapter configuration profile that has the init.tec_gwr start command removed from the after-file-distribution actions. You can also manually stop the tec_gwr program.
To start the tec_gwr program manually, use one of the following commands:
init.tec_gwr start &
To obtain the status of the tec_gwr program on a UNIX system, use the init.tec_gwr command as follows:
init.tec_gwr status &
init.tec_gwr pid &
init.tec_gwr env &
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 15, 2008