Open Stack

Vincent,

Thanks for your comment. Here is my understanding of the problem:
1. cloud operators will choose one particular metrics monitoring stack/source
but not multiple of them on the same target;
2. in the same cloud, it is possible that some compute are monitored
with Monasca, some computes are monitored with ceilometer, but it is
not the common deployment practice
3. In the same cloud, it is very rare that multiple monitoring stacks
run on the same compute - here is why: 1) larger performance overhead,
2) correlation between different data samples become difficult (due to
potentially different sampling intervals, and API interfaces), 3) not
scale;

Basically the design I proposed is to support all the three scenarios
above, but the implementation will be optimized for scenario #1 only.
1. define a global configuration of default monitoring stack, for example,
[Defaults]
default_metrics = Monasca
default_alarm = Monasca
metrics_engines = Monasca, Gnnochi, Ceilometer, ## list of metrics
engines in preference order

[Metrics]
Monasca_URL = ""
Gnnochi_URL = ""
...
[Alarms]
Monasca_URL = ""
Aodh= ""

[Events]
....

2. At the time when watcher starts, watcher read in all the
configurations and populated its internal data structure including the
preference and availability.
3. An abstract layer will be built for each data source. For
example, the following interfaces will be implemented for metrics
data source:
get_metrics_cpu()
get_metrics_io()
get_metrics_memory()
4. Each data source pliugin will implement the abstract interface. If the
plugin doesn't support the function, it will throw exceptions
5. A consumer of a service, will use the abstract interface to access
the service. Unless a caller specify a engine explicitly, the default
engine will be used. If the default engine does not support the
function, the call will be directed to the next available engine in
the preference order.

Please let me know what you think.

regards,
Bin

On Thu, Jun 22, 2017 at 10:52 AM, Vincent FRANCOISE
<Vincent.FRANCOISE at b-com.com> wrote:
> 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
>
> __________________________________________________________________________
> 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