[转]日志系统设计

原文链接

The logging model used by Dynamo provides a flexible mechanism for setting up complex application logging rules. With a combination of filters and sinks, you can design a logging configuration that handles all requirements.

The key to designing logging systems is to model your logging rules in terms of the logging filters and sinks provided with Dynamo (or with new filters and sinks that you write yourself).

For example, if you want to monitor a particular component so errors are sent as email, but all messages, including errors, are sent to a single file, you need the following:

  • LogListenerQueue, to ensure the component is not hampered by the logging processes

  • DispatchLogger that:

    • receives events from the LogListenerQueue

    • defines only the logDestinations property

    • distributes all events to two listeners

  • Another DispatchLogger that feeds from the first DispatchLogger but only recognizes ErrorLogEvents

  • EmailLogger to receive events from the second DispatchLogger and to send those events as email

  • RotatingFileLogger to receive all events from the first DispatchLogger and write those events to a file

Finally, the log source component must specify the LogListenerQueue as one of its logListeners.

Here is an example of what a logging system might look like:

 

LogEvent Sinks

A LogEvent sink is a LogListener that performs a final action on a LogEvent. This can include writing the LogEvent to a file, sending the LogEvent as email, or writing the LogEvent to a database. Dynamo defines several different kinds of LogEvent sinks:

  • PrintStreamLogger

  • FileLogger

  • RotatingFileLogger

  • EmailLogger

PrintStreamLogger

PrintStreamLogger writes logging messages to a PrintStream. By default, a PrintStreamLogger is configured to write logging messages to System.out, which usually leads to the console.

PrintStreamLogger is useful as a debugging tool during development. Dynamo defines a PrintStreamLogger called /atg/dynamo/service/logging/ScreenLog of theatg.nucleus.logging.PrintStreamLogger class. By default, the ScreenLog component is a logListener for all Nucleus components that implement ApplicationLogging. You can disable theScreenLog component by setting its loggingEnabled property to false. This is the recommended setting for live Dynamo sites.

FileLogger

FileLogger writes logging messages to a text file. Two properties define an instance of a FileLogger:

  • logFilePath: The path to the directory that holds the log file. The path can be relative to the directory where Dynamo is run. For example, logFilePath=./logs points to the <ATG9dir>/home/logsdirectory, while logFilePath=logs points to the <ATG9dir>/home/servers/<server>/logs directory.

  • logFileName: The actual name of the log file, within the logFilePath. So if logFilePath is ./logs, and logFileName is warnings.log, the logging messages are written to<ATG9dir>/home/logs/warnings.log.

You can disable any FileLogger component by setting its loggingEnabled property to false.

RotatingFileLogger

RotatingFileLogger is a subclass of atg.nucleus.logging.FileLogger that periodically archives its log file to another directory. This prevents log files from growing without bound, but still lets you keep some log file history around.

The archiving is controlled by the following properties:

Property

Description

scheduler

The Scheduler to use to perform the archiving. This is usually set to /atg/dynamo/service/Scheduler.

schedule

The Schedule to use to perform the archiving (see Configuring a Schedulable Component). This is often set to a CalendarSchedule, allowing it to perform the archiving on a calendar-based schedule such as every Sunday morning at 1am.

logArchivePath

The directory where the archived log files are to be placed. This is usually different from the logFilePath, to make it easier for you to manage your log files and your archive files separately.

maximumArchiveCount

This is the maximum number of archive files that are kept for a particular log file. After this maximum has been reached, the oldest file is discarded whenever the log file is archived.

archiveCompressed

Specifies whether log files are compressed before being archived. See below.

When the log file is archived, it is moved from the logFilePath to the logArchivePath, and is renamed <logFileName>.0. If there already is a <logFileName>.0, it is renamed <logFileName>.1. 1 is renamed to 2, 2 is renamed to 3, and so on. This rotation stops at the maximumArchiveCount. If the maximumArchiveCount is 10, <logFileName>.9 is not moved to <logFileName>.10, but is instead erased.

After the log file is archived, a new log file is opened in the logFilePath, and logging continues as normal.

You also have the option of compressing log files before they are archived. If the archiveCompressed property is set to true, log files are compressed into a ZIP file format. The archived log files also have the extension .zip. These compressed log files can be read by a standard ZIP file reader, or by using the jar command that comes with the JSDK:

jar xvf info.log.0.zip

One example instance of RotatingFileLogger can be found at /atg/dynamo/service/logging/InfoLog. It has the following properties:

$class=atg.nucleus.logging.RotatingFileLogger
logFilePath=./logs
logFileName=info.log
logListeners=ErrorLog

scheduler=../Scheduler
schedule=calendar * . 1 1 0
logArchivePath=./logs/archives
maximumArchiveCount=20
archiveCompressed=true
EmailLogger

An EmailLogger takes log messages and sends them out as email to a list of recipients. This is useful for system administrators who wish to be notified whenever certain parts of the system malfunction. Administrators who use email-to-pager gateways can be paged when certain critical events take place.

The EmailLogger batches log messages before sending them as email. This is extremely valuable in situations where the system malfunctions in such a way that it is generating many error messages in a short amount of time. In such a situation, an administrator finds it much more helpful to receive, say, ten pieces of email with 100 error messages in each, than to receive 1000 messages with one error in each. The logger can be triggered to send its batched log messages when a certain number of messages are batched, or after a certain amount of time.

When the logger sends its email message, it generates an EmailEvent, which is then sent to an EmailSender.

The following properties control the configuration of an EmailLogger:

Property

Description

logEventThreshold

The number of log messages that are batched before being sent as email.

schedule

Using the above threshold, messages are not sent until the threshold is reached. So if the threshold is 10, and 9 log events are issued, email is still not sent until the 10th is received. By specifying a schedule, you can tell the EmailLogger to send out email according to a time trigger as well as a threshold. So if the schedule is set to every 5 minutes, email is sent within 5 minutes of receiving a log event, whether or not the log event threshold has been reached.

scheduler

If you are going to specify a schedule, you must also specify a scheduler. This is usually set to /atg/dynamo/service/Scheduler.

emailListeners

This is a pointer to the EmailSender that performs the task of sending email. This is usually set to /atg/dynamo/service/SMTPEmailQueue.

defaultRecipients

This is a comma-separated list specifying the email addresses of those for whom the email is intended. For example,sysadmin@example.com,test@example.com.

defaultFrom

This is what you want to appear in the from field of the email.

defaultSubject

This is what you want to appear in the subject field of the email.

defaultBody

Anything placed in here appears at the top of the email body. The log messages are placed after the defaultBody.

A sample EmailLogger can be found at /atg/dynamo/service/logging/EmailLog:

$class=atg.nucleus.logging.EmailLogger
emailListeners=../SMTPEmail
logEventThreshold=10
scheduler=../Scheduler
schedule=every 5 minutes
defaultRecipients=sysadmin@example.com,test@example.com
defaultFrom=Dynamo_Number_12
defaultSubject=Main Reactor Core Down
defaultBody=Run now!
posted @ 2016-01-20 17:25  masic  阅读(255)  评论(0编辑  收藏  举报