[NSD] NS Monitoring

[mbredel]

Describing monitoring for NS is in a very early stage. It is basically copy-and-paste from the T-NOVA descriptors. Questions are:

• What monitoring parameters do we want to support?
• What is the best way to describe the monitoring parameters?

[jbonnet]

NS Monitoring depends on what the service is and how it's author wants its quality to be measured. In T-NOVA we've opted for restricting service-level monitoring parameters to a composition of VNF-level monitoring parameters, allowing simple expressions like MIN, MAX, etc., between them. In SONATA, with the SSM/FSM concepts, we may go a little further, and allow more freedom.

As to the best way to express them: this is close to what the NS/VNF monitoring tools will provide. I'd say the minimum is

• name, e.g., '#Simultaneous sessions' (something nice, to show on reports);
• type, e.g., 'number' (but might also be like '%', 'Gb', etc.);
• threshold, e.g., '100' (might be passed to the monitoring system to establish an alarm on this).

Then we must find a way for the service to provide values for this monitoring parameter, either like in T-NOVA (combination of VNF-level monitoring parameters) or totally independent, through the usage of SSMs/FSMs?

My 2 cents

[mbredel]

Let me elaborate a bit more on monitoring:

First, we need to specify the monitoring data, i.e. what is monitored:

• In the VNFD this can be done at various levels, i.e. at VNFC (aka VDU) level and at VNF level. At VNFC level, we could monitor the very basic stuff, such as cpu utilization and memory consumption. At VND level, we could monitor VNF specific things, like calls per second, but also network parameters between VNFCs and - as Jose mentioned - a composition of VNFC-level parameters.
• In th NSD this can again be done at various levels, i.e. at VNF level and at NS level. At the VNF level, we could have the same parameters as at the VNF level in the VNFD. To this end, we could override or enrich the monitoring specified already in the VNFD. But what happens, e.g. if the NS specifies a VNF-CPU monitoring when the VNF actually comprises several VNFCs? We need to resolve that. At the NS-level, we again can have NS specific things, like requests per second, but also network parameters between VNFs, and a composition of VNF-level parameters.

Second, we need to specify triggers on the monitoring data:

• Where, in the NSD, are triggers located? Are they co-located directly with the monitoring parameters? Or do we foresee a specific section for triggers? Given the various types of monitoring parameters, I propose a separate section for the triggers.
• Triggers could look like that:

trigger:
  meter_ref: "Reference to the meter (monitoring parameter)"
  threshold: "A number"
  unit: "The measurement unit"
  comparison_operator: "like <, >, >=, <=, ==, !="
  statistic: "avg, peak, ewma"
  period: "Cool down period"
  actions: "A set of actions"

Last, we need to specify the action that is triggered:

• The actions should be co-located with the triggers.
• Actions are limited to fire events, i.e. messages on the message bus. To this end, we need to specify the topic and the message itself.

[mbredel]

The triggers and the actions could live in the 'auto_scale_policy' section that is foreseen by ETSI.