Opsview Timeseries (opsview-timeseries) provides a Web Service that manages the timeseries data in Opsview. Opsview Timeseries component can be installed on a remote server (OS independent), thus reducing the load on Opsview Master Server. Due to the use of multiple processes, it also allows to utilize available resources on the server.
Adding new data
On Opsview Master server the Opsview Results-Performance component reads the collected service check outputs from the MessageQueue and passes them to the Opsview Timeseries Web Service. One of the Workers parses the raw data and extracts from it the performance metrics - this operation is very CPU intensive. The parsed data is then dispatched in CBOR format to configurable storage providers based on the host name - so given host’s servicechecks metrics are always send to the same Enqueuer.
Performance data graphs in Opsview UI query the Opsview Timeseries Web Service which dispatches the request to the storage providers that handle given host servicechecks metrics. The returned information is in JSON format and can be cached by reverse-proxies.
Opsview Timeseries can be installed on any supported platform.
Refer to Advanced Automated Installation.
opsview-timeseries was installed on other than Opsview Master host, you need to update the
/opt/opsview/coreutils/etc/opsview.conf file to be able to query the graphs, eg.:
$timeseries_url = 'http://192.168.10.22:1600';
And Results Performance configuration file
/opt/opsview/resultsperformance/etc/resultsperformance.yaml, so it knows where to send the tests results:
resultsperformance: http_server: host: 127.0.0.1 port: 1600
As Opsview Timeseries by default listens only on loopback interface, so you need to update its configuration located in
timeseries: server: host: 0.0.0.0
All configurable options are listed in the
timeseries: server: # IP to listen on, use 0.0.0.0 to listen on all interfaces host: 127.0.0.1 # port to listen on port: 1600 # number of pre-forked subprocesses handling the incoming requests workers: 4 # username and password for HTTP Basic authorization user: opsview password: opsview # should it parse the output of the servicecheck (old style plugins that not use the separate performance metrics field) # and the path to the file used parser: parse_output: true mapfile: /opt/opsview/timeseries/etc/map # list of providers handling the actual requests nodes: # url to the host - url: http://192.168.11.33 # username and password for HTTP Basic authorization user: opsview password: opsview # port used by the Enqueuer updates_port: 1620 # port used by the Queries queries_port: 1660 # add more hosts for storing timeseries data - url: http://192.168.12.44 user: opsview password: opsview updates_port: 1620 queries_port: 1660 logging: loggers: opsview: # syslog compatible log level, at INFO level HTTP requests are logged level: NOTICE
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-timeseries
Performance data is not being generated or it is not interpreted correctly
Some Servicechecks do not provide performance data. Other checks do provide it but the data isn’t interpreted correctly. In both cases a change can be made via a ‘map’ file
/opt/opsview/timeseries/etc/map.local — this file is used to read the plugin output and (if a match is found) generate performance data for use in graphs (if no match is found then any performance data output by the plugin is used).
This file is a series of perl regular expressions which matches Servicecheck output. You can see examples within the file
/opt/opsview/timeseries/etc/map but you should only ever make changes to
/opt/opsview/timeseries/etc/map.local; this is because
map will be overwritten on an upgrade whereas
map.local will not.
Any changes should be followed by a
perl -c map.local
to ensure there are no grammatical errors in the file.
After making a change, the
opsview-timeseries daemon will need to be restarted.