Open Stack

Bin Zhou,

IMHO, we should have a new configuration that introduces weights for each
metrics backend we intend to use. Then, we use the datasource with the
biggest weight that actually provides the metric we are requesting. This way,
only one datasource will ever serve a given metric although many datasources
may be involved at once. By doing so, we can provide sensible defaults as to
which datasource has the best expected performance (i.e. prefer Monasca
over Ghocchi wherever possible or vice-versa) and also provide something
that will work straight out of the box.

What do you think?

Vincent Françoise
________________________________________
From: Bin Zhou <lakerzhou at gmail.com>
Sent: 22 June 2017 15:39
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Watcher] handle multiple data sources in watcher

Hi All,

I am working on the blueprint
https://blueprints.launchpad.net/watcher/+spec/watcher-multi-datasource.
It is a good idea to construct an abstract layer and hide data source
details from the consumer of the data. But I have one doubt about the
possibility of using multiple metrics data sources at the same
deployment. Metrics instrumentation is not free, it comes with
overhead of CPU, memory, storage. Production deployment should always
avoid to use multiple monitoring tools for the same metrics.

I propose to have a default monitoring engine in  the watcher
configuration. In case that multiple monitoring engines are
configured, and a user has to collect different metrics from different
monitoring engine, the caller has to specify the engine explicitly to
avoid using the default engine.

Please let me know if you have any concerns or better solutions. Thanks!

Bin Zhou (lakerzhou)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev