Architecture

Opsview is 3 tiered system.

• Web front end
• Application server
• Datastores

This is a very thin layer provided by Apache. This just serves static files and proxies dynamic requests to the application server.

This is provided by a Catalyst instance running the Opsview::Web application. This runs on port 3000 and handles all the dynamic pages displayed.

Opsview uses three MySQL databases with Nagios® Core also providing some information via a CGI wrapping technique.

Opsview configuration database (Opsview) contains all Opsview configuration data.

Interaction with the Opsview database is via Class::DBI perl modules. These are prefixed Opsview::.

This database is highly normalised. It uses the InnoDB engine, which is required for row level locking and foreign key constraints.

Runtime database (Runtime) contains current status information for monitored devices, this is used by monitoring user interface.

Interaction with the Runtime is via Class::DBI perl modules. These are prefixed Runtime::.

There is a requirement that the Runtime database is on the same database server as Opsview (because of various join statements that cross databases).

This database uses a mixture of normalised and denormalised tables. It uses the InnoDB engine, which is required for row level locking.

Opsview Data Warehouse (ODW) contains historical status and performance data. This can be used for reporting and trend analysis. Data is in an OLAP, denormalised format. More information on the ODW page.

The ODW database can run on a different database server as Opsview and Runtime.

This database uses the InnoDB engine for consistency.

This database is deprecated as the Opsview Reporting Module is used instead.