Architecture
We have tried to design a basic framework which can easily be extended on both sides. Instead of writing every possible check and hard-wiring it into the system, we have designed the system to be easily extensible with third-party services.
Service Test
The first way to extend Kinti is by writing Service Tests. These will be loaded as a plugin into the Kinti Framework to perform a certain check. The results on these checks will be handed back to the Kinti framework which will pass it to the other side.
Buckets
This other side consists of 'buckets' which will receive all test results provided by the service tests. A bucket is a separate process and communicates with Kinti using XMPP. This means that a bucket can be written in any language as long as it can communicate using XMPP. In the future, the Kinti framework will let a bucket receive test results from different servers. It's important to note that there doesn't have to be a one-to-one relationship between service tests and buckets.
By allowing the user to extend the system on both sides we achieve great flexibility; for example an ftp-service-test has only to be written and loaded once and its results can thereafter be used by different buckets. One bucket might send an email to the administrator when the server goes down and another might just write status messages to a log file.
Flow
The basic Kinti framework gathers data from different tests, gathers the results and passes them on to the buckets. Kinti will also read the configuration files, automatically reload them if they have changed, and will give them to the buckets and service tests. Except for the exchange of config files, all messages will flow through the system from left to right, that is; from service tests to buckets at the end.