Shinken is a monitoring Solution. It's a Python Nagios® Core total
and large environment management.
Ready to run monitoring packsEndless scalability and RAID-like availabilityFocus on critical business impacts onlyFull virtualization integrationKeep your Nagios® configuration and plugins
Download FreeTry the Full version
Shinken Io
Extend Monitoring
The monitoring node doesn't give you what you need out of the box ? You can easily extend it with configuration packs and modules.
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 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
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!
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.
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!
1 . Install a Shinken poller in the DMZ
2 . Tag the DMZ hosts as such in your configuration file
3 . Enjoy : DMZ Shinken poller handles all the checks and collects all data, eliminating unnecessary interaction between LAN and DMZ.
Root problem analysis
Alert Filtering
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.
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.
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.
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.
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.
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.
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
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.
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.
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!
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.
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.
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.
Learn more about this
Home
Ready to start
Scalability
Business Focus
Virtualisation