Timeseries
Overview Copied
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 Copied
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.
Timeseries queries Copied
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.
Dependencies Copied
Opsview Timeseries can be installed on any supported platform.
Installation Copied
Refer to Advanced Automated Installation.
Configuration Copied
If 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 /opt/opsview/timeseries/etc/timeseries.yaml:
timeseries:
server:
host: 0.0.0.0
All configurable options are listed in the /opt/opsview/timeseries/etc/timeseries.defaults.yaml
and /opt/opsview/timeseries/etc/timeseries.yaml.example.
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
Service administration Copied
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-timeseries
Troubleshooting Copied
Performance data is not being generated or it is not interpreted correctly Copied
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.