Trex Alerts Test

How often should the test be executed

The host for which the test is to be configured.

Specify the port at which the specified host listens. By default, this is 30001.

Specify two numbers in the format x:y. 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 detailed 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,2:1 as the value for LINES and if the corresponding value in the SEARCHPATTERN filed is like error:error-*,offline:*offline*,online:*online then:

0:0 will be applied to error:error-* pattern

1:1 will be applied to offline:*offline* pattern

2:1 will be applied to online:*online pattern

This flag governs the display of descriptors for this test in the eG monitoring console.

If this flag is set to True and the alertfile text box contains the full path to a specific (log/text) file, 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:\trex\logs\alert.txt, and rotatingfile is set to true, then, your descriptor will be of the following format: c:\trex\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., syslog.txt:<SearchPattern> in the case of the example above. 

If this flag is set to true and the alertfile parameter is set to the directory containing log files, then, the descriptors of this test will be displayed in the format: Configured_directory_path:<SearchPattern>. For instance, if the alertfile parameter is set to c:\trex\logs, and rotatingfile is set to true, then, your descriptor will be: c:\trex\logs:<SearchPattern>. On the other hand, if the rotatingfile parameter had been set to false, then the descriptors will be of the following format: Configured_directory:<SearchPattern> - i.e., logs:<SearchPattern> in the case of the example above.

If this flag is set to true and the alertfile parameter is set to a specific file pattern, then, the descriptors of this test will be of the following format: <FilePattern>:<SearchPattern>. For instance, if the alertfile parameter is set to c:\trex\logs\*alert*, and rotatingfile is set to true, then, your descriptor will be: *alert*:<SearchPattern>. In this case, the descriptor format will not change even if the rotatingfile flag status is changed.

This test extracts the performance metrics from the diagnostics.log file present in the {ITS_INSTALL_DIR}\6.20\{Directory corresponding to the ITS instance}\logs directory. Therefore, in the LOGFILEPATH text box, provide the full path to the diagnostics.log file in the following format: {Instance Name}={Path to the log file}. For example, if the log file for an instance named 'ADM' is to be monitored, and ITS is installed in the C:\Program Files\SAP\ITS directory, then the LOGFILEPATH specification should be as follows: ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\diagnostics.log. To monitor the diagnostics.log files associated with multiple instances, provide the LOGFILEPATH as a comma-separated list. For example, ADM=c:\Progra~1\SAP\ITS\6.20\ADM\logs\diagnostics.log,ITS1=c:\Progra~1\SAP\ITS\6.20\ITS1\logs\diagnostics.log.

Specify the path to the alert log file to be monitored. For eg., /user/john/alert_john.log. Multiple log file paths can be provided as a comma-separated list - eg., /user/john/alert_egurkha.log,/tmp/log/alert.log.

