|
MAIL LOG DETAILS To access this page, click on the
If required, you can modify the default settings, by selecting/deselecting the relevant check boxes in the Alarm details to be logged field in this section. For instance, by selecting the Description and Start date & time check boxes, you can make sure that the mail log also records the details of problem descriptors, a brief description of the problem, and the problem date and time.
Assume that the Processes test has raised an alert indicating that a critical process is not running on the event log server. The default log entry that corresponds to this event would be: Mail send failed [Critical,Event92,Event Log,Application Processes,Processes. If you have enabled the Description and the Start date & time check boxes, the log entry would be: Mail send failed [Jan.21.2008 14:21:28,Critical,Event92,EventLog,ApplicationProcesses,Processes{+firefox -> Process not running}. Besides, to ensure that a single log file is not overloaded with problem details or does not grow enormously in size, you can trigger the creation of additional log files as soon as the size of a log file exceeds a pre-configured limit. This ceiling can be set using the Maximum size of log file(MB) text box. Once this limit is reached, the eG manager creates a new log file, copies the old data to it, and starts logging the latest information to the older log file. In environments where there is excessive mail activity, this can result in a large number of log files, which might in turn consume too much space on the eG manager host. In such a case, you can conserve space on the eG manager host using the Maximum number of log files configuration. If such a limit is configured, then the eG manager will continue creating new log files only till such time that the said file limit is reached. Beyond this point, no additional log files will be created; instead, the eG manager will overwrite the currently open log file with the newer problem information. Note: Like email activity, the eG manager can also be optionally configured to maintain logs of the alarms generated by it. In some environments, this could serve as a tool for effective 'postmortem' analysis of problem situations - i.e., administrators can use the logs to be informed of problems that might have occurred during a period of their non-availability. Auditing of alarms reveal when an alarm was generated, the nature of the problem reported by the alarm, what were the problems clubbed together, and which problem is the source of a set of related problems. In some other environments, alarm logging could be a ‘must have’; such environments may host applications that read the alarm information stored in the logs for converting them into email/SMS alerts. |