Log files contain important run-time information about the general health of EGO daemons and EGO system events. Log files are an essential troubleshooting tool during production and testing.
The naming convention for most EGO log files is the name of the daemon plus the host name the daemon is running on.
The following table outlines the EGO daemons and their associated log file names. Most log files on Windows hosts have a .txt extension.
By default, most EGO log files are found in EGO_TOP\kernel\log (Windows) or EGO_TOP/kernel/log (Linux/UNIX).The majority of log entries are informational in nature. It is not uncommon to have a large (and growing) log file and still have a healthy cluster.
Log files can also be accessed through the Platform Management Console (from System Logs > Standard Logs).
The standard format for log file entries is:
where the date is expressed in YYYY-MM-DD hh:mm:ss.sss.
For example, 2006-03-14 11:02:44.000 Eastern Standard Time ERROR [2488:1036] vemkdexit: vemkd is halting.
Every time an EGO system event occurs, a log file entry is added to a log file. Most entries are informational in nature, except when there is an error condition. If your log levels provide entries for all information (for example, if you have set them to LOG_DEBUG), the files grow quickly.
During regular EGO operation, set your log levels to LOG_WARNING. With this setting, critical errors are logged but informational entries are not, keeping the log file size to a minimum.
For troubleshooting purposes, set your log level to LOG_DEBUG. Because of the quantity of messages you receive when subscribed to this log level, change the level back to LOG_WARNING as soon as you are finished troubleshooting.
The growth rate of the log files is dependent on the log level and the complexity of your cluster. If you have a large cluster, daily log file maintenance may be required.
We recommend using a log file rotation utility to do unattended maintenance of your log files. Failure to do timely maintenance could result in a full file system, which hinders system performance and operation.
logging severity: The configured severity log class controlling the level of event information that is logged (critical, error, warning, notice, info, debug, or dynamic). In the case of the log class set to debug, a log level is required to determine the amount of detail logged for debugging purposes. The higher the log level number, the more debug details messages are logged. Refer to third-party documentation for more information about BIND and logging.
The egosc daemon reads egosc_conf.xml.
If a system is running well, typically set log level to info or even warning to minimize messages.
Use the following parameters to specify the log class:
Every log entry belongs to a log class. You can use log class as a mechanism to filter log entries by area. Log classes in combination with log levels allow you to troubleshoot using log entries that only address, for example, configuration.
Log classes (as well as log levels) can be filtered at run time using egosh debug.
Use EGO_DEBUG_LIM to specify the log class. For example, EGO_DEBUG_LIM=LC_MEMORY.
Every log entry belongs to a log class. You can use log class as a mechanism to filter log entries by area. Log classes in combination with log levels allow you to troubleshoot using log entries that only address, for example, configuration.
Log classes (as well as log levels) can be filtered at run time using egosh debug.
Use EGO_LOG_MASK to specify the log level. For example, EGO_LOG_MASK=LOG_CRIT.
For most logs, there are nine log levels that allow administrators to control the level of event information that is logged. For logs associated with the reporting feature, there are seven log levels.
When you are troubleshooting, increase the log level to obtain as much detailed information as you can. When you are finished troubleshooting, decrease the log level to prevent the log files from becoming too large and to enhance daemon performance.