The VmkwarningLogTest monitors the /var/log/vmkwarning log file of a VMware ESX server. All warning messages logged in the vmkwarning log file are tracked and alerted on by this test.

Note:

By default, on an ESX server, the vmkwarning log file can be accessed only by a root user. If the eG user is not installed as the root user of the target ESX server, then the eG user needs to be granted the permission to read the vmkwarning log file. To do so, execute the following command on the ESX server: chmod 644 /var/log/vmkwarning.

The default parameters associated with this will be displayed at the bottom of this page.

• The TEST PERIOD list box helps the user to decide how often this test needs to be executed.

• In the HOST text box, the host name of the server for which the test is to be configured has to be specified.

• The port number to which the server is listening is to be provided in the PORT text box. By default, this will be NULL.

• In the ALERTFILE text box, the default specification is vmkwarning@/var/log/vmkwarning. If you need to change this to a different log file, 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, the path to the directory containing log files can be provided - eg., /user/logs. This ensures that eG monitors the most recent log files in the specified directory. If while monitoring a log file in a directory a newer log file gets added to that directory, then eG will first finish monitoring the original log file and then start monitoring the new one. Specific log file name patterns can also be specified, so that the log file(s) monitored are restricted to files that match the specified patterns. 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 spaces (as the case may be).

  The eG monitor interface will report one set of measurements for every configured path. You can also configure the path in the following format:Name@logfilepath. 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 the test, and not the individual paths.

• By default, all messages logged in the vmkwarning log are reported by this test. If you wish to change the search pattern for messages, then, in the SEARCHPATTERN text box, specify a pattern 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 VM:VM-* in the SEARCHPATTERN text box. This indicates that "VM" is the pattern name to be displayed in the monitor interface. "VM-*" indicates that the test will monitor only those lines in the alert log which start with the term "VM-". Similarly, if your pattern specification reads: offline:*offline, then it means that the pattern name is offline and that the test will monitor those lines in the alert log which end with the term offline.   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: VM:VM-*,offline:*offline*,online:*online

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

• In the LINES text box, 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 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,2:1 as the value for LINES and if the corresponding value in the SEARCHPATTERN filed is like VM:VM-*,offline:*offline*,online:*online then:

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

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

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

• 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.

• The ROTATINGFILE 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:\eGurkha\logs\syslog.txt, and ROTATINGFILE is set to true, then, your descriptor will be of the following format: c:\eGurkha\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:\eGurkha\logs, and ROTATINGFILE is set to true, then, your descriptor will be: c:\eGurkha\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:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor will be: *sys*:<SearchPattern>. In this case, the descriptor format will not change even if the ROTATINGFILE flag status is changed.

• DD FREQUENCY 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.

• To make diagnosis more efficient and accurate, eG embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test, by default, for a particular server, choose the On option against DETAILED DIAGNOSIS. To disable the capability, click on the Off option.

  The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability

  • Both the bad and normal frequencies configured for the detailed diagnosis measures should not be 0.

• If multiple components of the same component type are awaiting configuration, then an APPLY TO OTHER COMPONENTS check box will appear in this page. Clicking on this check box will allow you to apply the configuration to all/selected components of that type.

• Once the necessary values have been provided, click on the Update button.

When changing the configuration for specific servers, a “*” beside the text box corresponding to the parameter signifies that these values have to be manually configured by the user. The parameter values that require to be configured will typically be prefixed with a “$” or contain a series of “*”. A value of "none" in the parameter value indicates that the corresponding parameter value can be changed if required.

The Back button enables the user to go back to the previous screen.