Icinga IDOUtils now uses a socket queue and transactions for large object dumps by default. With asynchronous data processing, the core is not only freed [...]]]> What could be better to celebrate Icinga’s 4th birthday with a new Icinga release? We’ve resolved the last release-critical issues and are happy to announce the release of Icinga 1.9!

Icinga IDOUtils now uses a socket queue and transactions for large object dumps by default. With asynchronous data processing, the core is not only freed of bottlenecks, but core reload times are also significantly reduced - from minutes to seconds in larger setups. This was a useful byproduct of our Icinga 2 prototyping.

In the Icinga Core, we’ve added various performance enhancements, including community contributions – thanks to Michael Lucka, Viranch Metha and Alexander Sulfrian! Kudos to Andreas Ericsson from Nagios and the Op5 team for their patches too.

Icinga Classic UI  has also been given a performance boost, now using hash compare when reading status and object files. We’ve improved its user-friendliness in large organisations too, adding config options to set expiry and send notifications for acknowledgements by default. As of v1.9, Icinga Classic UI can be installed as a standalone component, giving you the option to implement additional dashboard installs and us the ability to develop Icinga2 and its compat layer more efficiently.

Usability was the main focus in Icinga Web v1.9. It now ships with the new list-style cronk menu you voted for, and features better user-restrictions handling, whereby *groups or custom variables and combinations of them can be used. We’ve also made filtering much more flexible, enabling multiple combined attributes in drag-n-drop style (thanks Geberit AG).

In Icinga Reporting the availability report parser is now available in contrib/ and its files have been restructured a bit, alongside various bug fixes.

As usual, we’ve updated Icinga Docs with all these changes and spruced up the Icinga Web introduction with new screenshots. We’ve also revised the beginners guide to feature a comparison of the two user interfaces, for greater clarity.

Special Update Notes for Icinga Web: There’s a new apache configuration which requires your attention. Remove all existing .htaccess files – they are now obsolete  Last but not least, the order.deny rules were removed in favor of supporting Apache 2.4 (re-add those if your setup requires them).

You will find our top 7 picks for each subproject below. Further details can be found in the Core / Web / Reporting change logs.

Icinga 1.9 is available for download on Sourceforge. Packages and demo VMs should soon follow. As always, please do not hesitate to report bugs and/or feature requests, join the community support channels with questions and discussions and last but not least, spread the word for Icinga :-)

Core

• Increased core performance on config read with hash compare #3722
• Keep logfile open, reduce open/close performance decreases #3390
• Enhanced performance on illegal macro and host-service relation processing #3389 #3820
• Added skipping of status.dat/objects.cache write by setting to /dev/null #3819
• Fixed host_check last_check == next_check wrong in scheduling queue #2195
• Fixed triggered downtimes for child hosts are missing after restart #2688
  
• Fixed unable to exclude hostgroups when using nested host groups #2619

Classic UI

• Increased performance with hash compare on host/service show/filter #3722
• Added date/time selector to logfile navigation #3168
• Enabled Classic UI to be installed standalone (Icinga2 compat) #3869
• Added config options for acknowledgement notifications and expiry #3467 #3476
• Added ‘executed command’ to extinfo.cfg linking to command expander #3901
• Added process status to JSON response #3172
• Added lighttp config examples #2253

IDOUtils

• Use transactions for large object dumps #3527
• Added socket queue proxy (reduce core reload time significantly) #3533
• Oracle: change output columns to clob #3412
• Fixed memory leaks in idomod/ido2db #3749
• Added workaround fix for num_rows_affected broken in libdbi/mariadb, returned ids are 0 #3728

Web

• Revamped credential system, better grouping of permissions and performance #3715
• New and smaller Cronk menu design, showing the cronks as a list #3396
• New filtering window which allows detailed and combined filters #3268
• Many small interface improvements #3511 #3430 #3896
• New Apache configuration, making the .htaccess files obsolete #2759
• Search in admin user- / group dialog #3909
• PENDING are now shown for any new host or service in the database #2602 #3844

Reporting

• Added AvailReportParser into contrib/ (standalone) #3978
• Reorganized directory structure #3742
• Fixed image expression in PNP4Nagios template #3693
• Fixed state replacement in morning report #3752
• Fixed rounding error with small numbers #3942

Docs

