...

Configuration of LogWriters

The configuraton of log writers can be either done in the application.ini / installation.ini or hardcoded in PHP.

resources.ZfExtended_Resource_Logger.writer.default.type = 'ErrorLog'
resources.ZfExtended_Resource_Logger.writer.default.filter[] = "level <= debug" ; → warn logs from fatal to debug

; Test config:
resources.ZfExtended_Resource_Logger.writer.mail.type = 'DirectMail'
; via the formatter define what the user gets: full debug content, or only notice and so on.
resources.ZfExtended_Resource_Logger.writer.mail.filter[] = "level <= error" ; → warn logs from fatal till error
resources.ZfExtended_Resource_Logger.writer.sender = 'sysadmin@example.com' ; → should be overwritten with useful values in installation.ini
resources.ZfExtended_Resource_Logger.writer.mail.receiver[] = 'sysadmin@example.com' ; → should be overwritten with useful values in installation.ini
resources.ZfExtended_Resource_Logger.writer.mail.receiver[] = 'other-important-person@example.com' ; → should be overwritten with useful values in installation.ini

resources.ZfExtended_Resource_Logger.writer.mail.type = 'Database'
; via the formatter define what the user gets: full debug content, or only notice and so on.
resources.ZfExtended_Resource_Logger.writer.mail.filter[] = "level <= debug" ; logs from fatal to debug

resources.ZfExtended_Resource_Logger.writer.tasklog.type = 'editor_Logger_TaskWriter'
resources.ZfExtended_Resource_Logger.writer.tasklog.filter[] = "level <= warn" ; logs only from fatal to warning

; example for an additional filter to log from fatal to debug for events with an domain starting with "core.foo.bar"
resources.ZfExtended_Resource_Logger.writer.tasklog.filter[] = "level <= debug; domain ^= core.foo.bar" 

; The TaskWriter is a editor specific writer, it logs only events containing information about a task. The events are logged in a dedicated table, accessable via the frontend. Only warnings or events more severe as warnings are written to the task log. So no notices about tasks are additionally logged.

// use the default logger instance:
$logger = Zend_Registry::get('logger');
$logger->addWriter('name', $writerInstance);

Filtering

Each writer can have an list of filter rules. See the above module.ini example. The filter rules are connected via "or", that means one of the filter rules must be valid in order that an event  is logged.

resources.ZfExtended_Resource_Logger.writer.tasklog.filter[] = "level <= warn" ; first filter rule
resources.ZfExtended_Resource_Logger.writer.tasklog.filter[] = "level <= debug; domain ^= core.foo.bar" ; second filter rule

Each filter rule is it self, a semicolon separated list of expressions. All expressions of one rule are connected via "and", so all expressions must be evaluated to true in order that the rule is valid.

An expression consists of a keyword, an operator and a value, for example: "level <= warn". Each keyword can be used multiple times, so "level >= warn; level <= trace" would also be possible.

In the following table a list of valid keywords and operands is listed:

...

Is used to compare with the log levels as defined at the top of this page.

The second operand must be a valid log level: "fatal", "error", "warn" etc.
Since internally the levels are integers, only numeric operators are usable here.

Example: given FATAL(1), configured "level <= WARN(4)" the event is filtered, since level 1 (fatal) is lesser then level 4 (warn)

...

=

...

The domain (origin) of the event must be matched completely.

...

documentation about the configuration of the LogWriters is here.

Logging Database Tables

Currently there are two database tables receiving events:

• Zf_errorlog via ZfExtended_Logger_Writer_Database
• LEK_task_log via editor_Logger_TaskWriter

Whats the difference?

Zf_errorlog receives basicly ALL events, limited by the configured log level of events to be received.

LEK_task_log receives:

• only events which contain a task in its extra data
• only events higher as the configured log level for that writer
• The content of that table is available via API to provide information to the tasks in the GUI

-- instead of 
select * from Zf_errorlog;
-- use for better readability:
select * from Zf_errorlog\G

Exceptions

In translate5 to less different exception types were used till now. Mostly just a ZfExtended_Exception was used.

To be more flexible in filtering on logging exceptions but also on internal exception handling with try catch more exceptions are needed.

See the following page for the usage and the idea behind exceptions in translate5.

EventCodes

The EventCodes used in exceptions and other logging usages are defined via the ErrorCodes listed and maintained in git..

Prevent Log Duplications

BearbeitenOne problem are duplicated log entries flooding the log if for example an attached service is not reachable anymore.

To prevent this, specific event codes can be configured, so that for that codes no additional log is send, if the same error pops up multiple times. The time interval for recognition as duplicate is currently fixed to 5 minutes. Since this affects in general use only some errors, the design reason to set this per event code, is just to prevent logging loss in the case that wanted errors happens multiple times.

// activates the duplication recognition by the formatted and rendered error message.
// for places where event codes are added with editor_Services_Connector_Exception::addCodes just add the addDuplicates calls directly afterwards.
// so the messages 'Test Error for "FOO"' and 'Test Error for "BAR"' are considered different, even if the event code is the same, and also the message template is the same: 'Test Error for "{variable}"'
ZfExtended_Logger::addDuplicatesByMessage('E1317', 'E1318'); 

//Configured that way, the variables in the message will play no role anymore:
ZfExtended_Logger::addDuplicatesByEcode('E1319', 'E1234'); 

// if duplication recognition should be used for events defined in exceptions, just override the template function ZfExtended_ErrorCodeException::setDuplication: 

class Demo_Exception extends ZfExtended_ErrorCodeException {

    static protected $localErrorCodes = [
        'E1234' => 'Demo Error.',
    ];

    protected function setDuplication() {
        parent::setDuplication();
        ZfExtended_Logger::addDuplicatesByMessage('E1234');
    }
}

