After our initial release of Icinga Reporting for early adopters we continued our development and are happy to release v0.9.1 today. The release includes bug fixes and some minor enhancements for the usability. I want to take this opportunity to write a post aimed at the people who are new to the whole reporting shabang – like me 🙂
This week I set out to figuring out for myself why one would need to use reporting and how to get there – and to share my new knowledge with you!
What is reporting?
When I’m talking about reporting in this context I mean Business Reporting. I’ll give you a brief overview by citing good old wikipedia:
Business reporting or enterprise reporting refers to both “the public reporting of operating and financial data by a business enterprise,” and “the regular provision of information to decision-makers within an organization to support them in their work.”
– Wikipedia ‘Business Reporting’ (12.06.2019)
In short: Reporting means collecting data, from a certain period of time.
What does Icinga Reporting do?
In simple terms you could say, that the reporting module takes the data from the Icinga Database (IDO) or other modules and displays it. So you gain a nice overview directly in Icinga Web 2 and if you schedule the reports you can also get them per mail or export it to PDF, JSON or CSV format.
You can review the uptime of your hosts and services in the form of a recap of your chosen time period. This gives you the opportunity to improve the accessibility of your systems and environments in the long run. If you want a more in depth description I can point you to this article about the new reporting release.
The process of the installation is already described in the docs here, but for the sake of completeness I’ll do a quick walk through with you here as well.
I documented my way from my installation to my first report for you, installing both the reporting and the idoreporting modules:
Step 1: Cloning the reporting repository
You’ll want to navigate into the icingaweb2/modules repository and clone this repository under the name ‘reporting‘.
git clone firstname.lastname@example.org:Icinga/icingaweb2-module-reporting.git reporting
Cloning reporting in the modules directory
Step 2: Database creation
You will need to create a MySQL/MariaDB database – in this example it will be called ‘reporting‘ for convenience.
Create the db with:
CREATE DATABASE reporting;
GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON reporting.* TO reporting@localhost IDENTIFIED BY 'secret';
Then import the schema provided under etc/schema:
mysql -p -u root reporting < schema/mysql.sql
Database creation in MySql
Step 3: Activate the module in Icinga Web 2
Log in with a privileged user in Icinga Web 2 and enable the module in Configuration/Modules. Alternatively you can use the icingacli and run
icingacli module enable reporting
Activating the module under Configuration/Modules
Step 4: Adding the resource
Once you’ve set up the database, create a new Icinga Web 2 resource for it using the Configuration/Application/Resources menu. Make sure that you set the character set to utf8mb4.
Adding the resource under Configuration/Application/Resources
Step 5: Cloning the IDO reports repository
Like in step one, just that this time we will clone this repository under the name ‘idoreports’.
git clone email@example.com:Icinga/icingaweb2-module-idoreports.git idoreports
Step 6: Import schemas
This step is an analogy to step 2: Import the following schemas also found under etc/schema to your Icinga 2 database (IDO):
mysql -p -u icinga2 icinga2 < schema/slaperiods.sql
mysql -p -u icinga2 icinga2 < schema/get_sla_ok_percent.sql
Step 7: Activate IDO reports
Log in with a privileged user in Icinga Web 2 and enable the module in Configuration/Modules/idoreports. Alternatively you can use the icingacli and run
icingacli module enable idoreports
Configuring a new Report
So you should now be at the point where you can start creating your first reports. Just navigate to the Reporting menu item and you should see a button reading ‘Add report‘.
Creating a new report
You can define exactly what you want to see with the Filter, that you can use just like anywhere else in Icinga Web 2 to see only what is relevant to you.
Break it down by days, weeks or months to see what happened when.
Add your own threshold to set what value must be undershot before the tile will be coloured in an alarming red, so it sticks out for you to immediately see problematic entities.
In case you want to have a report sent out to you on a regular basis, you can use the scheduler daemon for that:
icingacli reporting schedule run
This command schedules the execution of all applicable reports. You may configure this command as
systemd service. Just copy the example service definition from
/etc/systemd/system/icinga-reporting.service and enable it afterwards:
systemctl enable icinga-reporting.service
You have everything in your hands now to get started with Icinga Reporting. For any questions please feel free to get in touch with us and our lovely community on community.icinga.com. We would love to hear some stories how you use reporting in your organization and how we can help you with your daily work!
We’re happy to announce that we released an early version of Icinga Reporting today! With this release we create the foundation for an overall reporting functionality for Icinga by introducing a new way to work with collected data. At the same time we are also publishing the first use case of Icinga Reporting which enables you to calculate, display and export SLA reports for your hosts and services.
Icinga Reporting is the framework and foundation we created to handle data collected by Icinga 2 and other data providers. By definition Icinga Reporting does not collect or calculate any data. The framework processes usable data from data providers such as Icinga’s IDO or Icinga Web 2 modules and makes them available in different formats. The first version can display the data directly within the Icinga web interface or export it to PDF, JSON or CSV format. With scheduled reports you can receive the prepared data periodically via email.
Create Host Report
Create Scheduled Report
The IDO is the database where Icinga 2 stores all the status data it collects. It is also the first data provider for Icinga Reporting. We calculate the availability of your hosts and services over a certain amount of time and return a percentage value. This allows you to evaluate and compare the accessibility of you applications and network devices. You can use the data to check if you’re meeting your SLA (Service-Level-Agreement) and share it with your team and managers.
Open Source Projects
Icinga Reporting consists of multiple projects. We’re continuously working on updating and extending our existing Modules to provide data for Icinga Reporting. This release is at a very early stage and your feedback is very welcome and appreciated.
Join our community on community.icinga.com and have a chat with us about your reporting use cases and challenges! We will discuss Icinga Reporting on our upcoming Icinga Camps as well. The CfP for Stockholm, Milan and Zürich is still open for those who are interested in speaking at these events.
Took a little longer than expected, but thanks to all testers and reporters, we can provide another 1.8.2 release – this time for Icinga Reporting.
Please note, that this release is fully tested with the latest JasperServer 5.0.0. Furthermore, the least supported version will be JasperServer 4.5.0.
- fix queries for host/service availability/activity report #3312 #3400
- fix empty reports and reversed OK/NOK #3331
- fix compatibility with jasperreports <= 4.6 #3481
- fix host overview with empty contacts and contactgroups #3686
- test support for jasperserver 5.0.0 #3501
- define the least supported jasperserver version (4.5.0) #3502
Icinga Reporting 1.8.2 is available on Github. As usual, please report any bugs and/or feature requests to our development tracker, and look for help on the support channels.
At the moment we are working heavily on the upcoming Icinga 1.8 version of Icinga Reporting. Beside a new SLA function (thanks to Thomas Gelf) we’ve redesigned all templates and integrated some stunning new reports. We’ve also added a time-range selector (last week, last month and last year) to every time-range related report. Makes scheduling and automated report distribution much much easier.
Next up, we’ve got enhanced compatibility for PostgreSQL in the works. Please check out the current git-master to test the new templates. Feedback is always welcome.
Have a nice weekend!
If you have upgraded to Icinga Web 1.6 you may already be familiar with the new SLA extension in IDOUtils. The optional module is our response to the old niggle from the community that data written to database could be better used. So we have taken the opportunity to add a table to the database model and fiddle with IDO2DB. The end result is ‘enable_sla’ in your IDOUtils configuration files, which takes events and identifies the periods of scheduled downtime and acknowledgment for more accurate SLA reporting.
You could say, it improves SLA results too, by making it clearer, to what extent a critical event is actually critical or being resolved 😉
Coding and coordination aside, the concept behind the SLA extension is actually quite simple. We added a SLA history table to the database model, which organizes event start and end times, object id, state and state type as well as acknowledgement and scheduled downtime. Then in IDO2DB we added extra logic to write data from the core to the aforementioned table correctly.
At the moment you can view SLA data in the Icinga Web interface’s new tackle cronk, in the form of a pie chart. This is just the beginning though. We hope to integrate SLA history into Icinga Reporting with even more refined metrics.
So perhaps in the (not too far) future, you may be able to open up Icinga Reporting and call up a diagram that shows service availability for the year, though only from Monday – Friday, 9 am – 5 pm, discounting scheduled downtimes and acknowledgement periods. That maybe something worth waiting for – or even better, contributing to.