• Added upgrade/troubleshooting notes about invisible icinga web cronks/modules after upgrade #3939
• Make install-webconf-auth installs htpasswd.user with icingaadmin credentials #3964
• Icinga Web 1.9: New menu style (smaller icons) #3944
• Icinga Web 1.9: New filtering methods #3947
• Added userpreferences.xml to icinga web configs #3991
• Added web gui comparison to beginners #3907
• Middle-clicking on TOC links now opens pages in new tab #3561

This past year has been marked by the launch of the Icinga 2 development branch, our Nagios core rewrite and replacement framework. Meanwhile we’re still making headway on the Icinga 1.x branch; we’ve continued to improve [...]]]> Icinga turns four today, surpassing the 300,000^th download while preparing for a celebration release and second technology preview soon to come.

This past year has been marked by the launch of the Icinga 2 development branch, our Nagios core rewrite and replacement framework. Meanwhile we’re still making headway on the Icinga 1.x branch; we’ve continued to improve performance the core, made packaging it easier and enabled notifications to be deactivated with expiry program-wide. Classic UI has received date picker, pagination and regex-based search functions, while Icinga Web a new credentials model, events in grid views and global master configuration cronk. Alongside a bunch of new reports, Icinga Reporting got a facelift, as did Icinga Docs.

All this development has been captured in both our git.icinga.org and on Ohloh. Though what speaks most is the continued growth in our user community. The list of organisations professing to use Icinga is nearing 100 and boasts ever-larger environments such as the > 40,000+ services at CERN’s Large Hadron Collider experiments.

While we look back, we too look ahead. As we head into our 5th year we have Icinga 1.9 and 1.10 releases planned on top of an Icinga 2 release candidate to come at the OSMC; ideally complimented with swift packaging and testing (helpers welcome).

We hope to forge ahead with your continued support on the mailing lists, forum, dev tracker, wiki and social channels. Cheers to all Icinga fans and friends – four years on and we’re still going strong!

