README

Adds scheduler, system log and log file insights to the endpoint of t3monitoring_client, so your monitoring shows right away when something goes wrong inside a TYPO3 installation:

Scheduler – did the scheduler run recently? Which tasks failed, are overdue or stuck?
System log – errors of sys_log in the last hours, grouped by message, and the number of failed backend logins.
Log files – errors written to var/log/typo3_*.log (e.g. uncaught frontend exceptions that never show up in sys_log).
Composer – the version constraints of the root composer.json, so a monitoring server can tell whether an available update only needs composer update or a changed constraint (composer require).
PHP – the full PHP version and the build date of the PHP binary, so a monitoring server can estimate whether a security release was applied by the provider without raising the version number (backports of distributions and hosters).


Extension key	`t3monitoring_client_extended`
Composer name	`yesjoar/t3monitoring-client-extended`
TYPO3	12.4, 13.4, 14
PHP	8.2 – 8.5
Requires	`t3monitor/t3monitoring_client` 11

Installation

composer require yesjoar/t3monitoring-client-extended

There is nothing else to set up: the extension registers its providers in t3monitoring_client. The next request to ?eID=t3monitoring&secret=… contains the additional data.

What the endpoint delivers

The result is delivered twice, so it is useful for the t3monitoring server as well as for other monitoring servers:

Messages in extra (warning / danger), the groups the t3monitoring server imports and shows for a client, e.g. Scheduler - 2 failed task(s) or Log files - 14 error(s) in the last 24 hours. They work without any change of the server.
Structured data in extended for monitoring servers that want to evaluate it:

{
  "extended": {
    "version": 1,
    "scheduler": {
      "available": true,
      "lastRunStatus": "ok",
      "lastRun": { "start": 1790000000, "end": 1790000004, "type": "cron" },
      "tasks": { "total": 8, "enabled": 6, "disabled": 2, "failed": 1, "overdue": 0, "stuck": 0 },
      "problems": [
        {
          "uid": 12,
          "type": "failed",
          "task": "Vendor\\Extension\\Task\\ImportTask",
          "description": "Import products",
          "since": 1789999000,
          "message": "Could not reach https://api.example.org/?… (#1700000000)"
        }
      ]
    },
    "sysLog": {
      "periodHours": 24,
      "errors": 3,
      "failedLogins": 0,
      "groups": [
        { "channel": "php", "message": "Core: Exception handler (WEB): …", "count": 2, "first": 1789990000, "last": 1789995000 }
      ],
      "truncated": false
    },
    "logFiles": {
      "periodHours": 24,
      "entries": 14,
      "files": 1,
      "groups": [
        { "level": "error", "component": "TYPO3.CMS.Frontend", "message": "…", "count": 14, "first": 1789990000, "last": 1789995000 }
      ],
      "truncated": false
    },
    "composer": {
      "available": true,
      "require": { "georgringer/news": "^12.3", "typo3/cms-core": "^13.4" },
      "requireDev": { "typo3/testing-framework": "^9.0" }
    },
    "php": {
      "version": "8.2.7-1~deb12u1",
      "sapi": "fpm-fcgi",
      "buildDate": 1792598261,
      "buildProvider": null
    }
  }
}

composer is plain data without messages: package names (with a vendor) and their constraints. It is only evaluated by monitoring servers that know the available versions; available is false without Composer mode.

php is plain data without messages as well. version includes the suffix of distribution packages, which t3monitoring_client cuts off. buildDate is the build date of the PHP binary that runs the website (PHP 8.5: PHP_BUILD_DATE, before: the line "Build Date" of phpinfo()); it is null if phpinfo() is disabled. A binary built after a security release probably contains the fixes even if its version number is older. buildProvider is only set from PHP 8.5 on, if the binary was built with it.

All times are Unix timestamps. scheduler.lastRunStatus rates the last run by the configured thresholds: ok, warning, error, never (tasks are enabled, but the scheduler never ran) or unused (no enabled tasks). version is increased on incompatible changes of the format. If a provider fails, the endpoint keeps working: the error is reported in extended.errors.<provider> and as a warning in extra.

Configuration

Admin Tools → Settings → Extension Configuration → t3monitoring_client_extended

Setting	Default	Description
`scheduler.enabled`	1	Report the scheduler
`scheduler.lastRunWarningMinutes`	60	Warning if the scheduler did not run for this long
`scheduler.lastRunErrorMinutes`	360	Error if the scheduler did not run for this long
`scheduler.overdueMinutes`	60	An enabled task is overdue if its planned execution is older
`scheduler.stuckMinutes`	240	A task is stuck if it is marked as running for longer
`sysLog.enabled`	1	Report errors of `sys_log`
`sysLog.periodHours`	24	Period that is evaluated
`sysLog.maxGroups`	10	Number of different errors that are reported
`sysLog.failedLoginsWarning`	50	Warning from this number of failed backend logins (0 = off)
`logFiles.enabled`	1	Report errors of the log files
`logFiles.periodHours`	24	Period that is evaluated
`logFiles.maxGroups`	10	Number of different errors that are reported
`logFiles.minimumLevel`	error	Minimum PSR-3 level (`warning` … `emergency`)
`logFiles.maxBytesPerFile`	1048576	Only the end of each log file is read
`composer.enabled`	1	Report the version constraints of `composer.json`
`php.enabled`	1	Report the PHP version and build date
`ignoredMessages`		Comma separated text fragments; matching entries are skipped

Privacy and security

The data leaves the installation, so it is reduced on purpose:

No user names, IP addresses or record data of sys_log are read; only the message of an entry.
Query strings of URLs (which may contain secrets), email and IP addresses are removed from all messages.
Messages are limited to 300 characters; equal messages are grouped.
Scheduler tasks are never unserialized, so no code of task classes is executed.
Of composer.json only package names and version constraints are read – no repositories or credentials.
Of phpinfo() only the line "Build Date" is read; nothing else of it (environment, paths, settings) is delivered.

Every provider can be disabled, also in config/system/additional.php:

$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['t3monitoring_client_extended']['composer']['enabled'] = '0';

The endpoint itself is protected by t3monitoring_client (secret and allowed IPs).

Development

The checks run in Docker with the images of the TYPO3 core testing:

Build/Scripts/test.sh              # TYPO3 13.4, PHP 8.3: coding standards, PHPStan, unit and functional tests
Build/Scripts/test.sh 12.4 8.2
Build/Scripts/test.sh 14.0 8.4 functional

Release

The extension is distributed via Packagist only.

Set the version in ext_emconf.php and in composer.json (extra.typo3/cms.version), update CHANGELOG.md.
Create and push a tag with the version, e.g. git tag -a 1.0.0 -m "First stable release" && git push --tags. Packagist picks up the tag through its GitHub hook.

License

GPL-2.0-or-later. Developed by Kai Seliger.

yesjoar / t3monitoring-client-extended

Package info

Security

Statistics