Loading...
 
Skip to main content

Monitoring Tiki

Tiki includes tiki-monitor.php, a JSON endpoint that can be used by monitoring systems such as Nagios, Zabbix, Icinga, and Shinken. It reports selected application health values and supports IP restrictions, token-based authentication, role-based data visibility, custom probes, and custom HTTP status codes for failed probes.

General monitoring recommendations

For complete monitoring, use tiki-monitor.php together with ordinary system and web checks.

Nagios / Icinga / Shinken examples

  • Ensure required services are running.
    • Apache or another web server
    • MySQL or MariaDB, including test queries with tools such as check_mysql
  • Ensure adequate memory, CPU, and disk space are available with tools such as check_mem, check_load, and check_disk.
  • Ensure the web site is reachable.
    • Use check_http to check a specific page.
    • Use check_webinject to script a login or more detailed site workflow.
  • Track site performance over time with tools such as pnp4nagios or nagiosgraph.

Tiki monitoring endpoint

The endpoint is available at the root of a Tiki installation:

Copy to clipboard
https://<domain>/tiki-monitor.php


Replace <domain> with the real domain of the Tiki site.

Access without a token

If the monitor_token preference is empty, anyone who can reach the endpoint can access the public monitor data, subject to any IP restrictions configured with monitor_restricted_ips.

Copy to clipboard
curl https://<domain>/tiki-monitor.php


For public sites, configure a token before exposing tiki-monitor.php.

Token-based authentication

Set the monitor_token preference to require authenticated monitoring requests. When monitor_token is set, requests with a missing or invalid token return 401 Unauthorized.

The configured token value can be passed as:

  • a GET or POST parameter named monitoring_token
  • an HTTP header named X-Tiki-Monitoring-Token


GET parameter

Copy to clipboard
curl "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"


POST parameter

Copy to clipboard
curl -X POST https://<domain>/tiki-monitor.php \ -F "monitoring_token=your_token_here"


HTTP header

Copy to clipboard
curl -X POST https://<domain>/tiki-monitor.php \ -H "X-Tiki-Monitoring-Token: your_token_here"


Prefer HTTPS so the token is not sent in clear text. Prefer the header method when URLs may be logged by proxies or monitoring tools.

IP restriction

Use monitor_restricted_ips to define a comma-separated list of IP addresses allowed to access tiki-monitor.php.

Copy to clipboard
127.0.0.1,192.168.1.10


Requests from other IP addresses return 403 Forbidden.

Configuration

Configure the monitoring preferences in tiki-admin.php?page=performance, under the Monitor tab.

Image

PreferencePurpose
monitor_restricted_ipsOptional comma-separated list of IP addresses allowed to access tiki-monitor.php.
monitor_token Optional shared token required for monitoring requests when set.
monitor_rulesOptional visibility rules for public and authenticated monitor data.
monitor_probesOptional formulas that evaluate monitor values and report OK or FAIL.

JSON output

A successful request returns JSON. The exact values depend on the server, PHP opcode cache, scheduler setup, database state, search index state, and configured monitor rules.

Sample response
Copy to clipboard
{ "OPCodeCache": "OPcache", "OpCodeStats": { "opcode_cache": "OPcache", "stat_flag": null, "warning_check": false, "warning_fresh": false, "warning_ratio": false, "warning_starve": false, "warning_low": false, "warning_xcache_blocked": false, "hit_hit": 0.99, "hit_miss": 0.01, "hit_total": 234249, "memory_avail": 0.37, "memory_used": 0.63, "memory_total": 132057840 }, "DbRequiresUpdate": false, "SearchIndexRebuildLast": "1784681759", "SchedulerLastRun": 1752834313, "SchedulerHealthy": 0, "Probes": { "result": "OK", "details": [] } }


Common fields:

  • OPCodeCache: detected PHP opcode cache, for example OPcache.
  • OpCodeStats: cache health and memory statistics. Values such as memory_used are ratios, so 0.63 means 63% used.
  • DbRequiresUpdate: true when Tiki detects pending database updates, otherwise false.
  • SearchIndexRebuildLast: timestamp of the last unified search index rebuild for the configured search engine.
  • SchedulerLastRun: Unix timestamp of the last recorded scheduler run, or 0 if no run is recorded.
  • SchedulerHealthy: 1 when scheduler execution is configured, 0 when it is not.
  • Probes: overall custom probe status and per-probe details. Without configured probes, the default is OK with an empty details list.

Monitor rules

monitor_rules controls which JSON fields are visible to public and authenticated requests. Each rule has the form MonitorName:role, one per line.

The supported roles are:

  • public: available without token authentication.
  • auth: available to admin sessions or requests authenticated with the configured monitor_token.


If monitor_rules is empty, Tiki uses these defaults:

Copy to clipboard
OPCodeCache:public OpCodeStats:public DbRequiresUpdate:public SearchIndexRebuildLast:public *:auth


Example custom rules:

Copy to clipboard
OPCodeCache:auth SearchIndexRebuildLast:public OpCodeStats.opcode_cache:public OpCodeStats:auth *:auth


With these rules, public users see only selected values, while authenticated requests can see broader data. Rules can target nested values, for example OpCodeStats.memory_used:public.

Custom probes

Use monitor_probes to define specific checks using Tiki calculation syntax. Add one formula per line.

Probe examples
Copy to clipboard
(equals SchedulerHealthy 1) (less-than OpCodeStats.memory_used 0.85) (less-than SearchIndexRebuildLast NOW)


The endpoint reports probe results in the Probes section:

Copy to clipboard
{ "Probes": { "result": "OK", "details": { "probe_1": "OK", "probe_2": "OK" } } }


If one or more probes fail, Probes.result is set to FAIL and each probe status is listed in details.

When a probe refers to a timestamp value, a numeric probe value can be interpreted as an offset in minutes by the monitor script. The special value NOW is replaced with the current Unix timestamp.

HTTP methods and custom error codes

The endpoint supports ordinary GET and POST requests. It also checks monitoring_error_code, or the X-Tiki-Monitoring-Error-Code header, when probes fail.

If Probes.result is FAIL and the supplied code is between 200 and 599, Tiki sends that HTTP status code.

GET parameter

Copy to clipboard
curl "https://<domain>/tiki-monitor.php?monitoring_error_code=503"


POST parameter

Copy to clipboard
curl -X POST https://<domain>/tiki-monitor.php \ -F "monitoring_error_code=503"


HTTP header

Copy to clipboard
curl https://<domain>/tiki-monitor.php \ -H "X-Tiki-Monitoring-Error-Code: 503"


For HEAD requests with a failing probe and a valid custom error code, the endpoint sends the status code and exits without a JSON body.

Additional monitoring scripts

Tiki includes helper scripts for monitoring integrations:


Example:

Copy to clipboard
php doc/devtools/check_tiki.php \ -u "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here" \ --bccwarn 80 --bcccrit 90 \ --sirwarn 86400 --sircrit 172800


Before using the helper script, verify that the same URL returns JSON:

Copy to clipboard
curl "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"


Example for check_tiki-new.php:

Copy to clipboard
php doc/devtools/check_tiki-new.php \ -u "https://<domain>" \ --user "username" --pass "password"


The -u value must include the URL scheme, such as https:// or http://.

For simple uptime tools, a direct HTTP check is enough:

Copy to clipboard
curl --fail "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"

Source code