Welcome to docs.opsview.com

Architecture

Opsview is 3 tiered system.

  • Web front end
  • Application server
  • Datastores

Architecture

Web front end

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

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.

Data Sources

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

Opsview Configuration Database

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 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

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.

Reports

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

Navigation
Print/export
Toolbox