Icinga Core, IDOUtils & Classic UI: As mentioned, we’ve added a socket queue (#3533) and transactions buffer for large object dumps (#3527) that are great to test in large environments. There are many [...]]]> Download Icinga 1.9 Beta now, for a chance to preview our newest features and check on some of the bugs you’ve reported:

Icinga Core, IDOUtils & Classic UI: As mentioned, we’ve added a socket queue (#3533) and transactions buffer for large object dumps (#3527) that are great to test in large environments. There are many bug fixes contributed by community members (#2619 #2688 #3736 thanks!) as well as smaller performance improvements on the core, as well as the Classic UI on parsing the current config and status data (#3722).

Furthermore we’ve added new acknowledgement expiry (#3476) and notification (#3467) default settings, fixed and improved JSON functions as well as made the Classic UI a standalone component (#3869) especially for Icinga 2 development tests.

Check the full Core change log for more details.

Icinga Web:  Now is the chance to test the new cronk menu you voted for (#3396 #3430), as well as the new sought-after drag-n-drop style filter (#3268). These are complimented by usability improvements in the interface (#3511), from scrolling and tabs to links and authorisations. In addition, we’ve fixed the upgrade path for custom cronks for v1.7 users (#3431 #3981). There’s a known bug with overlapping credentials (#4002). Check the full Web change log for more details.

These come with a couple of fixes in Icinga Reporting and plenty of new guide enhancements in Icinga Docs.

So take Icinga 1.9 Beta for a whirl and give us your feedback on our development tracker, or chat to our team on our IRC devel channel. See our bug reporting and testing guides for tips.

Thanks for helping us polish up Icinga 1.9 for the release in 7 days time.

From CLOB (#3965) and ‘DistictOutputModel’ (#3976) problems to disobedient custom variables and credentials (#3715), we’ve been testing and fixing over the past couple of days. But there is only so much time.

This update include some bug fixes for the session and preference backend, as well as fixes for pending states in the Cronk grids and an issue occurring with the latest PHP versions.

Icinga Web 1.8.3 is available for download on [...]]]> Today we’re happy to release Icinga Web 1.8.3 – a bugfix release for the 1.8 major version.

This update include some bug fixes for the session and preference backend, as well as fixes for pending states in the Cronk grids and an issue occurring with the latest PHP versions.

Icinga Web 1.8.3 is available for download on Sourceforge.net – packages should be available soon.

Please keep in touch using the support channels and report bugs and/or feature requests to our development tracker.

Notice

Please make sure to update your database schema. We’ve added a unique constraint, the update script should cleanup any duplicated user preference.

Changelog

• Session does not get cleared on logout #3721
• Fixed duplicated user preferences / appstate #3727 #3870
  (caused a Doctrine_Hydrator_Exception)
• Fix for PHP 5.3.22 / 5.4.xx #3751
• Fix Pending states shown as OK #3843
• Fix order handling with Cronk templates #3886
• Disabled all caching of permissions for a user #3880
  (caused problems when deleting a user from the system)

Checksums

MD5:
f3ccc0c683b2f8fdb1d14741c52857f9


SHA512:
0623500536014ade462c1c451c9abc4985cae78d75b9063919ee10ecfbac1709f73a5ab900756b165ca10483294df03acdaeb40cc7f3ecfa76a77675eeb03a28


signed with GPG:
pub 2048R/9B1F5883 2012-06-14
Key fingerprint = 549D 24B3 A7CD 941F AEE1 17F1 6295 5F6B 9B1F 5883
uid Markus Frosch <markus@lazyfrosch.de>
uid Markus Frosch (NETWAYS) <markus.frosch@netways.de>
sub 2048R/E1F43EB9 2012-06-14

gpg: assuming signed data in `icinga-web-1.8.3.tar.gz'
gpg: Signature made Mon Mar 25 16:01:11 2013 CET using RSA key ID 9B1F5883
gpg: using PGP trust model
gpg: Good signature from "Markus Frosch <markus@lazyfrosch.de>"
gpg: aka "Markus Frosch (NETWAYS) <markus.frosch@netways.de>"
gpg: binary signature, digest algorithm SHA1

Bischeck is an open source [...]]]> While surfing around for ideas to improve business monitoring in Icinga, we stumbled upon Bischeck and it’s creator Anders Haal. So we thought we’d share what we got to learn about teaming Icinga up with Bischeck for dynamic and adaptive thresholds – straight from the maker’s mouth:

What is Bischeck?

Bischeck is an open source project with the goal to provide dynamic and adaptive threshold logic for Nagios based monitoring solutions and forks such as Icinga.

Until now, Nagios based monitoring has only supported static thresholds. With static thresholds we are limited to define one maximum or one minimum value to express the threshold that is valid in every situation for the service that is monitored. To have one single value that is correct for each day of the week and for every hour of the day is not very likely. The risk is that we will get too many or too few alarms and there is even some service metrics that we will not be able to set a threshold due to their dynamic behavior. This is especially true when monitoring application and business related services that follow the dynamics of business load.

Dynamic thresholds suited to business load visualised in PNP4Nagios

What can you do with Bischeck?

With Bischeck you have a solution that allows for dynamic and adaptive thresholds to complement the traditional static threshold solution. So dynamic and adaptive thresholds give you the ability to:

• Define different threshold profiles depending on the time of the day and day of the week or month: We can set thresholds for any service where we expect some increase and/or decrease in the metric during the day.
• Define thresholds based on historical data: This enables us to express different kinds of threshold baselines. For example, we can specify that the expected threshold at 12:00 should not be 5% higher or lower than the calculated average of the measured metrics at the same time from the previous 5 days. Bischeck supports several mathematical functions to calculate thresholds at run-time.
• Set multiple thresholds rules for the same service: E.g. for a file system utilization service we can combine the classic 90% file system utilization with a threshold that checks how quickly the utilization changes by using historical data to calculate a utilization delta over some time period.
• Use data collected for one or multiple service as an input in the calculation of the threshold for a different service: This adaptiveness is excellent when you have some service metrics that drive the business process. For instance the number of visits to your web shop is likely to have some affect on the number of expected orders, CPU utilization, application threads, etc. This means we can set the thresholds in relation to data that matters and not just a single value.
• Create virtual services: A virtual service would be a metric that is not possible to measure at a single source, but can only be calculated from other metrics. This can typically be ratios, aggregations, etc that can not be measured as a single metric by itself.

 How does it work?

Bischeck can collect metrics in several ways, e.g. execute SQL queries, query Icinga/Nagios data over Livestatus, execute normal Icinga/Nagios check commands but bypassing state and just retrieve the performance data, etc. Both collection and threshold classes is simple to extend and customize.

Bischeck integrates with Icinga and Nagios by sending passive checks. Passive checks are supported over NSCA, NRDP and Livestatus. Bischeck data can also be sent to Graphite and OpenTSDB for graphing visualization.

Bischeck Architecture

Bischeck is written in Java and runs as a standalone daemon. It is “supported” on all major Linux distributions. It has also been tested on Windows, but installations scripts are currently not supplied for Windows. For more on how Bischeck works and its architecture see our documentation.

Where have you seen Bischeck in production environments?

DHL Freight in Sweden was our first “user”. It has been in production at DHL for over 2 years. They use monitored data like shipments orders to calculate the  threshold in next step of the process e.g. monitoring how many of these shipments orders are geographically coded for delivery and truck loading.

DHL has been a great sponsor to the project and you can read more about what they use it in our testimony page. We now start to see some more companies testing it and hopefully we can disclose some more interesting production cases in the near future.

Any future development plans?

Absolutely. We will soon release 0.4.3 with just some minor fixes and improvements. At the same time we are working on the next major release that we think will be our 1.0.0. What we currently are targeting as the major feature is threshold baselining. With threshold baselining you will use the historical data that Bischeck collects and apply mathematical filters to the data to get a comparative threshold baseline. This will minimize configuration and hopefully a threshold that is very adaptive to the production environment. The benefit is of course less configuration, but more important, a better threshold management that only triggers adequate alarms. This feature will demand some changes to our historical cache storage and currently we are leaning against Redis which seems to work well for the our time series data model. Feedback and ideas are of course appreciated.

What’s the coolest thing about Bischeck for you?

I think the coolest thing is that it solves the problem that it was meant to solve. Hopefully the rest of the world will find dynamic and adaptive thresholds as cool and useful as we do.

Requisites for installation: See Bischeck quick start guide and documentation.

Version compatibility: All Bischeck versions (0.4.2 at the time of writing) with all Icinga versions

More information: www.bischeck.org

Current default Icinga Web menu: Large Cronk icons

Proposed new default Icinga Web menu: List with small icons

As we’re [...]]]> On our roadmap for our next release is a redesigned Cronk menu for Icinga Web 1.9. We’re thinking of replacing the current large icons with smaller icons in a list view, by default:

Current default Icinga Web menu: Large Cronk icons

Proposed new default Icinga Web menu: List with small icons

As we’re all about flexibility and customization, we will ensure you can switch between them and add some example configuration lines to guide you in our Icinga Docs.

But before we get carried away, we thought we’d ask you our user community first – what would you prefer as a default view?

Our poll will close on 20th April 2013 to give us some time to implement the majority-preferred menu. So till then, add your vote and help shape the next Icinga Web 1.9 . As always, suggestions are welcome in the comments below.

Actually, we have a lot of fun – discussions on Icinga, live hack sessions on dev tracker issues or just having some beer(s). Feedback on Icinga [...]]]> Thanks to Amanda’s awesome organization, Team Icinga arrived safely in Chemnitz at CLT 2013 – accompanied by the exclusive Icinga beer, sponsored by Netways – thanks a bunch! :-)

Actually, we have a lot of fun – discussions on Icinga, live hack sessions on dev tracker issues or just having some beer(s). Feedback on Icinga is great, and we might actually adapt some ideas for the upcoming 1.9 release.

On Saturday 15:00, Web and Core lead developers Marius and Michael teamed up and presented “Icinga Open Source Monitoring – Today and Tomorrow”. While the overview and demo of Icinga 1.8 was rather short in comparison, the presentation focused on our core rewrite Icinga 2.  After showing the latest improvements on the to-be-released Milestone 2 it was demo time again, running latest GIT snapshot with some to-be-notified checks :-)

You’ll find the slides directly on slideshare, or as download here.

Since CLT also offers a rich program of presentations and workshops, we also walked by and saved some impressions – namely, that FSFE’s clothes for babies would just fit for Icinga as well ;-) Find some more pictures from Team Icinga at CLT 2013 below.

For the first time, our lead Core and Web developers Michael Friedrich and Marius Hein will team up to present the latest on Icinga and Icinga 2.

To support them from the stand, [...]]]> This weekend 16 – 17 March, Icinga will be hanging out at Chemnitz Linux Days 2013, manning a stand and making a speech.

For the first time, our lead Core and Web developers Michael Friedrich and Marius Hein will team up to present the latest on Icinga and Icinga 2.

To support them from the stand, this year there’ll be a further six of us to chat to, ask questions, share your ideas and maybe even have a beer with.

Otherwise, we’re pretty sure the 2 days of presentations, workshops, key signings, LPI certifications and social events will keep you busy. 15 years and running, the event always manages to pack in a good deal of information on the latest open source happenings.

Tickets are just 8 EUR, so if you happen to be near Chemnitz this weekend, pop by and say hello!