This document is intended for the System administrator that has the operational responsibility for the op5 system. You are expected to have good knowledge and understanding of computers and Solaris or UNIX knowledge.This document will try to give you a installation instruction how to configure op5 Solaris Extension. For information about how to use and configure op5 Monitor after installation, please refer to “op5 User Manual” and “op5 Monoitor Administration Manual”.Note: To complete this installation guide you need to configure a database connection for op5 Monitor covered in “Oracle Extension Manual”.For Solaris a number of requirement packages need to be installed prior to installation of op5 Monitor. These requirements are provided as a tarball, named (csw-deps-<version>.tar.gz)This tarball installs basic requirements for op5 Monitor, for example apache and php. These are standard Solaris packages provided by blastwave.orgAdd command line option 'oracle' to the installer to avoid installing mysql-server. NOTE: The database must be manually setup and configured as described in the Oracle database setup manual.The op5 Monitor product package is named op5-monitor-<version>.tar.gz. This tarball contain all packages developed and built by op5.Follow step 1, 2, 3 and 4 above <FIXME> ->When upgrading it is important that the old install dirs are removed before the tarballs are unpacked. This since we otherwise might get multiple versions of packages to install and this will break the installation. When the installer detects that an upgrade is beeing performed configuration is saved prior to package upgrade and restored when upgrade is complete.Note: To complete this step you must have setup a database connection as explained in “Oracle Extension Manual”.The Solaris installation tarball include a 爽ninstall.sh script which uninstall op5 Monitor and all third party dependencies that where added during install. Execute:Estimating the disk usage on a op5 Monitor server is not an exact science. The exact disk usage depend on the amount of services, the output of the plugins, the number of state changes etc. The numbers presented below should only be considered estimates since there are a lot of factors influencing the actual storage needed.The data that is persistent can be divided into three categories; performance graphs, database (reporting data) and logfiles.Performance data will be stored in Round Robin Databases using RRDtool. That means that after some time the oldest data will be dropped at the 兎nd and it will be replaced by new values 殿t the beginning. The good thing about this approach is that the size of one particular rrd file is fixed, it does not grow over time. New data is stored with high precision and older data is stored with lower precision. When data is really outdated it is discarded.Estimates provided by the maintainers of pnp4Nagios (the graphing engine) suggest that roughly 400KB per datasource is needed.Example: 10 hosts, 50 services per host and 10 datasources per service each mean a total of ~2GB of storage. (500*10*400KB)Sizing formula: num hosts * num services/host * num datasources/service * 400KBThe data stored in database can be divided into two categories, status information and reporting data. Status information contain the current state (and associated data) for all services. Reporting data contain historical data used when creating availability and SLA reports. Please note that report data only contain state changes (both soft and hard states) so the amount of space needed depend on the how often a service changes state.Using the example above a default Oracle database, in standalone mode on Windows, result in 1-1.5GB of storage for storing current status information and oracle internals.The database storage is highly dependent on the stability of the monitored environment. In an unstable environment there is a lot of state changes which generate reporting data and hence the storage required increase.Normally a stable environment, consisting of 10 hosts with 50 services each, produce less then 100 state changes per day but when calculating storage requirements one should count on higher numbers.Sizing formula: 1.5GB + avg service output size * number of state changes.An extremely unstable environment, generating 1000 state changes per day would, in one year, require:1.5GB + 1KB * 1000 * 365 =~ 1.9GB of storage (the actual data file storage is larger and depend on the allocation scheme used)Estimating logfile usage is the biggest challenge. This since the storage needed depend on the number of monitor process restarts, the amount of state changes, whether external commands and passive checks are logged, the number of notifications send etc. The main logfile (nagios.log) contain information of state changes and other information needed to generate availability reports. Optionally one could also include passive checks and external commands in the log file.Calculating the storage needed for logfiles when passive checks and external commands are not logged would require (roughly):Since the number of process restarts are difficult to calculate and since there are also other events that are logged the example above, if monitor is restarted 10 times a day, would generate atleast:Also, each notification are also logged to file which mean that if several contacts get notified by the same service the amount of logfile space increase even further.Apart from nagios.log a number of other logfiles exist which consume relatively small amounts of data.Since logfile usage in particular are difficult to estimate the op5 recommended hardware specifications should be honored. The hardware specifications for a op5 Monitor server include >140 GB of hard drive which is enough for a system monitoring up to 10 000 services during the expected hardware lifetime (3-4 years). The following configuration options are covered by the setup tool.