||Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix|
|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
You might want to configure the Tivoli Enterprise Console gateway for the following reasons:
To control the number of events sent from an adapter, refer to the event filtering information in the IBM Tivoli Enterprise Console Adapters Guide.
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.Note:
To distribute a modified Tivoli Enterprise Console gateway adapter configuration profile to a managed node with a gateway installed, the managed node must also have an endpoint installed on it. When you distribute the adapter configuration profile, the subscriber must be the endpoint on that managed node.
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:
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:
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.Notes:
Assume that the ServerLocation and the BufEvtPath keywords are specified as follows:
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:
Windows: $DBDIR/cache.dat@EventServer#region (on managed nodes)
$TIVOLIHOME/tec/$(AC_TYPE).cache@ EventServer#region (on endpoints)Note:
To reduce network traffic and improve performance, filter events as close to the source as possible by specifying filter options in adapter configuration files. You can also use the Filter, FilterCache, FilterMode, and UseStateCorrelation keywords in the Tivoli Enterprise Console gateway configuration file.
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.
To send service status events from the tec_gwr program to the tec_gateway program, set this keyword to SAME as follows:
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.Notes:
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.Note:
When the ServerLocation keyword is used in conjunction with the TestMode=YES keyword, the ServerLocation keyword defines the path and the file name for logging events instead of the event server.
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:
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.Note:
Messages received on the socket are generated by non-TME adapters and must be in the correct format as defined by the Tivoli Event Integration Facility in the Tivoli Enterprise Console product. Other types of messages are discarded.
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|
|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 &
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site|
Last modified: March 12, 2019