DEPRECATION WARNING

This documentation is not using the current rendering mechanism and is probably outdated. The extension maintainer should switch to the new system. Details on how to use the rendering mechanism can be found here.

MK LOGGER

Installation

Install TYPO3 via composer. Maybe you can use our TYPO3-Composer-Webroot Project

From project root you need to run

composer require dmk/mklog

Developer Log

TYPO3 provides a functionality for logging information for the purposes of development and debugging. However this functionality doesn't do anything by itself. MK LOG provides a log writer to handle the informations from this logging. The informations are stored in a database table and can be browsed using the build in backend module.

Extension Configuration

  • enable_devlogEnables the logger. This is required, otherwise the Developer log will nort work.
  • min_log_levelOnly messages with minimum these log level should be logged. The allowed levels are described below.
  • exclude_ext_keysA comma seperated list of extension keys that should not be logged
  • max_logsThe absolute limit of log messages stored in the database. If that limit is reached all older logrund are deleted. If you don't want any limit, set this parameter to zero.

Gelf Logger

This logger is designed to transport emergency messages to an gelf compatible backend like Graylog2.A log message with a severity of ALERT or EMERGENCY can usualy not be written into the database. These messages has to transport directly. Otherwise they will be lost.Just that this was created.

Extension Configuration

  • gelf_enableEnables the gelf logger.
  • gelf_credentialsThe gelf logger comunicates with a udp ransport. fill the host and port here like 127.0.0.1:12201
  • gelf_min_log_levelOnly messages with minimum these log level should be transportet. We recommed to use here ALERT for performance reasons. All other log messages schould logged with the devlog into the database.

How to log

We recommend to use the static utility Tx_Rnbase_Utility_Logger as warpper.

The recommend way with the wrapper

    Tx_Rnbase_Utility_Logger::debug('tx_myext', 'only a debug info');

The direct way

    $logManager = t3lib_div::makeInstance('TYPO3\\CMS\\Core\\Log\\LogManager');
    $logger = $logManager->getLogger($'tx_myext');
    $logger->debug('only a debug info');

The old way with the wrapper over the classic logging hook

    tx_rnbase_util_Logger::debug('only a debug info', 'tx_myext');

The old direct way over the classic logging hook

    t3lib_div::devLog('only a debug info', 'tx_myext', -1);

Log Levels

  • EMERGENCYsystem is unusable. You'd likely not be able to reach the system. You better have an SLA in place when this happens.
  • ALERTaction must be taken immediately. Entire website down, database unavailable, ...
  • CRITICALcritical conditions like unexpected exception.
  • ERRORerror conditions like runtime errors.
  • WARNINGwarning conditions. Use of deprecated APIs, undesirable things that are not necessarily wrong.
  • NOTICEnormal but significant condition. Things you should have a look at, nothing to worry about though.
  • INFOinformational messages like User logs in or SQL logs.
  • DEBUGdebug-level messages with detailed status informations.

Scheduler

DevLog WatchDog

The devlog scheduler checks the devlog entries for new messages and sends these messages throu a transport.

Currently there are a mail and some gelf transports.

The credentials are Transport specific:

  • Mail MessageOnly the email: john@dohe.org
  • Gelf UDPThe host and port of the server: 127.0.0.1:12201
  • Gelf HTTPThe complete url of the server: https://admin:admin@127.0.0.1:2345/gelf
  • Message limit per runMax message count to send throu the transport for each scheduler run. Set to 0 to disable the limit.

tx_devlog Scheduler

You have to provide an email address which receives the mails.

Furthermore you can choose from which severity on devlog entries should be sent. If you set it to WARN, all entries with the serverity of WARN and ERROR will be sent via mail.

Note, you will only get entries which are new since the last run. If nothing new no mail will be sent. Except if you force a summary mail.

It is even possible to include the data_var/extra_data field of a devlog entry into the mail.

Additional features

Normally when a page is copied the tx_devlog entries are copied along (depending on the permissions). This is annoying and can lead to confusion as those entries are recognized as new even though they aren't. That's why this extensions hooks into the copy process and removes the devlog table from the list of tables which can be copied. This happens for all admins as well.

When a page is deleted by a non admin TYPO3 checks if the user has permissions to delete all tables on that page. This is fine except for the devlog table as this can be safely deleted and users shouldn't have permissions for those. That's why this extensions hooks into the deletion process and deletes all devlog entries on a page before the page is deleted ignoring permissions.