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.
During the past years we made plenty of contributions to improve the current state of the Windows monitoring. We tried to improve the actual installation with the Icinga 2 Powershell Module, allowing users to easier automate installation and configuration of Icinga 2. On a long term we however wanted to improve the monitoring of Windows infrastructures entirely, by not only providing new plugins but also to increase the contribution by the community.
Last year a first prototype was developed as a proof of concept on how Windows information could be fetched and is now continued as Icinga PowerShell Framework.
One Framework for everything
The Framework will provide all core functionality for developing plugins and to ensure standardised output for Icinga. This will include properly formatted performance metric output for your graphs within Graphite and/or Grafana. As a Framework alone of course does not provide monitoring capabilities, we will ship our very own re-designed PowerShell Plugins.
New Windows Plugins
With the new PowerShell Framework a bunch of the Plugins will be shipped separately in an own repository, to ensure updates can be applied more frequently and without having a huge impact on the core components itself. The following Plugins are currently available:
More will follow periodicaly over the time. If you wish to contribute your own Plugins to the community, you can have a look on the first draft of the developer guide.
Collecting Metrics over time
Another feature is to run the PowerShell Framework within an own service, which then will execute selected Plugins by you within a given time and collect metrics. By doing so, you can define how they should be combined to get a better idea on how output will perform over time.
We have released all repositories as Release Candidates and would love to hear your feedback! Within the next weeks and month we will continue to extend these components and to improve the use experience wherever required.
The 2.11.2 release addresses a problem unveiled with the cluster config sync and the new config-change-reload detection. Users who run HA zones (two masters, two satellites) are affected by this in large scale environments when the sync takes quite some time. The fix is implemented on the config receiver side preventing reload loops. All affected agents, satellites and masters need to be updated.
2.11.0 unveiled a critical bug in the cluster config sync. Before you panic – upgrading the config master as documented before any other instance keeps you safe. The 2.11.1 release is for everyone upgrading their satellites/agents first. For those who cannot do a major upgrade on their masters, we also release 2.10.7 where we added an additional fix to prevent this behaviour.
The online documentation additionally covers troubleshooting topics for configuration problems with command endpoint agents and zone-in-zone synchronization.
We are happy to announce a new bugfix release for Icinga Web 2. Official packages are available on packages.icinga.com. You can find all issues related to this release on our Roadmap.
Less Smoky Database Servers
The release of v2.7.1 introduced a change which revealed an inefficient part of our database queries. We made some
general optimizations on our queries and changed the way we utilize them in some views. The result are faster
response times by less work for the database server.
Consuming more CPU resources since upgraded to 2.7.1 #3928
Anarchism Infested Dashboards
Recent history already showed signs of anarchism. (Pun intended) A similar mindset now infested default dashboards
which appeared in a different way than before v2.7.0. We taught their dashlets a lesson and order has been reestablished
Recently Recovered Services in dashboard “Current Incidents” seems out of order #3931
We improved the host and service distinction with v2.7.0. The downtimes list however got confused by this and didn’t
knew anymore how to combine multiple downtimes. If you now instruct the list to select multiple downtimes this works
again as we removed the confusing parts.
Over the last four years, the Icinga Director has grown from an optional configuration add-on to a mature Software product with lot‘s of features. Most Icinga installations are now driven by the Director, no matter whether they are small or huge, manually curated or fully automated.
But it will not stop here. Many cool ideas are eager to finally become reality. Director v1.7 is a huge step in that direction, as it lays the foundation for a completely new type of features. We are now able to delegate complex tasks to a dedicated background daemon that has been introduced with this version. New library modules have been published, allowing us to share cool bleeding edge funtionality among different modules in a more efficient way.
The UI comes with new features like cloning a Service to a different Host, Downtime-related features or autosuggestion for fields based on Data Lists. Please check our changelog for more details.
Some artificial limits have been increased. Host address length does no longer limit cloud people who want to fire their checks against super long hostnames instead of IPs. For large setups with tens of thousands of hosts in a single zone the maximum size for generated single configuration files has been increased.
Import and Sync
Ever wondered what WOULD happen when pressing “Trigger this Sync”? Sync now offers a preview, showing what to expect. This works fine even if thousands of objects might be subject to change. New Property Modifiers have been added, and a generic REST API Import Source has been implemented. Import Sources will now provide detailled errors hinting right to the problem in case of erraneous data.
Available since v1.6.0, configuration baskets got a lot of interest. They became a valuable tool when it goes to exchange Service Sets or Automation Pipelines, either with the Community, when asking an Icinga Partner for support or just between your very own testing/staging and production systems. In this release many related issues have been addressed, and more object types are now supported.
Extensions and Hooks
Icinga Partners and Community members are building products based on Icinga and the Icinga Director. To satisfy their needs a couple of new Hooks have been introduced. For example it’s now possible to run custom code at deployment time. Experienced developers are allowed to do black magic by extending many of our web forms.
Last but not least the German translation has been refreshed, and we have now a Japanese translation. Many thanks to Chisato Hashimoto!