The Opsview Downtime Manager purpose is:
- to receive downtime requests from the orchestrator API:
- add - to plan a new downtime;
- cancel - to cancel a current or future downtime;
- to maintain the downtime status of services, host, and downtime history.
This component requires access to the opsview MySQL database, to the Opsview Message Queue and the Opsview DataStore.
You will also need to ensure the
mysql client binary is installed.
Refer to Advanced Automated Installation.
We ship the
opsview-downtimemanager with its default configuration, which can be modified or overridden by the user.
- default setting - /opt/opview/downtimemanager/etc/downtimemanager.defaults.yaml
- custom setting example - /opt/opsview/downtimemanager/etc/downtimemanager.yaml.example
- user settings - /opt/opview/downtimemanager/etc/downtimemanager.yaml
Default settings are restored on upgrade/installation, user settings are left as defined by the user.
The setting files follow the YAML file format; setting are stored in a <setting_name>: format.
The custom setting example contains an example on how to override default value.
- runtime_database: Configuration for the Runtime database.
- downtime_queue: The message-queue configuration to receive downtime messages.
- downtime_store: The data-store configuration.
- registry: Connection configuration for the Registry.
- logging: Component logging configuration.
Watchdog service files are now managed by the package, doing a remove would leave the watchdog service file behind with a .save extension. Purging the package will remove it. The package managed config files are as follows
Watchdog service files are now managed by the package. Any modifications will be saved at upgrade and remove processes with the .rpmnew and .rpmsave extenstions correspondingly.
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-downtimemanager
Updated almost 4 years ago