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, andcheck_disk. - Ensure the web site is reachable.
- Use
check_httpto check a specific page. - Use check_webinject to script a login or more detailed site workflow.
- Use
- 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:
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.
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
curl "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"
POST parameter
curl -X POST https://<domain>/tiki-monitor.php \ -F "monitoring_token=your_token_here"
HTTP header
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.
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.
| Preference | Purpose |
| monitor_restricted_ips | Optional comma-separated list of IP addresses allowed to access tiki-monitor.php.
|
| monitor_token | Optional shared token required for monitoring requests when set. |
| monitor_rules | Optional visibility rules for public and authenticated monitor data. |
| monitor_probes | Optional 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.
{ "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 exampleOPcache. -
OpCodeStats: cache health and memory statistics. Values such asmemory_usedare ratios, so0.63means 63% used. -
DbRequiresUpdate:truewhen Tiki detects pending database updates, otherwisefalse. -
SearchIndexRebuildLast: timestamp of the last unified search index rebuild for the configured search engine. -
SchedulerLastRun: Unix timestamp of the last recorded scheduler run, or0if no run is recorded. -
SchedulerHealthy:1when scheduler execution is configured,0when it is not. -
Probes: overall custom probe status and per-probe details. Without configured probes, the default isOKwith 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 configuredmonitor_token.
If
monitor_rules is empty, Tiki uses these defaults:
OPCodeCache:public OpCodeStats:public DbRequiresUpdate:public SearchIndexRebuildLast:public *:auth
Example custom rules:
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.
(equals SchedulerHealthy 1) (less-than OpCodeStats.memory_used 0.85) (less-than SearchIndexRebuildLast NOW)
The endpoint reports probe results in the Probes section:
{ "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
curl "https://<domain>/tiki-monitor.php?monitoring_error_code=503"
POST parameter
curl -X POST https://<domain>/tiki-monitor.php \ -F "monitoring_error_code=503"
HTTP header
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:
- doc/devtools/check_tiki.php reads
tiki-monitor.phpand can check opcode cache memory, database update status, and search index freshness. - doc/devtools/check_tiki-new.php is a separate helper that checks
tiki-check.php?nagiosfrom the base Tiki URL. It does not usetiki-monitor.php.
Example:
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:
curl "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"
Example for check_tiki-new.php:
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:
curl --fail "https://<domain>/tiki-monitor.php?monitoring_token=your_token_here"