I have recently been doing a lot of development work for a very large Known installation. This installation is highly customised, has many active users, all doing unexpected and creative things with the platform, and makes use of many of Known’s more advanced features in often quite unexpected ways.

As with everything built by mankind, sometimes things go wrong, which is especially true with something as complicated as software. Simply waiting for a user to report a fault, and for that report to bubble up through IT/management, is poor customer service. The time between the fault being found, and the report being received, is often measured in weeks, and is often misleading/missing crucial information, leading to more time spent clarifying the fault.

So, recently, I’ve been exploring a number of ways to handle any issues in a much more proactive way, and to collect objective data, rather than subjective fault reports.

Crash reports

One thing I’ve been exploring is a simple mechanism whereby Known will send an email to one or more addresses when a fatal error or exception occurs. This email contains the details of the error, as well as who was logged in at the time.

You can try this for yourself if you’re tracking Known’s master branch by adding the following to your config.ini:

oops_notify[] = 'you@yourdomain.com'

This is great for when something blows up, but often problems are much more subtle than that. For example, what happens if a change you’ve made causes an increase in page load for certain users? How would you track back and find out when it started, and what was the change that might have caused it?

Running stats and health metrics

In the latest master build, I’ve added a mechanism to start collecting useful metrics of a running system – page build time, events tracking, instances of errors, etc – which when properly analysed will give a much more useful overview of the general health of a running system.

I’m a big fan of graphs over logs for this sort of thing.

Currently the stats handler is a dummy which throws this information away, however it’d be a simple matter to extend this functionality to use something RRDTool or StatsD, with Graphite over the top to generate the graphs.

Recording your stats

If you’re a plugin writer, you can push your own statistics using the same tool, e.g.:

$stats = \Idno\Core\Idno::site()->statistics();
if (!empty($stats)) {
   $stats->increment('myplugin.somethinghappened');
}

Give it a play!

Sometimes it is desirable to execute actions in the background and periodic intervals. Building on from last week’s post, I wanted to spotlight a new feature, which uses the asynchronous event queue, to allow you to do this – the periodic execution (cron) service.

After completing the configuration step for enabling the Asynchronous Event Queue, you can then run the Known console periodic execution service:

./known.php service-cron

Once running, this service will periodically trigger an event to which code can listen to. Available events are cron/minute, cron/hourly and cron/daily.

While I’ve not really had a chance to talk about it recently, owing to being rather busy, there has been a lot of work done in Known core recently.

Known uses event queues to dispatch things like Webmention pings. By default, this dispatching is synchronous. However, an advanced feature that was recently added, was the ability to enqueue events and have them dispatched later in an asynchronous fashion, enabling faster page loading.

Configuring

As mentioned above, by default Known uses a synchronous event queue. To use something the asynchronous queue, add the following line to your config.ini:

event_queue = 'AsynchronousQueue'

Next, you need to run the Known event queue dispatching service using the Known console tool:

./known service-event-queue

Note: if you’re using per-domain configuration you’ll need to set an environment variable in order for everything to work as expected:

export KNOWN_DOMAIN='your.domain.name'

Enjoy!