Every logging service extends the GenericDataListenerService class and has a dataListeners property. This property defines which Data Collection services operate on the log entry objects generated from the logging services. The DataListenerQueue component configures each logging service to send logging events to its own unique listeners.
For example, the UserEventLogging service has this property:
dataListeners=userevents/QueueSink
Each QueueSink has a dataListeners property that specifies how to log events. By default, the system sends all log entries directly to the FileSink, as specified by this property:
dataListeners=FileSink
To send all log entries to a database instead, configure the dataListeners property as follows:
dataListeners=SQLSink
See Logging to a Database for more information about changing the Personalization module’s configuration to use SQLSinks rather than FileSinks.
Each event channel is logged separately, so each of the following sinks are available:
userevent/SQLSink
userevent/FileSink
requests/SQLSink
requests/FileSink
contentviewed/SQLSink
contentviewed/FileSink
If a site generates a very large load of log entries, you may not be able to put all log entries into the database fast enough. This could result in the queue backing up and the potential loss of data. One way to avoid this problem is to use a flat file as your logging queue sink. You can create a routine to import the data from the flat file into your database at appropriate intervals for use in reporting.
The purpose of the queues in the logging system is to optimize the request handling time for the user. Storing the logged data in the scope of a request can be a relatively time consuming operation. Each queue has its own thread management that allows it to issue log entries to the various output sinks outside the scope of the request thread. This allows the request to hand off the log entry very quickly and it does not get slowed down by the data store of the logging data.
The discrete log entries are stored persistently in:
a flat file, through an instance of
atg.service.datacollection.FormattingFileLoggerora relational database, through an instance of
atg.service.datacollection.SQLTableLogger.
By default, the queue forwards the log entries to a file sink. SQL sinks have been pre-configured in the Personalization module’s installation, but have not been activated.
Once the log entry reaches the file or SQL sink, the Data Collection formatting syntax is used to determine how to represent the log entry. Each logging service uses a specific JavaBean to represent the log entry. The properties of the JavaBeans can be used in the formatting syntax. For more information on the properties available for logging, see the ATG Platform API Reference.
