Our journey of Icinga integrations continues – we’re announcing the general availability of the Icinga Module for Jira v1.0 today! Jira is a ticketing system created by Atlassian and it’s one of the most popular ones of its kind. Jira is used by a very diverse audience: Developers, Managers, SREs, Systems Engineers and everyone else who needs to keep track of issues and projects. The Icinga Module for Jira extends Icinga with multiple functionalities to create seamless workflows between Icinga and Jira.
Create Issues on Problems
When Icinga detects a problem in your infrastructure, be it a host that is down or a service that is critical, this module helps you by creating an issue for each problem automatically in Jira. This system comes in handy when multiple people work on problems or need to keep track of those.
The Icinga Module for Jira also keeps track of reoccurring problems, so you won’t create multiple issues for the same problem. Additionally, acknowledgements will be set automatically. If you don’t want to create issues automatically, you may create them manually through the Icinga Web interface.
To keep track of all existing issues created by this module, there’s a dedicated history overview. Further, a direct link to Jira is embedded at the host and service detail view leading you directly to related Jira issues.
Integrating with Jira Workflows
For those of you who are using customised workflows in Jira, this module brings a functionally to map those with the module. The highly configurable templates allow you to set custom values based on your existing workflow. You may set your team automatically or tag different problems with different tags.
Integrating with Director
The Icinga Module for Jira works based on a notification command that is included in ‘icingacli’ once the module is installed.
Users of the Director can simply just synchronise the related configuration and deploy it through Director to Icinga. This provides a hassle-free installation path where you don’t have to take care about creating custom Icinga configurations.
The documentation with a introduction is available on our website: Get started with Icinga Module for JIRA
Yes, we had some fantastic Icinga Camps through this year – but there’s still room for more! Starting in Berlin, followed by Atlanta, Stockholm and Milan we met great people from our community and had a good time together. Our final destination for this year is Zurich, and the date is just around the corner.
One outstanding fact about Icinga Camp Zurich is the location – the Camp will take place in the Letzigrund Stadium of Zurich. Even though the venue is definitely worth a visit, this alone should not convince you to join us. Our speakers for this Icinga Camp come from different industries, roles and working areas creating a very diverse program. And of course our developers will be present as well, showing our latest developments and achievements.
||State of Icinga
||Efficient IT operations using monitoring systems and standardized tools
||Bank Vontobel AG
||Monitoring the Cloud at Vontobel
||Signalilo: Visualizing Prometheus alerts in Icinga2
||Max Planck Computing and Data Facility
||Moving from Icinga 1 to Icinga 2 + Director
||Tornado Complex Event Processing Framework for Icinga
||Latest developments of Director, Icinga for vSphere and many more
||Our daily business with Icinga
Some say you have to move all of your server infrastructure into the cloud. Others counter that you should keep your data safe and secure in your own datacenter. And then there are many people in between who use cloud services as an addition to their self-hosted servers. In fact, there’s no right or wrong, because as always in IT: It depends. We at Icinga always try to find a way to make everyone happy with their monitoring – be it in the cloud or on premise. Today we’re pleased to announce version 1.0 of our Icinga Module for AWS!
Automation and integrations are important parts of every Icinga setup since ever then. The Icinga Module for AWS follows this path by embedding into your existing monitoring setup. The module is an addition for the well-known Icinga Director, whose main purpose is to manage Icinga configuration at a glance – the Icinga Module for AWS is yet another Director Import Source. Import sources are a crucial factor of the Director as they enable you to import data from multiple data providers. The collected data is transformed into Icinga 2 configuration. Learn more about import sources and automation in our guide Monitoring Automation with Icinga – The Director.
This module collects data about your EC2 Instances, RDS Instances, Load Balancers and Auto Scaling Groups. The Director uses the regularly collected information to create Icinga 2 configuration out of it. Since this can be automated, you can just continue on spawning and deleting new instances in AWS without having to take care about if they’re going to be monitored or not – without any human interaction.
Import EC2 Instances
The following example demonstrates how you can use this module to import details about your currently running EC2 Instances into Icinga. Before you get started, make sure you have your AWS Access Key by hand. This is required, so you can establish a connection to your account and pick up the information we need for monitoring. Make sure to add your Key details to the modules configuration at “Configuration > Modules > aws > AWS Keys”.
Installation and Configuration
Extract or clone this module to your Icinga Web 2 module path. The directory name must fit the module name, aws. This would usually lead to
Additionally, the module requires the AWS PHP SDK v3 which you have to install manually. The easiest way to do this is by downloading it from the release page and unpacking it into
Configuring the Import Source
The first step is to create a new Director Import Source:
- Import source name: A general identifier, choose something that you will recognise later
- Source type: Select
- AWS region: You may create an import source for each region you use
- AWS access method: Select your previously configured AWS Key from the dropdown
- Object type: We use
EC2 Instances for this demo purpose, you may create multiple import jobs for each object type you want to import
Save the details and open the newly created Import Source again. We now continue with adding a Modifier.
Import only running Instances
Director Modifiers are used to handle the incoming data and transform it or filter it by certain conditions. Since you usually want to monitor only running instances, we’re using a Modifier to filter for the state of the EC2 Instances.
- Property: We refer to the
status property, in order to filter by states
- Modifier: The
Black or White-list modifier allows you to whitelist only certain instances
- Filter: We filter by
running systems only
- Policy: Here we decide to keep only matching rows, therefore only running systems are whitelisted
Hit the save button to save your Modifier.
Trigger Import Run
You’re now ready to trigger the first import run. This will not create any Icinga configuration yet, but allow you to see a preview of the collected information in the “Preview” tab. There you can now see a variety of data that was synchronised from your AWS account. All of these information can be used to create Icinga hosts for example. Additionally you may use part of the data and add it as custom variables to your monitoring objects.
Your next step is to create a Sync Rule which will use the gathered AWS data to generate Icinga configuration. If you’re not familiar with Sync Rules, you may refer either to the Director Documentation to learn about it or read our guide Monitoring Automation with Icinga – The Director
The Icinga Camps we are co-organizing with our partners are truly fascinating. We manage to offer a platform for experienced monitoring experts and beginners at the same time. An Icinga Camp is an event where you can listen to amazing stories from Icinga users and developers. But it’s also a place where you discuss your own challenges learn from the experience of others. You will get the news about the latest technologies in the Icinga universe and discover many possibilities how Icinga helps you to manage your daily monitoring requirements.
We have opened the Call for Presentations and Registration for the upcoming Icinga Camps in Stockholm, Milan and Zürich!
We would love to hear about your successes, learnings and pains in production. Share your experience with others and tell us your story. These are just some examples on what we are looking for:
- Best Practices – There isn’t just one way to do it
- From your Experience – Every monitoring environment has different challenges, tell us about yours
- Monitoring Culture – Building a healthy monitoring environment
- Integrations – How do you connect and use Icinga with your other tools
Submit your Proposal
I’m not going to list all benefits of automating your monitoring system. If you’re here and reading this, you are most likely very aware that maintaining a large infrastructure is a big challenge.
Automating the monitoring process for a huge amount of servers, virtual machines, applications, services, private and public clouds was a main driver for us when we decided to build Icinga 2. In fact, monitoring large environments is not a new demand for us at all. We experienced this challenge in tandem with many corporations for many years. Finally, it lead us to build features like our rule based configuration, Icinga’s REST API and various modules, cookbooks, roles and playbooks for different configuration management tools.
All these methods make it easier to automate monitoring in their own particular way. We have built multiple ways to automate monitoring because there is not only one way to do it right. As usual in the IT field “it depends”. Depending on your infrastructure either one way or another may be the right way for you to automate your monitoring.
Beyond the Static
With all this in mind we have created the Icinga Director 3 years ago. Director is a module for Icinga that enables users to create Icinga configuration within a web interface. The Director utilizes Icinga’s API to create, modify and delete monitoring objects. Besides the plain configuration functionality, the Director has a strong focus on automating these tasks. It provides a different approach that goes far beyond a well-known static configuration management. With thoughtful features the Director empowers operators to manage massive amounts of monitoring objects. In this article I put my attention on the automation functionality of the Director, even though creating single hosts and services manually is also possible of course.
Step 1: Import
In almost every company a database exists, or something similar, that holds information about the currently running servers and applications. Some use dedicated software to manage this information. Others use tools they have built themselves or rely on their config management tools.
While most people refer to this database as a CMDB there are also other common terms. In theory only one database exists within an organization, allowing everyone involved to manage the information in a single place. In practice, most organizations spread the data across a number of different tools. While there are some professional approaches, there are also some not-so-professional ways of maintaining this data. Have you ever seen someone keep their IP addresses and locations of servers in an Excel file? We’ve seen it all.
Creating the source
The Director contains a feature called Import Source. It allows you to import all kinds of data from many different data graves. The data does not have to be in the Icinga configuration format, the Director will take care of that later. For a start, you only need some kind of data.
In my very simple example, I’m using a MySQL database, which is a common storage for this type of information. My database
cmdb contains only one table
hosts that holds everything I know about my servers. For demo purposes, this is perfect.
Add Import Source
Import Source Preview
Creating the import source requires access to the database server. The credentials are stored in an Icinga Web 2 resource, therefore they are re-usable. After triggering a Check for changes you can preview the data set in the Preview tab. If everything that you need is included, you can trigger the import run which actually imports the data.
Starting from here your data is generally available and you can create Icinga configuration out of it. The properties may also be modified during the import, but I leave them as they are for now. Learn more about available modifiers
Using SQL, LDAP or else
For my import source I used the source type SQL which is built-in and available by default. You can use other source types as well, for example LDAP. That allows you to import not only objects that have to be monitored, but also users from your LDAP or Active Directory and use the contact information for alerts.
Of course, you can also use other import sources, such as plain text files, PuppetDB, vSphere or AWS. New import sources are added to the Director as Modules, which you could also write yourself. Our lovely community is continuously extending the Director with new import sources as well, for example with import sources for Microsoft’s Azure or Proxmox VE.
Step 2: Synchronise
After a successful import I am able to continue with basic config synchronisation. Syncing configuration means, that you use the imported data to generate Icinga configuration out of it. Generally speaking, you map your data fields into Icinga objects and properties.
Some of the data I imported is easy to map, such as hostname and IP address. Icinga has pre-defined config parameters for those. Others, like the location and environment of the servers are mapped to custom variables. Custom variables are something like tags, but on steroids. They accept plain strings as values but also booleans, arrays and even dictionaries (hashes). I know, this sounds crazy. Custom variables are usually used to store meta information about your objects. This information you might later want to use to create rules which in turn define what should be monitored or who should receive alerts.
But first things first.
Creating a new Sync requires some input and some decisions. You define what kind of monitoring objects you’re going to create out of your imported data. This can be Hosts, Endpoints, Services, User, Groups and so on. In my example I simply choose to create some host objects.
Then you decide what should happen with existing monitoring configuration. Shall it be replaced with the new one, merged or ignored? Once the Sync is created you can finally start to tell the Director how to map your data to Icinga configuration attributes. This is done within the Properties type by creating new sync property. For every column in my table I create a sync property. Have a look at the images for details.
Add Sync Rule
Add Sync Property
Sync Properties Overview
Checking for changes will only do a dry run to tell you if there are any changes available. Triggering the Sync actually synchronizes the new configuration with the existing one and automatically creates new entries in Director’s activity log. At this point, everything is ready to be deployed to Icinga.
Step 3: Deploy
The Director’s activity log shows precisely what changes are waiting to be deployed to Icinga. Clicking on each element displays the exact diff between old and new configuration. This diff format may be familiar to you from Git for example. Another point that may be familiar is the whole history of deployments which you can see within the activity log.
Travelling in time
It contains every configuration change you ever made with the Director. It lets you travel back in time and deploy old configs if necessary. The Director’s history of deployments basically works like your Git history: You can do a diff between certain deployments to track the changes and see which user deployed which configuration at what time.
The simplest way of deploying your new configuration is by just clicking Deploy pending changes. Your config will be pushed to Icinga and validated. If everything is fine it will be in production within seconds. If there’s anything wrong, you will receive a log with the details and your running configuration remains untouched.
Fully Activity Log
Config Version Diff
As I mentioned in the beginning, automation is a key aspect of the Director. The steps described so far (Import, Synchronise and Deploy) can all be automated once they are fully configured. The automation is done by creating Jobs, with each Job running one certain task in a specified period.
The frequency of a Job is freely configurable. It may run every minute or only once a day. You create a Job for each task or only for certain tasks.
Hint: You can use a simple cronjob to run the Jobs. To fully leverage the Director’s Job functionality in the web interface, you have to start a separate daemon as described in the documentation.
The workflow described above was only a sneak peek into the capabilities of the Director. This scenario however demonstrates very well the basic functionality and what you can do with it. There are many more features left out in this article like modifying imported data, merging data from multiple data sources, filtering or creating and using custom data sets.
Managing and maintaining large server infrastructures is a very complex thing to do and there’s a good reason why whole teams are required to do so. I would lie if I told you that monitoring of such large setups is easy. But with the right toolset it is definitely doable! Check out the full Director Documentation to get started with your monitoring automation project.
We will discuss the challenges of monitoring large infrastructure at the upcoming Icinga Camps as well. Join us for a full day filled with talks and discussions about and around Icinga. Meet new people and get to know others from the same field.