Hub Reporting

The Hub prepares and provides content for multiple peripheral Uyuni Servers. The goal of the reporting feature is to get data from these Servers back and have combined reporting data available on the Hub. The data is made available for external Reporting Tools.

1. Architecture

The main database is a PostgreSQL database in the Uyuni Hub system. It stores all the information collected from all the servers, and aggregates them. Every peripheral Server has its own reporting database where the information is collected for that system. In summary:

  • the DB in Uyuni Hub stores, collects and aggregates data coming from all the DBs of the peripheral Servers,

  • the DB in Uyuni Hub stores also its own data from the systems directly connected and managed by the Hub,

  • the DB in peripheral Uyuni Server stores its own data,

  • the reporting tool can be connected either to the Hub or to any Uyuni Server.

2. Setup

The reporting database and schema are set up by default using the local PostgreSQL server. The reporting database is a separate database accessible via the network.

As a requirement we expect all server certificates are signed by the same Root Certificate Authority (CA). The whole Uyuni Hub environment should be using only one Root CA.

For more information about certificates, see specialized-guides:large-deployments/hub-reqs.adoc#lsd-hub-reqs-certs.

2.1. Create a DB user for the reporting

Before connecting an external Reporting Tools to the Database, a user with read-only permission should be created. For doing that, it is possible to use uyuni-setup-reportdb-user.

usage: uyuni-setup-reportdb-user [options]

options:
  --help
            show this help message and exit
  --non-interactive
            Switches to non-interactive mode
  --dbuser=DBUSER
            Report DB User
  --dbpassword=DBPASSWORD
            Report DB Password
  --add
            Add the new user
  --delete
            Delete the user
  --modify
            Set a new password

3. Database Schema

The schema exports the most important tables from the main Uyuni Database as a de-normalized variant containing only data which are relevant for a report.

Ready-to-use reports are provided as views, aggregating data over multiple tables.

Every table gets an extra id column (mgm_id) specifying the Uyuni server which provided the data. On a single Uyuni Server this column has the standard value 1 which represent localhost. On the Uyuni Hub it is replaced with the real server id the managed server has in the hub database.

Another common additional field is synced_date, which represents the time when the data were exported from the main Uyuni Server database.

Navigate to Help  Report Database Schema to find the schema documentation.

4. Data Generation and Update

Uyuni uses taskomatic jobs to generate the data for the reporting database and to get the data from the peripheral servers to the hub.

To generate and update the data on a peripheral server, the responsible schedule is called update-reporting-default. It is executed by default daily at midnight.

On the Uyuni Hub there is a second schedule which is important. To fetch the reporting data from all registered peripheral servers, the task with the name update-reporting-hub-default is executed daily at 1:30 AM.

All times are in the local timezone of the server. If the peripheral servers are in different timezones, it is recommended to align all the schedules. Make sure that all reporting data are gathered at a specific point in time, and update-reporting-hub-default is running when all peripheral servers have actually finished their local jobs.

4.1. Tuning Reporting Jobs

4.2. report_db_batch_size

Description

The maximum number of rows fetched and written from one database to the other in one shot.

Tune when

Out of memory errors or on processing speed problems.

Value default

2000

Value recommendation

500 - 5000

Location

/etc/rhn/rhn.conf

Example

report_db_batch_size = 4000

After changing

Check memory usage. Monitor memory usage closely before and after the change.

4.3. report_db_hub_workers

Description

The maximum number of workers requesting data from peripheral servers on a hub at the same point in time.

Tune when

The number of peripheral servers increases significantly (more than 100), or a faster synchronization is required.

Value default

2

Value recommendation

2 - 10

Location

/etc/rhn/rhn.conf

Example

report_db_hub_workers = 5

After changing

Check memory usage. Monitor memory and cpu usage of the hub closely before and after the change. Also monitor the load, cpu and memory usage of the reporting database of the hub.

Notes

All the data collected from the peripheral server must be written into the hub reporting database. Tuning that database could increase the performance as well.