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
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 email@example.com: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 firstname.lastname@example.org: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!