Also, instead of a specific log file path, the path to the directory containing log files can be provided - e.g., /user/logs. This ensures that eG Enterprise monitors the most recent log files in the specified directory. Specific log file name patterns can also be specified. For example, to monitor the latest log files with names containing the strings ‘dblogs’ and ‘applogs’, the parameter specification can be, /tmp/db/*dblogs*,/tmp/app/*applogs*. Here, ‘*’ indicates leading/trailing characters (as the case may be). In this case, the eG agent first enumerates all the log files in the specified path that match the given pattern, and then picks only the latest log file from the result set for monitoring.

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. Accordingly, the parameter specification for the ‘dblogs’ and ‘applogs’ example discussed above can be: dblogs@/tmp/db/*dblogs*,applogs@/tmp/app/*applogs*. In this case, the display names ‘dblogs’ and ‘applogs’ 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 monitoring 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).

By default, this flag is set to false. Set this flag to trueif log files do not 'roll over' in your environment, but get overwritten instead. In such environments typically, new error/warning 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 overwrittenfileflag 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.

Enter the specific patterns of alerts to be monitored. 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 your SEARCHPATTERN specification is as follows: DEBUG:DEBUG*. This indicates that "DEBUG" is the pattern name to be displayed in the monitor interface. "DEBUG*" indicates that the test will monitor only those lines in the specified log file which start with the string "DEBUG". Similarly, if your pattern specification reads: ERROR:*ERROR, then it means that the pattern name is ERROR and that the test will monitor those lines in the log which end with the term ERROR.

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: DEBUG:*DEBUG*,ERROR:*ERROR*,INFO:*INFO*,ERROR:*ERROR*,WARNING:*WARN*,FATAL:*FATAL*

If the alertfile specification is of the format Name@logfilepath, 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 file paths, then the descriptors will be of the format: LogFilePath:PatternName.

If you want all the messages in a log file to be monitored, then your specification would be: <PatternName>:*

If UTF-8 encoding is to be used for reading the specified log file, then, set this flag to true. By default, this flag is set to false. If multiple log files are being monitored, then, for each file, you will have to indicate whether UTF-8 encoding is to be used for reading that file or not. For instance, assume that the ALERTFILE parameter is set to dblogs@/tmp/db/dblogs.log,applogs@/tmp/app/applogs.log. Now, to instruct the test to use UTF-8 encoding for reading the 'dblogs' log file and not to use the UTF-8 encoding while reading the 'applogs' log file, your USEUTF8 setting should be as follows: true,false. Note that the number of values provided against the USEUTF8 parameter should be equal to the number of log files being monitored. Also, note that if the ALERTFILE being monitored has BOM, then the test will automatically use UTF-8 encoding to read that file, even if the USEUTF8 flag is set to false.

Note:

If your alertfile specification consists of file patterns that include wildcard characters (eg. /tmp/db/*dblogs*,/tmp/app/*applogs*), then the files that match such patterns will only support the ANSI format, and not the UTF format, even if the utf-8 parameter is set to true for such patterns.

If UTF-16 encoding is to be used for reading the specified log file, then, set the USEUTF16 flag to true. By default, this flag is set to true. If multiple log files are being monitored, then, for each file, you will have to indicate whether UTF-16 encoding is to be used for reading that file or not. For instance, assume that the ALERTFILE parameter is set to dblogs@/tmp/db/dblogs.log,applogs@/tmp/app/applogs.log. Now, to instruct the test to use UTF-16 encoding for reading the 'dblogs' log file and not to use the UTF-16 encoding while reading the 'applogs' log file, your USEUTF16 setting should be as follows: true,false. Note that the number of values provided against the USEUTF8 parameter should be equal to the number of log files being monitored.

Note:

If your ALERTFILE specification consists of file patterns that include wildcard characters (e.g., /tmp/db/*dblogs*,/tmp/app/*applogs*), then the files that match such patterns will only support the ANSI format, and not the UTF format, even if the UTF-16 parameter is set to true for such patterns.

Provide a comma-separated list of patterns to be excluded from monitoring in the EXCLUDEPATTERN text box. For example *critical*, *exception*. By default, this parameter is set to 'none'. 

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 Pattern1:*fatal*,Pattern2:*error* is 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 'fatal' and 'error'. 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 'fatal' and 'error' 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.

This 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-sensitive' manner. In this case therefore, for the test to work, even the case of your alertfile and searchpattern specifications should match with the actuals.

By default, this 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 - eg., UTF-8, UTF-16, etc.  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. 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. For instance, say that your alertfile specification is as follows:D:\logs\report.log,E:\logs\error.log, C:\logs\warn_log. Assume that while UTF-8 needs to be used for reading from report.log , UTF-16 is to be used for reading from warn_log. No encoding format need be applied to error.log. In this case, your encodeformat specification will be: UTF-8,none,UTF-16. 

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. 

1. The USE SUDO parameter is applicable to Unix environments only. By default, the eG agent does not require any special permissions to parse and read messages from the log file to be monitored. This is why, the USE SUDO parameter is set to No by default. In some highly-secure Unix environments however, the eG agent install user may not have the permission to read the log file to be monitored. In such environments, you will have to follow the steps below to ensure that the test is able to read the log file and report metrics:

   • Edit the SUDOERS file on the target host and append an entry of the following format to it:

     <eG_agent_install_user> ALL=(ALL) NOPASSWD: <Log_file_with_path>;

     For instance, if the eG agent install user is eguser, and the log file to be monitored is /usr/bin/logs/procs.log, then the entry in the SUDOERS file should be:

     eguser ALL=(ALL) NOPASSWD: /usr/bin/logs/procs.log

   • Finally, save the file.
   • Then, when configuring this test using the eG admin interface, set the USE SUDO parameter to Yes. Once this is done, then every time the test runs, it will check whether the eG agent install user has the necessary permissions to read the log file. If the user does not have the permissions, then the test runs the sudo command to change the permissions of the user, so that the eG agent is able to read from the log file.

The SUDO PATH parameter is relevant only when the USE SUDO parameter is set to ‘Yes’. By default, the SUDO PATH is set to none. This implies that the sudo command is in its default location - i.e., in the /usr/bin or /usr/sbin folder of the target host. In this case, once the USE SUDO flag is set to Yes , the eG agent automatically runs the sudo command from its default location to allow access to the configured log file. However, if the sudo command is available in a different location in your environment, you will have to explicitly specify the full path to the sudo command in the SUDO PATH text box to enable the eG agent to run the sudo command.