vCloud Container Info Log

The vcloud-container-info.log file, which will be present in the /opt/vmware/cloud-director/logs directory (on the vCloud Director host) by default, captures the debug-level log messages from the cell. This test scans this debug log file for specific patterns of messages and quickly reports the count and details of messages that match the configured patterns.

This test is disabled by default. To enable the test, go to the enable / disable tests page using the menu sequence : Agents -> Tests -> Enable/Disable, pick vCloud Director Cell as the Component type, set Performance as the Test type, choose the test from the disabled tests list, and click on the < button to move the test to the ENABLED TESTS list. Finally, click the Update button.

Note:

  1. This test can be executed only in an agent-based manner.
  2. The eG agent executing this test should run with root user privileges.

Target of the test : A vCloud Director Cell

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every AlertFile and SearchPattern combination.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The host for which the test is being configured.

Port

Specify the port at which the specified host listens in the Port text box.

AlertFile

Specify the path to the debug log file to be monitored. For eg.,. /opt/vmware/cloud-director/logs/vcloud-container-info.log.

Also, instead of a specific log file path, the path to the directory containing log files can be provided - eg., /opt/vmware/cloud-director/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 string 'container-info', the parameter specification can be, /opt/vmware/cloud-director/logs/*container-info*. 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 'container-info' example discussed above can be: debuglog@/opt/vmware/cloud-director/logs/*container-info*. In this case, the display name 'debuglog' 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).

SearchPattern

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 you specify ORA:ORA-* in the SearchPattern text box. This indicates that "ORA" is the pattern name to be displayed in the monitor interface. "ORA-*" indicates that the test will monitor only those lines in the alert log which start with the term "ORA-". 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: ORA:ORA-*,offline:*offline*,online:*online

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 the log file path, 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>:*.

Lines

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 ORA:ORA-*,offline:*offline*,online:*online then:

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

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

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

ExcludePattern

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

UniqueMatch

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.

RotatingFile

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 /opt/vmware/cloud-director/logs/vcloud-container-info.log, and RotatingFile is set to True, then, your descriptor will be of the following format: /opt/vmware/cloud-director/logs/vcloud-container-info.log:<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., vcloud-container-info.log:<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 /opt/vmware/cloud-director/logs, and RotatingFile is set to True, then, your descriptor will be: /opt/vmware/cloud-director/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 /opt/vmware/cloud-director/logs/*container-info*, and RotatingFile is set to True, then, your descriptor will be: /*container-info*:<SearchPattern>. In this case, the descriptor format will not change even if the RotatingFile flag status is changed. 

OverWrittenFile

By default, this flag is set to False. Set this flag to True if you want the test to support the 'roll over' capability 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. For instance, say, errors and warnings were originally logged to a file named messages. When a roll over occurs, the content of the file messages will be copied to a file named messages.1, and all new errors/warnings will be logged in messages. In such a scenario, since the overwrittenfile flag is set to False by default, the test by default scans only messages.1 for new log entries and ignores messages. On the other hand, if the flag is set to True, then the test will scan both messages and messages.1 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 or directory specifications should not be specified in the AlertFile text box.
  • The roll over file name should be of the format: “<alertfile>.1”, and this file must be in the same directory as the AlertFile.

CaseSensitive

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.

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. 

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite 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 for a particular server, choose the On option. 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 normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Exceptions

Indicates the number of errors that were added to the log file when the test was last executed.

Number

The value of this measure is a clear indicator of the number of “new” alerts that have come into the log file. The detailed diagnosis of this measure, if enabled, provides the detailed descriptions of the exceptions of the configured patterns.