Domains

The domains are used to classify and therefore filter exceptions and log entries. In the filter process the event code is added to the domain internally, that enables filtering for concrete event codes too.

How domains should be defined and used see the following examples. In general the domains are dot separated strings. Starting on the left side from the general identifier to more specific identifier on the right.

Three starting domains are defined so far: "editor" for the editor module, "core" for core code, "plugin" for plugin code.

Domain Examples:

core                                ./library/ZfExtended/Exception.php
core                                ./library/ZfExtended/Logger.php
core.api.filter						./library/ZfExtended/Models/Filter/Exception.php
core.entity                         ./library/ZfExtended/Models/Entity/Exceptions/IntegrityConstraint.php
core.entity                         ./library/ZfExtended/Models/Entity/Exceptions/IntegrityDuplicateKey.php
core.worker                         ./library/ZfExtended/Worker/TriggerByHttp.php
core.authentication
editor.customer                     ./application/modules/editor/Controllers/CustomerController.php
editor.export.difftagger            ./application/modules/editor/Models/Export/DiffTagger/Exception.php
editor.export.fileparser            ./application/modules/editor/Models/Export/FileParser/Exception.php
editor.import                       ./application/modules/editor/Models/Import/Exception.php
editor.import.configuration         ./application/modules/editor/Models/Import/ConfigurationException.php
editor.import.fileparser            ./application/modules/editor/Models/Import/FileParser/Exception.php
editor.import.fileparser.csv        ./application/modules/editor/Models/Import/FileParser/Csv/Exception.php
editor.import.fileparser.sdlxliff   ./application/modules/editor/Models/Import/FileParser/Sdlxliff/Exception.php
editor.import.fileparser.xlf        ./application/modules/editor/Models/Import/FileParser/Xlf/Exception.php
editor.import.metadata              ./application/modules/editor/Models/Import/MetaData/Exception.php
editor.import.metadata.pixelmapping ./application/modules/editor/Models/Import/MetaData/PixelMapping.php
editor.import.relais                ./application/modules/editor/Models/RelaisFoldertree.php
editor.languageresource.service     ./application/modules/editor/Services/Manager.php
editor.languageresource.service     ./application/modules/editor/Services/NoServiceException.php
editor.languageresource.taskassoc   ./application/modules/editor/Controllers/LanguageresourcetaskassocController.php
editor.segment                      ./application/modules/editor/Models/Segment/Exception.php
editor.segment                      ./application/modules/editor/Models/Segment/UnprocessableException.php
editor.segment.pixellength         

Logging Database Tables

Currently there are two database tables receiving events:

• Zf_errorlog via ZfExtended_Logger_Writer_Database
• LEK_task_log via editor_Logger_TaskWriter

Whats the difference?

Zf_errorlog receives basicly ALL events, limited by the configured log level of events to be received.

LEK_task_log receives:

• only events which contain a task in its extra data
• only events higher as the configured log level for that writer
• The content of that table is available via API to provide information to the tasks in the GUI

-- instead of 
select * from Zf_errorlog;
-- use for better readability:
select * from Zf_errorlog\G

Exceptions

In translate5 to less different exception types were used till now. Mostly just a ZfExtended_Exception was used.

To be more flexible in filtering on logging exceptions but also on internal exception handling with try catch more exceptions are needed.

See the following page for the usage and the idea behind exceptions in translate5.

EventCodes

The EventCodes used in exceptions and other logging usages are defined via the ErrorCodes listed and maintained in confluence..

Domains

The domains are used to classify and therefore filter exceptions and log entries.

How domains should be defined and used see the following examples. In general the domains are dot separated strings. Starting on the left side from the general identifier to more specific identifier on the right.

Three starting domains are defined so far: "editor" for the editor module, "core" for core code, "plugin" for plugin code.

Domain Examples:

editor.customer                 ./application/modules/editor/Controllers/CustomerController.php

editor.task                     ./application/modules/editor/Controllers/TaskController.php

core                            ./library/ZfExtended/Logger.php

core                            ./library/ZfExtended/Exception.php

editor.workflow                 ./application/modules/editor/Logger/Workflow.php

...

 ./application/modules/editor/Models/Segment/

...

PixelLength.php

...

editor.

...

terminology					./application/modules/editor/Models/

...

Term/

...

TbxCreationException.php

...

editor.task                         ./

...

application/

...

modules/

...

editor/

...

Controllers/

...

core.entity                     ./library/ZfExtended/Models/Entity/Exceptions/IntegrityConstraint.php

...

TaskController.php
editor.task.exceleximport           ./application/modules/editor/Models/Excel/ExImportException.php
editor.workflow                     ./application/modules/editor/

...

Logger/

...

Workflow.php

...

editor.

...

workflow.notification        ./application/modules/editor/

...

Workflow/

...

Actions/

...

Abstract.php

...

plugin.groupshare

...

                   ./application/modules/editor/Plugins/GroupShare

...

/

...

Exception.php

...

plugin.

...

groupshare.

...

httpapi.

...

tmservice ./application/modules/editor/

...

Plugins/

...

GroupShare/HttpApiTMService.php

...

plugin.

...

groupshare.

...

httpapi.web       ./application/modules/editor/

...

Plugins/

...

GroupShare/HttpApiWebAPI.php

...

plugin.

...

groupshare.token             ./application/modules/editor/

...

Plugins/

...

GroupShare/

...

ExceptionToken.php

...

plugin.matchanalysis                ./application/modules/editor/

...

Plugins/

...

MatchAnalysis/Exception.php

...

plugin.okapi                        ./application/modules/editor/

...

Plugins/

...

Okapi/Exception.php

Use the logger facility just to log stuff

...