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
Give your Icinga Web 2 a new look – with official ‘Color Blind Theme’ introduced in version 2.7.0! Not just for people with impaired colour vision – with a fresh and well rounded new palette, the new theme is a real looker!
It’s important for us that everyone has the chance to use our tools with maximum effectiveness.We took an existing module from our Icinga Partner Sol1 – icingaweb2-theme-colourblind by Andrew Foster – refined it a little and it is now part of the default Icinga Web 2 colour scheme bundle!
What’s with the change?
The colorblind theme by Sol1 was already very well made, but we saw some minor issues with the chosen colours in terms of:
- context with the icinga states
Well, let’s just have a look first:
Overview over the different themes and the effects colour deficiency has on the appearance
So in the top, there is the default Icinga colour scheme – with mocks of the three types of colour deficiency we focused on during the development for the module.
In the middle row you can see the module Sol1 provided
Last row is the new theme which is integrated into the Icinga Web 2 core now.
Icinga state context
Another minor detail to improve was the colour of the WARNING (handled) state, which didn’t really fit in with the rest:
The WARNING (handled) grey sticks out and is hard to connect to the unhandled state colour
So in order to both have the context in which the colours are used preserved and have some sort of hierarchy in severeness of the states some changes needed to be made.
This warranted for a change both in brightness and hue for the OK green as well, so it could be distinguished from the WARNING (handled) yellow:
Visual representation of changes in hue, saturation and brightness.
There have also been some changes to the font colour:
Handled states (Including OK for urgencies sake) are now displayed with black text.
This makes it a lot easier to distinguish between handled and unhandled states in the blink of an eye.
Badges with the different themes
In case you want to build your own theme, there is a helpful article on the topic from our Partner Würth Phoenix. If you have any issues, feedback or inspiration – please tell us about it here or open an issue on github.
And by the way, I will be speaking about this topic at the Icinga Camp Stockholm as well!
As a little introduction for everyone who has not heard about the cube yet:
The cube module is there to show statistics grouped by the custom variables that have been set for the hosts and services. They are then displayed in up to three dimensions for a quick overview to show the relations.
The services are going cubin’!
The most prominent change is the addition of services:
While it used to be only possible to have the hosts in a cube, the module has now been extended to provide full functionality with services as well.
You can easily switch between hosts and services, while we keep the filters of your cube in place!
No more SQL dump crashes! (or at least fewer)
PostgreSQL rollup syntax errors are now smoothed out and will work as intended – also including the documentation for the requirements.
Having custom variables names like SQL keywords also no longer break the cube!
- Fix SQL keywords breaking the queries #38
- Fix rollup syntax for PostgreSQL databases #29 + #24
Restrictions are in place
Adds a filter that considers protected custom variables.
The cube now polls the restrictions set in the monitoring module and only shows the hosts that the user has permission to view.
- Apply monitoring restrictions #33
- Respect protected custom vars #25
And just a pinch of UX
Removed the possibility to add more than three dimensions to the cube – we live in a three dimensional world after all.
When the name of a cube tile is too long to fit, it will no longer push everything else downwards but be shortened with an ellipsis instead!
- Limit to 3 dimensions #36
- Truncate long headers #35
Fixed pröblems with ümlauts
The URL encoding has been adapted so that both white spaces and umlauts are now supported!
Name your vars however you like!
- Fix Slices with whitespace or umlaut in data field #17
In our ongoing efforts to make it easier to automate monitoring environments we recently introduced a new module for Icinga Web 2.
Icinga Certificate Monitoring
This module is first and foremost a platform which lets you have an overview over all the certificates you are using in your environment to prove the identity of your devices. You can take a quick glance or a very detailed look at them. It will help you to know exactly how your certificates are distributed based on the signing certificate authority, the used algorithms and key strengths as well as which certificate expires next.
It helps with automation
You don’t need to register each device or certificate by hand. The module will scan the networks you’ll provide it with and harvest any certificates it encounters. Whether it does this regularly or on demand is fully up to you.
Networks are provided by setting up jobs. These jobs define several IP ranges in CIDR notation and ports. Schedules in CRON format may also be set for jobs so that this module’s daemon runs them regularly.
Integrates well with your environment
Cloud hosting and virtual machines are on the rise for a long time now and with SNI (Server Name Indication) a single host may easily present different certificates on the same endpoint. In order to facilitate this, the module can be told to scan an endpoint multiple times by setting up SNI maps.
Installed alongside the monitoring module, Icinga Certificate Monitoring even accesses its database backend to fetch SNI information.¹ This will help to match results found in the scan process to already known hostnames in your monitoring environment.
Don’t miss to roll out new certificates
Let’s be honest, everyone has sometimes missed to re-new or replace expired certificates. The module provides detailed views showing you exactly which certificates require your attention.
Certificate Chain Health
Take advantage of your favorite monitoring tool
Though, if you’re not proactively looking at the user interface the check command shipped with this module may help with setting up notifications in Icinga.
Monitoring Service List
Bridging the gap with the Director
With all this talk about automation one has to wonder how to establish a link between this module’s knowledge about certificates and Icinga’s configuration. You’re right if you think of the Director’s import and synchronization functionality now.
The module lets you easily import known hosts or certificates with its own import sources. By setting this up you only have to define jobs for it and all the rest is handled automatically.
¹Available with Icinga Web v2.7 (Scheduled for release mid 2019)
We are pleased to announce the first open source release of our X.509 module for Icinga.
The X.509 module for Icinga keeps track of certificates as they are deployed in a network environment.
It does this by scanning networks for TLS services and collects whatever certificates it finds along the way.
The certificates are verified using its own trust store. (more…)
After weeks of development with a lot of brainpower being invested we have finally finished the first stable release of our Graphite integration into Icinga Web 2. The new features include a searchable graphs dashboard, multi-client capability and much more – read on.
Thanks to all contributors – Alexander, Blerim, Eric, Florian, Johannes, Markus, Michael and Thomas, you have done an awesome job!
Also many thanks to Deutsche Telekom for sponsoring the development! (more…)