Log Aggregation Overview

See subversion log for revision information.

Introduction

The Log Aggregation Facility (LAF) harvests event log information from all Member Nodes registered with a Coordinating Node and aggregates this information into a Solr index that contains information from all member nodes. The Solr index can be queried to create reports of usage statistics for the DataONE network or individual Member Nodes. A description of the data harvested from MNs is described here: LoggingSchema.html

LAF relies on several technologies: Quartz Scheduler, Hazelcast Data Distribution, Metacat Repository Storage, and the Solr Search platform.

The DataONE use cases are described here:

An overview of LAF processing is shown in Figure 1: Log Aggregation Overview

Figure 1. Log Aggregation Overview

../_images/log-aggregation-activity.png

Installation

LAF software is installed from the dataone-cn-processdaemon and dataone-cn-solr Debian packages.

LAF is started when the Unix service /etc/init.d/d1_processing is launched. LogAggregationScheduleManager is initialized by Spring when d1_processing runs the bootstrap class org.dataone.cn.batch.daemon.SchedulerDaemon. All LAF related beans are configured in /etc/dataone/process/applicationContext.xml.

LAF does not require any manual configuration before it can be run, however Metacat must be installed and configured before LAF starts.

Several LDAP attributes are used to control the execution of LAF, so if necessary the following LDAP entries can be manually edited to alter execution of LAF. This may be useful for testing purposes. Table 1 shows the LDAP attributes in the directory dc=dataone,dc=org,cn=urn:node:<nodeName> directory that LAF uses

Table 1 LDAP entries

Attribute Name

Value

Purpose

d1NodeAggregateLogs

TRUE or FALSE

Enable/Disable this node for harvesting

d1NodeLogLastAggregated

ISO 8601 date

Last time this MN was harvested

Log Recovery Processing

The Java class LogAggregationScheduleManager coordinates all scheduling of jobs for LAF. This class first checks if any other CN has more current log information and if so a recovery job is scheduled to query the other CNs for newer log records.

Log Harvest Processing

Then LogAggregationScheduleManager schedules recurring Quartz job (every 24 hours) for LogAggregationHarvestJob which handles running the tasks that harvest log data from the MNs.

Next a Hazelcast listener is registered for the top thehzLogEntryTopic. When log entries are returned from MNs they will posted to Hazelcast so that they are distributed to every CN.

A Hazelcast systemmetadata listener is also registered so that certain changes to mutable systemmetata fields (see System Metadata Updates for details).

The queue indexLogEntryQueue is then setup when the listener LogEntryTopicListener is called. This queue is how tasks that perform the log aggregation and tasks that perform the log indexing communicate.

LogAggregationHarvestJob runs the task LogAggregatorTask that queries each MN by calling mn.getLogRecords and retrieving up to 1000 event log records at a time, starting after the last date retrieved that was recorded by the last run, if any.

LogAggregatorTask then modifies each harvested record by adding the following fields: isPublic, dateAggregated, nodeId, readPermissions, formatId, formatType, size, rightsHolder, country, region, city, geohash_1 - geohash_9, location. These records are then published to the Hazelcast topic hzLogEntryTopic so that each CN that is running LAF will have it’s LogEntryTopicListener fire, which published them to the queue indexLogEntryQueue. In this way one CN harvests a single MN at a time, and the processing of those records is synced with the other CNs.

On the indexing side of processing, LogEntryQueuManager is initialized by Spring when d1_processing init script is run executes the task LogEntryQueueTask that reads and processes entries from the logEntrySolrItemList when this queue has accumulated 100 entries.

LogEntryQueueTask then starts task LogEntryIndexTask which sends entries to Solr for indexing.

Figure 2. Log Aggregation Processing

../_images/log-aggregation-sequence.png

System Metadata Updates

In addition to processing harvested records, when an entry in the Hazelcast Systemmetadata map is added or updated, SystemMetadataEntryListener runs. This may happen when one of the mutable fields in systemmetadata changes, such as formatId. In this event, all event log records for that pid must be updated, so SystemMetadataEntryListener retrieves these records, updates them with the current information in systemmetadata and then updates the entries and then publishes them to the IndexLogEntrySolrItem queue, so that they are processed in the same way as new Event Log records.

Figure 3. System Metadata Listener

../_images/systemmetadata-listener-activity.png

Solr Index

Table 2 shows the fields contained in the Event Log Solr index

Table 2. Solr index schema

Event Log Index Schema

Solr index schema

Name

Solr Type

Comment

id

string

added after harvest

dateAggregated

date

added after harvest

isPublic

boolean

added after harvest, obtained from systemmetadata

readPermission

string

added after harvest, obtained from systemmetadata, filtered during query

entryId

string

obtained from MN event log

pid

string

added after harvest, obtained from systemmetadata

ipAddress

string

obtained from MN event log, filtered during query

userAgent

string

obtained from MN event log

subject

string

obtained from MN event log, filtered during query

event

string

obtained from MN event log

dateLogged

date

obtained from MN event log

nodeId

string

obtained from MN event log

rightsHolder

string

added after harvest, obtained from systemmetadata, filtered during query

formatId

string

added after harvest, obtained from systemmetadata

formatType

string

added after harvest, obtained from systemmetadata

size

slong

added after harvest, obtained from systemmetadata

country

string

added after harvest, determined from ipAddress

region

string

added after harvest, determined from ipAddress

city

string

added after harvest, determined from ipAddress

geohash_1

string

added after harvest, determined from ipAddress

geohash_2

string

added after harvest, determined from ipAddress

geohash_3

string

added after harvest, determined from ipAddress

geohash_4

string

added after harvest, determined from ipAddress

geohash_5

string

added after harvest, determined from ipAddress

geohash_6

string

added after harvest, determined from ipAddress

geohash_7

string

added after harvest, determined from ipAddress

geohash_8

string

added after harvest, determined from ipAddress

geohash_9

string

added after harvest, determined from ipAddress

location

location

added after harvest, determined from ipAddress

inFullRobotList

boolean

added after harvest, determined based on log processing for COUNTER compliance

inPartialRobotList

boolean

added after harvest, determined based on log processing for COUNTER compliance

isRepeatVisit

boolean

added after harvest, determined based on log processing for COUNTER compliance

Solr Query Processing

The Event Log Solr index can be queried from the service endpoint https://cn.dataone.org/cn/v1/query/logsolr, for example, the following query will return read counts for each node in the network:

https://cn.dataone.org/cn/v1/query/logsolr/select?q=event:read&facet=true&facet.field=nodeId

The Event Log Solr index requires authenticated access, because some fields in the log entries contain sensitive information, as shown in Table 2.

Solr queries are inspected and rewritten by SolrLoggingHandler such that counts for Solr entries will be included only if the entries are publicly accessible, or the user is a CN administrator or the caller’s identify has access privileges to the pids of the entries.

If the requesting session has a certificate then a list of authorized subjects is obtained from LDAP and access is based on the authorized subjects. Since the Solr index contains access information from systemmetadata, the same access rules that apply to systemmetadata will apply to the event log.

If the authenticated user is the CN administrator then the entire contents of each SOLR document are available in the SOLR result.

Example Queries

A description of how to query the Event Log Solr Index, please see the document UsageStatistics.html.

This material is based upon work supported by the National Science Foundation under Grant Numbers 083094 and 1430508.

Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.