|
The primary monitoring script, tiki-monitor.php, now supports multiple options to integrate seamlessly with external monitoring systems like Nagios, Zabbix, and Icinga.
- IP Restriction:
- Define IP addresses allowed to access the monitoring script. Set the
monitoring_restricted_ips preference with a comma-separated list of IPs, ensuring only specified addresses can initiate requests. This setting complements the existing $tikiMonitorRestriction option for backward compatibility.
- Example Configuration:
Copy to clipboard 127.0.0.1,192.168.1.10
- Token-Based Authentication:
- Set a monitoring_token preference to authenticate requests via a secure token.
The token can be passed as:
- A GET or POST parameter with the name
monitoring_token
- An HTTP header
X-Tiki-Monitoring-Token
- Requests with an invalid token return HTTP 401, preventing unauthorized access.
- Token Usage Examples:
- GET Parameter:
Copy to clipboard curl --location '/tiki-monitor.php?monitoring_token=your_token_here'
- POST Parameter:
Copy to clipboard curl --location '/tiki-monitor.php' --form 'monitoring_token=your_token_here'
- HTTP header:
Copy to clipboard curl --location --head '/tiki-monitor.php' --header 'X-Tiki-Monitoring-Token: your_token_here'
- Role-Based Data Visibility:
- Configure data visibility with the monitoring_auth preference to control which data is accessible to authenticated vs. public users.
- Define rules such as
OPCodeCache:auth or *:auth to specify visibility at the key level in JSON output, allowing fine-grained control over what each role can see.
- Two roles are supported:
-
public: Default role with access to limited data.
-
auth: Role for authenticated users (admin or valid token).
Users with auth can see both public and restricted data based on rule configuration.
- Example Rule:
Copy to clipboard OPCodeCache:auth
SearchIndexRebuildLast:public
OpCodeStats.opcode_cache:public
OpCodeStats:auth
*:auth
- With these rules, public users would only see selected keys, while authenticated users would have broader access. If no custom rules are provided, defaults apply to retain backward compatibility.
- Custom Probes:
- Use the monitoring_probes preference to define specific checks (probes) using Tiki’s calculation syntax.
- Examples of probes:
- Basic Comparison:
Copy to clipboard (less-than SearchIndexRebuildLast 10)
- Timestamp Comparison:
Copy to clipboard (less-than SearchIndexRebuildLast NOW)
- Equality Check:
Copy to clipboard (equals OpCodeStats.opcode_cache "OpCache")
- Sample JSON Output with Probes:
Copy to clipboard {
"Probes": {
"result": "OK",
"details": {
"probe_1": "OK",
"probe_2": "OK"
}
}
}
- If probes fail, the result field will be set to FAIL, and each probe’s status will be noted.
- HTTP Methods and Custom Error Codes:
- The script supports HEAD, GET, and POST methods:
-
HEAD: Returns no body, useful for health checks.
-
GET and POST: Standard responses based on request.
- The parameter
monitoring_error_code (passed as a GET/POST parameter or X-Tiki-Monitoring-Error-Code header) specifies a custom HTTP code (200-599) to be returned on probe failure.
- Examples of Custom Error Codes:
- GET Request:
Copy to clipboard curl --location '/tiki-monitor.php?monitoring_error_code=400'
- POST Request:
Copy to clipboard curl --location '/tiki-monitor.php' --form 'monitoring_error_code=400'
- HEAD Request:
Copy to clipboard curl --location --head '/tiki-monitor.php' --header 'X-Tiki-Monitoring-Error-Code: 400'
|