How many servers can be managed by one system administrator? This question is pretty hard to answer since it depends decisively on the tasks that need to be operated. It is clear, however, that the amount of servers one engineer can manage has increased tremendously over the time, and is still growing. Public and private clouds, in combination with automation tools, enables us to automate many daily tasks. In a modern IT infrastructure almost everything can, and should, be automated. Starting from the creation of a new instance up to software deployment. In this whole scenario, automated monitoring is an essential component.
Icinga is an enterprise-ready open source monitoring tool. It helps you to find out what is working in your infrastructure and what is not. Icinga may be used in small scale environments as well as in large scale organizations. Highly available and distributed clusters can be built with the integrated mechanisms. Communication between servers and agents is always SSL encrypted. If something in your environment is not working as expected, Icinga notifies you through your favourite channels.
Many servers means many things to monitor. In a small setup this may be achieved with manual configuration. Larger environments clearly need automation. Icinga has a powerfully configured DSL that allows you to describe your hosts and express what exactly you want to monitor and how you want to get notified. Your configuration is managed on a central node and distributed automatically to all connected servers and agents. Additionally, there are modules, cookbooks, and roles available for the most common configuration management tools Puppet, Chef, and Ansible.
Because configuration automation is not always enough, Icinga can be extended with the Director module. This module adds the ability to change configurations through the web interface. More importantly, the Director has the ability to import data from various data sources and transform it to Icinga configuration. Data sources can be potentially anything, pre-implemented sources are Active Directory, MySQL, PuppetDB, vSphere, and many more. Combining data from your existing tools, such as a CMDB or user database, with fresh configuration, is the master class of monitoring automation.
Many servers, much monitoring, much data. This leads, without a doubt, to many notifications that need to be addressed accurately. On each notification, Icinga runs a dedicated notification handler. With this capability it’s possible to notify users through almost any channel and leaves room for many integrations. A very popular notification channel is iLert. Icinga can route all notifications, enriched with loads of data, directly to iLert.
Handling a big amount of notifications is not easy at all– this is where iLert kicks in. Where many servers have to be managed, usually the work is split to several teams. It’s not uncommon that these teams are spread all over the globe. Routing notifications becomes a key aspect of the monitoring challenge. iLert brings all the capabilities to manage teams, escalations, on-call duties, and many more.
The sheer amount of alerts is not an issue for iLert at all. However, if you have many alerts, you may want to define how notifications should be sent out. iLert’s Alerting Channels feature is the perfect component to do so. iLert provides multiple alerting channels, where you can acknowledge or escalate an incident on the same channel. Alerting channels include
Integrating iLert with Icinga requires Icinga 2.x and Python 2.7.3 (or higher). You will have to create an additional API key and map it to one contact on your Icinga server to send your alerts directly to iLert. For detailed information read the integration documentation and ask questions in the Icinga Community for help.
Note: This is a guest post provided by the fine folks at Icinga.
Keep it quiet during maintenance. With maintenance windows, you can temporarily disable one or multiple alert sources for a set period of time. An alert source with an ongoing maintenance will not create any incidents.
With Priority-Based Alerting, you can set different notification rules for high and low priority incidents. That way, you can use more obtrusive alerting methods for incidents that require immediate attention and less obtrusive methods for the ones that don’t. Low priority incident also do not escalate automatically. The incident priority is set on the alert source level. Moreover, the incident priority can be dynamically set based on Support Hours. This gives you the flexibility to be notified differently based on the time of day. You could, for example, configure your alert source to receive voice alerts during the night and push notifications only during work hours.