Additional readme information associated with the TPTP Generic Log Adapter is available in the TPTP V3.3 release notes.
When the Generic Log Adapter is continuously monitoring a log file it will not process the last record if there is no end pattern specified. The last record will only be processed when the Generic Log Adapter is shutting down.
To ensure that the last record is processed during monitoring, provide an end pattern for the records in the Generic Log Adapter configuration file.
When parsing the WebSphere Application Server binary activity or service logs on UNIX® platforms using the Generic Log Adapter, the user must have equal or greater privileges than the installer of WebSphere Application Server.
To work around this limitation, the binary activity or service log should be moved to a directory with the same privileges as the user of the Generic Log Adapter before parsing the log.
When parsing WebSphere MQ Error logs on UNIX platforms using the Generic Log Adapter, the user must have equal or greater privileges than the installer of WebSphere MQ.
To work around this limitation, move the MQ Error logs to a directory with the same privileges as the user of the Generic Log Adapter before parsing the logs.
When trying to use the runregex_showlog_example.bat and the runregex_showlog_example.sh to parse a WebSphere Application Server activity log, the WebSphere Application showlog utility cannot be found.
To work around this problem, edit the file regex_showlog_example.adapter in the rule editor and update the Sensor Converter property to point to the proper directory location of WebSphere Application Server.
Parsing some logs generates incorrect time zone information.
Only log files with timestamps containing time zone information will produce parsed data with creationTime values having the correct time zone. If the timestamps in a log files do not contain time zone information the Generic Log Adapter will generate creationTime values with incorrect time zone information.
The Generic Log Adapter will generate an invalid extendedDataElements Common Base Event element for a log record if there is no rule that matches for either the name or type value. The extendedDataElement should not be generated if there is no name or type parsed from the log record but the Generic Log Adapter will generate one with the value field only.
To work around this problem, ensure that rules are supplied that will cause all three fields - name, value, type - of the extendedDataElement to be matched.
Unzipping runtime.zip and rules.zip on z/OS sometimes produces unreadable script files.
To avoid this problem, ensure the procedure below is followed when unzipping runtime.zip and rules.zip on a z/OS system.
unzip -a runtime.zip unzip -a rules.zip unzip -o rules.zip *.adapter unzip -o runtime.zip *.xsd
When Generic Log Adapter executes outside an Eclipse environment, it logs messages and errors to a file called hgla.log. When executing in standalone mode, the hgla.log file will be created in the current working directory. When executing as part of a remote log import operation using Log and Trace Analyzer, the hgla.log file will be located on the remote system in the temporary directory as specified in the SYS_TEMP_DIR variable in the Agent Controller configuration file serviceconfig.xml. For example, the hgla.log file will be located in /tmp or /var/tmp directory if running on a UNIX or Linux™ system or in c:\Documents and Settings\userid\Local Settings\Temp if running on a Windows system.
When executing inside an Eclipse environment, for example as part of a local log import operation using Log and Trace Analyzer, Generic Log Adapter logs messages and errors to the hgla.log file in the .metadata\.plugins\org.eclipse.hyades.logging.adapter directory in the Eclipse workspace directory.
Generic Log Adapter logs events with logging levels 10, 20, 30, 50 and 60. The hgla.log file can be imported into Log and Trace Analyzer to diagnose problems encountered by Generic Log Adapter when parsing the log file.
No validation is done by Generic Log Adapter to determine if the type of log file being parsed matches the adapter file configuration. For example, if the log file specified in the sensor configuration in the adapter file is not of the type that the extractor configuration and substitution rules in the parser configuration were designed for, unpredictable results may occur. The parsing may succeed without error but the resulting Common Base Event data will be incorrect. The parsing may fail with error messages indicating incorrect data was encountered.
To work around this problem, ensure that the log file specified in the sensor component configuration is of the correct type.
When parsing binary WebSphere Application Server activity log files on non-English machines using runregex_showlog_example.bat/sh, the log record data will not be mapped successfully to a Common Base Event. Instead, some log record data may appear in the incorrect field of the Common Base Event.
When parsing log files that contain timestamps in a locale different than the locale that Generic Log Adapter is executing in, using a rules-based adapter file configured to use the Time Format attribute in the substitution rule for creationTime, the timestamp and other log record data may not be parsed correctly. For example, when parsing an English IBM HTTP Server access log file on a Japanese machine using config\IHS\access\v1.3.19.3\runregex_example.bat/sh, the creationTime values in the resulting Common Base Events will have a value of zero and the Common Base Event msg field will be blank.
To work around this problem, change the runregex_example.bat/sh file by adding the following JVM parameters to the java command:
-Duser.language=2-char-language-code -Duser.region=2-char-country-code
where the language and country codes are for the locale that the timestamps are in. For the example mentioned, the JVM parameters would be:
-Duser.language=en -Duser.region=US
Alternatively, change the rules-based adapter file by specifying the language and country codes for the timestamp locale in the associated Context Instance attributes.
When installing Generic Log Adapter on Windows XP, there are problems unzipping the Generic Log Adapter rules.zip file with the Windows XP native unzip utility. Some directories and files are not unzipped. As a result of this problem, some log file types cannot be parsed using Generic Log Adapter. To work around this problem, when installing on Windows XP, use another unzip utility such as WinZip or UnZip.
Continuously parsing IBM WebSphere Application Server activity log and IBM HTTP Server error log files with the respective static parsers sometimes results in records missing from the parsed output. Specifically, when the log file is appended with new records, the first record of the appended record is not parsed and is not included in the parsed output. This problem occurs when the context instance is configured with continuousOperation="true" in the static adapter configuration file for the logs. To workaround this problem, either parse the log file once by configuring the context instance with continuousOperation="false" or use the rules-based adapter for continuously monitoring.
When converting log files that use three-letter time zone symbols to CBE format using the Log Adapter, incorrect creation times for log events may result if the three-letter time zone symbol is non-unique. For example, the three-letter symbol "IST" could be interpreted as Israeli Standard Time, Indian Standard Time, Iran Standard Time or Irish Summer Time.
Return to the main readme file
© Copyright IBM Corporation 2000, 2005. All Rights Reserved.