We are here to create an open source monitoring solution that is :

1. easy to install;
2. easy to use for new users;
3. useful for sys admins and business types;
4. built for scalability;
5. incorporates high availability;
6. multi-platform (and not just unix ones);
7. utf8 compliant;
8. nearly fully compatible with Nagios configuration;
9. fully compatible with its plugins and interfaces;
10. fast enough
11. centralized configuration that should be as easy as possible for the admin to manage;
12. independent from any huge monitoring solution;
13. fun to code :)

More precisely :

• The 2 first points are to make the system accessible to more people by automating and pre-building the typical monitoring environments so that users can focus on customizing, not getting the basics working. It is also through new methods of defining templates that are more logical and intuitive for users.

• Shinken provides a business monitpring service not just an IT focused service. This means helping users differente between real business impacting outages and minor IT related failures.

• The next two are for the global architecture. We should be able to scale the load within minutes without losing the high availability feature. We believe this has been successfully implemented. :)

• Multi platform is also important. If we only focused on GNU/Linux, a large user segment would be left out (Windows!). Of course, some features inherited from Nagios are Unix-only like named pipes, but we should promote other ways for users to bypass this (like commands sent to livestatus or in a web based API for example). Such “os limited” points should be if possible limited to modules. (named pipes will be modules in the future for example). Shinken runs on windows, making it easy to run native windows based testing without additional agents.

• UTF8 compatible : ¤§² should be a valid name for a server… ok, it's a joke :) But some users want to have Japanese and Chinese characters. UFT8 is not an option in the 21st century ;)

• Nearly compatible with Nagios configuration : No mistake, nearly. Shinken is not a Nagios fork. It will never be 100% compatible with it, because some Nagios parameters will never be useful in our architecture like external_command_buffer_slots (why impose artificial limits?) or retained_host_attribute_mask (has anyone used these?). We could manage them. But are they useful? No. Users won't use them, so let's focus on innovation that users want. If there truly is a use case for some oddball feature, we can consider backporting, on condition it is not incompatible or rendered obsolete by the Shinken architecture. Though it will compete with other feature requests and project direction.

• Fully compatible with plugins : plugins are the life blood of the monitoring system. There is great user value in the plugins, not so much in the legacy core. Shinken is deemed fully compatible and will remain that way. Easy plugins is onereason why Zenoss did not crush Nagios.

• Fast enough : We've got scalability. We've got a high-level programming language that makes it easy to develop powerful networked code. It provides decent speed, making it easy for every sysadmin to have what he wants. Hunting for the last few percent of performance always costs a lot in code hacking, making it far harder to maintain. Let these few percents rest, we don't need them.

• Independent from any huge monitoring solution provider : our goal is to provide a tool that allows them to run, but not to make a tool that is only compatible with only one of them. It should always be ok to run without any of them. We welcome all-in-one monitoring solution providers who want to use Shinken as the core of their product, but Shinken will remain independent.

• Fun to code : the code should be good and foster innovation. While respecting that technical debt should always be paid one day.

This is what we want to have (and already have for the most part).

At the beginning of the project, we used to say that what we didn't want was our own webui. This became a requirement. Why? Because none of the current UIs truly provided the right way to prioritize and display business oriented information to the end users. Features like root problem analysis or business impact. After trying to adapt the external UIs, we had to roll our own. So we did. :)

So there is nothing we do not want, if in the end it helps Shinken's users.