Allow different MON collectors

Pluggable Collector for MON

Proposer

Mark Beierl (VMware) Benjamín Diaz (Whitestack)

Type

Feature

Target MDG/TF

MON

Description

The MON module uses the same data element as RO to determine what backend it should use for gathering metrics. This prevents allowing end users the choice of alternate collectors such as SNMP, Gnocchi, or vROPS.

This feature proposes to add a new VIM account property to specify the MON collector to use for Infrastructure and VNF metrics collection.

Unless specified, the collector for openstack will remain Gnocchi, and the collector for vCD and VIO remain vROPS.

Points for discussion:

• Infra and VNF collectors could be independent - does that mean we need two properties?
• Should the prometheus backend also be configurable?
  • If so, how? (API, as this backend is not tied to any VIM)
• How far down the configuration rabbit hole do we want to do?
  • What if a VNF has its own EMS that can collect its own metrics?
  • Can a deployment specify collectors per NS?
• What is the boundary between MON and VNFM?
• Should we provide an API for external elements to push metrics to MON?
• Enable dynamically loading 3rd party plugins without the need of them being part of the codebase. Take OpenStack as reference.

Demo or definition of done

Use cases can be written and placed here.

Use Case #1:

A content delivery service for video on demand contains VDUs for the following:

• a front end load balancer
• one or more HTTP servers for serving up video content

The provider of this VNF has decided that network throughput is not the sole metric to determine when a new HTTP server should be scaled. The number of HTTP connections, which is available via SNMP should also be used.

The VNFD currently is capable of specifying what metrics to collect and what alarm thresholds to use. In addition, the provider would like to specify the type of collector for the HTTP server VDU, along with the interface to use when collecting the SNMP metrics.