Keywords in trap_mgr.conf lists and describes keywords that you can set in your local trap_mgr.conf.
Keyword |
Description |
Option or format |
---|---|---|
BATCH_NOTIFY_INTERVAL |
Allows you to set an interval (in seconds) to batch updates to notifications. In case, where a high frequency of notifications occurs, batching improves performance. To disable batching, set this interval to 0. For example: BATCH_NOTIFY_INTERVAL = 10 |
Any integer |
CACHE_HOSTS |
Note:
Use this CACHE_HOSTS keyword only if the “RESOLVE_IP” keyword is TRUE. Allows you to determine whether the system hosts will be cached and used to resolve IP addresses instead of calling the system functions, which may be slow in some cases.
Note:
This is ONLY useful if DNS name resolution is disabled in the environment. This is sometimes done to improve performance, but it requires an extensive hosts table. By altering the “HOSTS_PATH” keyword, you can use a special file to load the hosts cache instead of using the same hosts file used by the system that the trap processor is running on. For example: CACHE_HOSTS = FALSE |
TRUE or FALSE |
DEBUG |
Allows you to generate status messages, which you can use to debug the trap processor—without updating the trap_mgr_parse.asl. When DEBUG is set to TRUE in your local trap_mgr.conf, verbose status messages are generated, and your trap processor runs slower while the log grows faster. For example: DEBUG = FALSE |
TRUE or FALSE |
HOSTS_PATH |
Note:
Use this HOSTS_PATH keyword only if “CACHE_HOSTS” is TRUE. Allows you to define the full path to the system hosts file. (You can use a unique file for the cache by specifying its path here.) For example: HOSTS_PATH = /etc/hosts |
Path name |
IMPORT |
Allows you to access external information or processes for processing traps—without editing ASL scripts. You can use the IMPORT keyword in your local trap_mgr.conf to load tables, or any other pre-processor driver scripts. To load import drivers and lookup tables, you can replicate the IMPORT keyword as many times as necessary. For example: IMPORT TRUE TRUE driver1 import_rules.asl local/conf/someinput.txt | |
The format is as follows: IMPORT <wait> <auto-reload> <driver-name> <rules-file> [<input-file>] ... [<field-separator>] where:
|
LOGGING |
Allows you to generate status messages, which you can use to capture information about the trap processor. When LOGGING is set to OFF, for example, in your local trap_mgr.conf, error messages are generated and sent to the log file. For example: LOGGING = OFF |
ALL, DISCARD, STATUS, and OFF:
|
LOOKUP |
Allows you to substitute one value for another in the trap processor—without editing ASL scripts. You can use the LOOKUP keyword in your local trap_mgr.conf to substitute values. For example: LOOKUP MyTable local/lookups/filename In this example, filename contains: abcd1234:Alexandria stuvwxyz:Hopkinton If the trap definition in your trap_mgr.conf includes: UserDefined1: $MyTable($SYS$)$ Then, if SYS contains abcd1234, then UserDefined1 returns the value Alexandria. If SYS contains stuvwxyz, then UserDefined1 returns the value Hopkinton. Other examples include: $TABLE1($V4$)$; $TABLE2($SYS$[4])$ $TABLE2(coldStart[1])$ |
Available formats include:
where:
|
RESOLVE_IP |
Allows you to resolve IP addresses into their names. You can use this option to determine whether unrecognized IP addresses will be resolved before being assigned to the $SYS$ variable. For objects already known to the system, this option has no effect.
Note:
Name resolution can be very slow. A system receiving thousands of traps and calling a name server for every request can seriously impact the number of traps that can be processed. Threading can help somewhat, but name resolution is not recommended in large installations unless the server is configured to use only host file resolution and the “CACHE_HOSTS” keyword is defined. Alternatively, a caching DNS server can be run on the trap host to help somewhat, but performance will still be impacted. For example: RESOLVE_IP = FALSE |
TRUE or FALSE |
USE_CURRENT_TIME |
Allows you to set the timestamp for notifications—using either the time contained in the trap, or the time the trap was received. If this keyword is set to FALSE, then the timestamp from the trap is used unless it is invalid. If this option is set to TRUE, the timestamp from the trap is discarded, and the current time is used when creating notifications.
Note:
When using threads, traps can appear to come in out of order if this keyword is enabled. CLEAR traps are reordered, but other traps appear to occur at the time they were processed. For example: USE_CURRENT_TIME = FALSE |
TRUE or FALSE |