Use case 1:
In an alternate reality, Tiki Consultant sets up a Nagios/Icinga/Shinken instance to track all Tiki sites he has been associated with. Data is logged quietly in the background.
When an issue is reported, he can look at historical data and see what changed and have a clue. As a bonus, he can indicate to the customer that hosting company made changes to the server without advising anyone. Tiki Consultant is a hero (and can bill that time), and hosting company is not. If Nagios/Icinga/Shinken could alert the Tiki Consultant of changes, it would permit Tiki Consultant to review changes and to evaluate if there are any risks of issues.
Use case 2: run on all *.tiki.org sites to help reliability.
Use case 3: run on pre-dogfood servers and if we notice something went awry (ex: requires more RAM), we have a clear indication of which day the commit came in.
We have 50+ beautiful checks in tiki-check.php Surely it can't be hard to make them accessible to an outside monitoring system?
OK this task is kind of broad and unactionable, so I have broken it down into actionable sub-tasks. It is more of an ongoing thing anyway.
1) Document the state of testing going on tiki.org sites, collect historical information, and produce monthly report on pass/fail on various checks. (some of these checks might fail a lot of the time with no problem, but collecting the historical info is useful to tune the tests for future, notification can be disabled for most of these checks).
2) If possible, provide easy access to the monitoring dashboard for tiki.org sites.
3) Increase the number of checks on the Tiki.org sites. There is a scalability issue here - it might require more machines and changi's shinken setup might scale better than amette's icinga setup. Anyway, the more checks the better, even if it is to understand better how Tiki sites behave under various situations, in various measured parameters.
4) Organize TMIT webinar on "how did we setup a Tiki monitoring infra". Will invite all sysadmins to describe/present their setup. The idea is not to do an academic study on the umpteen ways to do such a thing but just to present what has been done.
I will create separate tasks for each of these
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
Unable to connect to show.tikiwiki.org. Please let us know of the problem so that we can do something about it. Thanks.