To infinity and beyond !

Extend your monitoring platfom :

The monitoring node doesn't give you what you need out of the box ? You can easily extend it with configuration packs and modules.

Configuration Packs

The configuration packs are basically "ready to run" Nagios® configurations files, with templates and commands. And if you already know how to write a Nagios® configuration file, then you know how to write Shinken configuration packs (and can help the community ;-) ).

Shinken modules

Shinken is designed to be very flexible and modular. If you want to load your configuration from a specific CMDB or export data into a brand new performance data tool, you'll be able to write modules to do that. Take a look at the sample modules, it's in Python and it's really easy.

LAN

DMZ

Multi-datacenters

Scale without limits

Easy scalability for all

Discover a world where the tool is scalable by design. Shinken has no limits regarding distribution. Scale it to your LAN, through your DMZs and even across several datacenters!

Raid like availability

You can be sure Shinken won't stop: define spare nodes, and should an active node go down, the spare will take it's place.

Mixed architectures

It's always smoother to monitor a Windows host from another Windows host, a Linux from a Linux, and so on. Hopefully, Shinken won't force you to choose between Linux and Windows, just get both! You will be able to check windows with the WMI protocol within your Active Directory domain on a Windows poller (no more password in the configuration files!), and check your network and Unix servers from a Linux poller!

Focus on your business

What really matters is not IT. Your end-users apps are.

End users applications are delivered through your IT, which is shared between very important applications like e-mails or CRM, and less important ones like your development environment. With Shinken, you will be able to describe your IT from the physical servers to the high level apps.

Find the root problem

When facing an incident, getting a full page of 500+ red lines like common monitoring apps usually do is useless if only one of them is interesting: 499 are consequences, 1 is the root problem! Shinken can filter out the consequences for you, allowing you to diagnose faster. This will also solve your "too much" alerts problems.

Sort by business impact

Have you ever seen an administrator rush for the server room to fix a development server? I guess not. But for production ones, they do ;-). You need to figure out in seconds which problems are impacting your production applications, and which ones can wait after your coffee break.

Production can’t wait (but production only).

Have you ever seen an administrator rush for the server room to fix a development server ? I guess not. But for production ones, they do ;-). Your team should focus on production, and manage the other environment later. Give them the tools taking this into account.

Filtering testing/production alerts

While problems on production need to trigger a SMS, the testing environment probably doesn't. With Shinken you can easily filter root problem alarms to only receive notifications that really NEED action.

Day != Night

You may not need to receive SMS during the day, or and e-mails during the night. With Shinken you can easily manage notification canals without having to add another layer of complexity to your configuration.

Sometime it's critical for business, sometime it's not

The payroll application is a good example. Do you need to wake the administrator at 3AM because the server hosting it is down? Probably not... Unless of course we are nearing the payroll! With Shinken you are able to define business impact modulations based on the period, like the 3 days at the end of the month :).

Automatic Vmware Topology

Amazon EC2 Monitoring

Because an ESXi host can fail

What if an ESXi host crashes?

Do you rather receive 50+ simultaneous alerts for your downed VMs, or just one critical alert about the fact that your hypervisor is down? I'll bet you'll choose the latter!
The VMWare module will solve this problem for you : it will automatically check through vSphere on which ESXi are the VM now, and create notification dependencies from it.

What about VMotion and my host-dependencies?

Don't worry about VMotion, if your VM has moved to another ESXi, the VMWare module will detect it, and automatically update the link without restarting Shinken.

VMWARE IS GREAT, BUT I USE XEN/KVM/OPENSTACK/...

No problem with this. In fact Xen and KVM are already managed, and new virtualization framework is easy to add. If it has an API, it can be integrated!

EC2 is great. Monitor the apps on these hosts is great too.

Why monitor EC2 ?

With the EC2 module you won't monitor EC2 itself, but you will be able to automatically monitor the applications (like Mysql or Apache) running on them.

No double configuration

This module will automatically load all your EC2 instances, and will use the EC2 tags to configure your hosts in Shinken. When your EC2 tags are filled, your configuration is done.

Not only EC2

As of today, only the EC2 module is available. But it won't be difficult to extend it to other cloud providers, like Rackspace, OVH or Gandi. Feel free to contribute on The Monitoring Station, we can help you for this.