|
Default Parameters for PepTuxLogTest
The PepTuxLogTest enables administrators to periodically scan TUXLOG files for specific patterns of errors/warnings, and efficiently troubleshoot them
This page depicts the default parameters that need to be configured for the PepTuxLogTest.
This test monitors the TUXLOG files for errors/warnings. Typically, these log files will be available in the <PSHome>\appserv\<domain>\LOGS directory and will be named in the following format: TUXLOG.mmddyy, where <mmddyy> refers to the month, date, and year of creation of the log file. In the LOGS directory therefore, you will find multiple TUXLOG files, one for every day of the month. To enable the test to monitor a specific TUXLOG file, you need to provide the full path to that log file against ALERTFILE. For instance, if <PSHome> (on Windows) is C:\ps, the name of the PeopleSoft domain is psdomain, and the log file you want to monitor was created on the 16th of April, 2015, your ALERTFILE specification will be: C:\ps\appserv\psdomain\LOGS\TUXLOG.041615. Multiple log files can also be monitored as a comma-separated list. For instance, your ALERTFILE specification can be: C:\ps\appserv\psdomain\LOGS\TUXLOG.041615, C:\ps\appserv\psdomain\LOGS\TUXLOG.042015. Specific log file name patterns can also be specified. For example, to monitor all the log files created in the months of March and April (i.e., in the 3rd and 4th months), the parameter specification can be, : C:\ps\appserv\psdomain\LOGS\TUXLOG.03*15,C:\ps\appserv\psdomain\LOGS\TUXLOG.04*15. Here, ‘*’ indicates leading/trailing characters (as the case may be).
Your ALERTFILE specification can also be of the following format: Name@logfilepath_or_pattern. Here, Name represents the display name of the path being configured. For instance, to monitor all TUXLOG log files that were created in the months of March and April, your specification can be: Marchlogs@ C:\ps\appserv\psdomain\LOGS\TUXLOG_03*15,Aprillogs@C:\ps\appserv\psdomain\LOGS\TUXLOG_04*15. In this case, the display names ‘Marchlogs’ and ‘Aprillogs’ will alone be displayed as descriptors of this test.
Every time this test is executed, the eG agent verifies the following:
Whether any changes have occurred in the size and/or timestamp of the log files that were monitored during the last measurement period; Whether any new log files (that match the ALERTFILE specification) have been newly added since the last measurement period;
If a few lines have been added to a log file that was monitored previously, then the eG agent monitors the additions to that log file, and then proceeds to monitor newer log files (if any). If an older log file has been overwritten, then, the eG agent monitors this log file completely, and then proceeds to monitor the newer log files (if any).
The specific patterns of alerts to be monitored are entered on the SEARCHPATTERN text box. The pattern should be in the following format: <PatternName>:<Pattern>, where <PatternName> is the pattern name that will be displayed in the monitor interface and <Pattern> is an expression of the form - expr or expr or expr or expr, etc. A leading ‘*’ signifies any number of leading characters, while a trailing ‘*’ signifies any number of trailing characters.
For example, say you specify Error:ERROR:* in the SEARCHPATTERN text box. This indicates that “Error” is the pattern name to be displayed in the monitor interface. “ERROR:*” indicates that the test will monitor only those lines in the alert log which begin with the phrase ERROR::. Similarly, if your pattern specification reads: Fail:*failed, then it means that the pattern name is “Fail” and that the test will monitor those lines in the alert log which end with the term “failed”.
A single pattern may also be of the form e1+e2, where + signifies an OR condition. That is, the <PatternName> is matched if either e1 is true or e2 is true.
Multiple search patterns can be specified as a comma-separated list. For example: For example: Error:ERROR:*, Fail:*failed
If the ALERTFILE specification is of the format Name@logfilepatterns, then the descriptor for this test in the eG monitor interface will be of the format: Name:PatternName. On the other hand, if the ALERTFILE specification consists only of a comma-separated list of log files/patterns, then the descriptors will be of the format: LogFile/Pattern:PatternName.
If you want all the messages in a log file to be monitored, then your specification would be: <PatternName>:*.
Specify two numbers in the format x:y in the LINES box. This means that when a line in the alert file matches a particular pattern, then x lines before the matched line and y lines after the matched line will be reported in the detail diagnosis output (in addition to the matched line). The default value here is 0:0. Multiple entries can be provided as a comma-separated list.
If you give 1:1 as the value for LINES, then this value will be applied to all the patterns specified in the SEARCHPATTERN field. If you give 0:0,1:1 as the value for LINES and if the corresponding value in the SEARCHPATTERN field is like Error:ERROR:*, Fail:*failed, then:
0:0 will be applied to Error:ERROR:* pattern
1:1 will be applied to Fail:*failed pattern
By default, the UNIQUEMATCH parameter is set to FALSE, indicating that, by default, the test checks every line in the log file for the existence of each of the configured SEARCHPATTERNS. By setting this parameter to TRUE, you can instruct the test to ignore a line and move to the next as soon as a match for one of the configured patterns is found in that line. For example, assume that Error:ERROR:*,Fail:*failed are the SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE, then the test will read every line in the log file completely to check for the existence of messages embedding the strings ‘ERROR:’ and ‘failed’. If both the patterns are detected in the same line, then the number of matches will be incremented by 2. On the other hand, if UNIQUEMATCH is set to TRUE, then the test will read a line only until a match for one of the configured patterns is found and not both. This means that even if the strings ‘Error’ and ‘failed’ follow one another in the same line, the test will consider only the first match and not the next. The match count in this case will therefore be incremented by only 1.
The ROTATINGFILE flag governs the display of descriptors for this test in the eG monitoring console.
If this flag is set to true, then the descriptors of this test will be displayed in the following format: Directory_containing_monitored_file:<SearchPattern>. For instance, if the ALERTFILE parameter is set to C:\ps\appserv\psdomain\LOGS\TUXLOG.042015, and ROTATINGFILE is set to true, then, your descriptor will be of the following format: C:\ps\appserv\psdomain\LOGS:<SearchPattern>. On the other hand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of the following format: <FileName>:<SearchPattern> - i.e., APPSRV_0415.LOG:<SearchPattern> in the case of the example above.
The CASESENSITIVE flag is set to No by default. This indicates that the test functions in a ‘case-insensitive’ manner by default. This implies that, by default, the test ignores the case of your ALERTFILE and SEARCHPATTERN specifications. If this flag is set to Yes on the other hand, then the test will function in a ‘case-insensitive’ manner. In this case therefore, for the test to work, even the case of your ALERTFILE and SEARCHPATTERN specifications should match with the actuals.
The ROLLOVERFILE flag, by default, is set to false. Set this flag to true if you want the test to support the ‘roll over’ capability (if any) of the specified ALERTFILE. A roll over typically occurs when the timestamp of a file changes or when the log file size crosses a pre-determined threshold. When a log file rolls over, the errors/warnings that pre-exist in that file will be automatically copied to a new file, and all errors/warnings that are captured subsequently will be logged in the original/old file. In such a scenario, since the ROLLOVERFILE flag is set to false by default, the test by default scans only the original/old file for new log entries and ignores the new file. On the other hand, if the flag is set to true, then the test will scan both old and the rolled-over file for new entries.
If you want this test to support the ‘roll over’ capability described above, the following conditions need to be fulfilled:
The ALERTFILE parameter has to be configured only with the name and/or path of one/more alert files. File patterns should not be specified in the ALERTFILE text box. The roll over file name should be of the format: “<ALERTFILE>.”, and this file must be in the same directory as the ALERTFILE.
The OVERWRITTENFILE flag is set to false by default. Set this flag to true if log files do not ‘roll over’ in your environment, but get overwritten instead. In such environments typically, new messages that are captured will be written into the log file that pre-exists and will replace the original contents of that log file; unlike when ‘roll over’ is enabled, no new log files are created for new entries in this case. If the OVERWRITTENFILE flag is set to true, then the test will scan the new entries in the log file for matching patterns. However, if the flag is set to false, then the test will ignore the new entries.
The ENCODEFORMAT, by default, is set to none, indicating that no encoding format applies by default. However, if the test has to use a specific encoding format for reading from the specified ALERTFILE, then you will have to provide a valid encoding format here. Where multiple log files are being monitored, you will have to provide a comma-separated list of encoding formats - one each for every log file monitored - e.g., UTF-8, UTF-16. Make sure that your encoding format specification follows the same sequence as your ALERTFILE specification. In other words, the first encoding format should apply to the first alert file, and so on.
Note:
If your ALERTFILE specification consists of file patterns that include wildcard characters (eg., C:\ps\appserv\psdomain\LOGS\TUXLOG.03*15, C:\ps\appserv\psdomain\LOGS\TUXLOG.04*15), then such configurations will only be supported in the ANSI format, and not the UTF format.
The USEUTF8 flag, by default, is set to No, implying that the test does not use the UTF-8 format to read from the log files configured for monitoring. However, if the test has to use only the UTF-8 format for reading from all the log files configured for monitoring in your ALERTFILE specification, then set this flag to Yes.
The USEUTF16 flag, by default, is set to No, implying that the test does not use the UTF-16 format to read from the log files configured for monitoring. However, if the test has to use only the UTF-16 format for reading from all the log files configured for monitoring in your ALERTFILE specification, then set this flag to Yes.
Note:
If your ALERTFILE specification consists of file patterns that include wildcard characters (eg., C:\ps\appserv\psdomain\LOGS\TUXLOG.03*15, C:\ps\appserv\psdomain\LOGS\TUXLOG.04*15), then such configurations will only be supported in the ANSI format, and not the UTF formats.
The DD FREQUENCY flag 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.
When changing default configurations of tests, the values with “$” indicate variables that will be replaced by the eG system according to the specific server being managed - for instance, $hostName is the host/nickname of the target host, $port is the port number of the server being monitored. E.g., for a server xyz:80, $hostName will be changed automatically by the eG manager to “xyz” and $port will be changed to “80” when configuring a test.
|