Status API

= Why do we need this API?

There have been at least 3 plugins in the wild which do Nagios monitoring of various parts of moodle, in particular the cron status. The requirement for monitoring of some form is very clear. The main draw back to these approaches has been that adding additional monitoring for other parts of Moodle has mean the monitoring code is maintained completely separately to the main code. Each component should be responsible for providing it's own definition of health.

Declaring a the metrics for a plugin

Each plugin can declare as many metrics as they want and are dynamically registered with the Status API via a hook in lib.php:

/admin/tool/task/lib.php: function tool_task_define_metrics(){

   return array(
       '\tool_task\metric\cronlastrun',
       '\tool_task\metric\scheduledtask',
   );

}

By making this a function and not a static file the db directory like other approaches in the past, the system properly account for how moodle is configured. For instance auth_ldap could declare a bind test metric, but if the ldap auth is disabled then we don't want to know about the metric at all or show it in any reports or checks.

/auth/ldap/lib.php: function auth_ldap_define_metrics(){

   TODO add enabled test
   return array(
       '\auth_ldap\metric\bindlatency',
   );

}

Implementing a metric

Each metric is an autoloaded class which extends a \tool_status\metric_base,

Metric dependencies

Because the system is aggregating metrics, and some functionality may be dependent on other systems or plugins, we need a way to declare dependencies between metrics so the system can properly report on the root cause of issues and give succinct actionable messages.

Monitoring overall status

There are several use cases for monitoring and this API aims to be flexible enough to work with any approach:

1) A standalone moodle with no or few dependencies and wants it's own 'Status' page 2) A moodle with an external monitoring tool such as Nagios / Icinga, or much simpler tools like Monastic 3) A full blown 'status' page which is user facing and hosted separately to the main app

To accommodate these various architectures the Status API can be used via:

1) An optional simple user facing html page which can be set to public or not. 2) A very lightweight unauthenticated web API which returns 200 or 503 and a summary message 3) A cli script, which happens to be NRPE compliant but can be used will almost any command line monitoring tool 4) A moodle webservice for querying of the full status list of metrics and details 5) Lastly for any other complex needs the internal php API can be queried from say a tool_xyz which integrates with a 3rd party status API