Metrics and Events Requirements High Level List

This wiki is a WIP. Please feel free to modify this page with relevant information

The intention of this wiki is to list the metrics and events that should be monitored or collected within the NFVI. In addition to the metrics/events collected about the NFVI, some information about the monitoring process (the process which collects the information and metrics) itself is also required.

This list should be developed in conjunction with the  Doctor (Faults) and VES Projects in OPNFV.

This wiki heavily references The ETSI NFV draft titled “Network Functions Virtualisation (NFV); Testing; NFVI Compute and Network Metrics Specification” which can be found at https://docbox.etsi.org/ISG/NFV/Open/Drafts/TST008

Metrics/Events Format

It's important to define a common format that can be used for the list of identified metrics and events that should be monitored/collected in the NFVI.

• Name
• Where the Metric/Event is collected (Host/Guest/Both)
• Scope of coverage
• Unit(s) of measure or associated severities
• Definition
• Method of Measurement
• Sources of Error
• Comments

Distinction between metrics and events

For the purposes of Platform Service Assurance, it's important to distinguish between metrics and events as well as how they are measured (from a timing perspective).

A metric (at any point in time) represents a measurement of an aspect of a particular platform resource for the purpose of monitoring. For example the number of dropped packets for a networking interface.

An Event can be thought of as a notification about a notable condition (usually a message with an associated severity and time). Events are used to notify monitoring systems of the occurrence of something that they should be aware of. For example, if the link status of a networking device on a compute node suddenly changes from up to down on a node hosting VNFs in an NFV deployment.

Information to be collected in conjunction with NFVI Metrics/Events

It's essential to collect some information about the environment that is being monitored as well as the monitoring process(es) themselves in order to associate the mertrics/events with the relevant host.

Host information:

Each host in a deployment should have a Unique identifier that distinguishes it from all other hosts. A UUID can be used in this case.

Monitoring Process information:

Each monitoring process in a deployment should have a Unique Process identifier.

Each monitoring process in a deployment should support the following events:

Each monitoring process in a deployment should support the following Metrics:

Timing Information

NFVI Other/Additional Information

BIOS information

NFVI Events

What about entire node and switch failures?  In terms of service affecting priority, host and switch failures are at the top as they can affect the most VMs / Containers / VNFs...

While the status of switches and hosts might be the domain of services that have a system-wide view, a host-resident component might be part of the monitoring functionality.

Compute

At a minimum the following events should be monitored:

• Machine check exceptions (System, Processor, Memory...) [TODO: Break this down further]
  
  • DIMM corrected and uncorrected Errors

Networking

At a minimum the following events should be monitored for a Networking interface:

• Link Status
• Dropped Receive Packets – An increasing count could indicate the failure or service interruption of an upstream processes.  

vSwitch liveliness

Storage

NFVI Metrics

Compute

At a minimum the following metrics should be collected:

• CPU utilization TODO: Break this down further]
• vCPU utilization TODO: Break this down further]
• Memory utilization TODO: Break this down further]
• vMemory utilization TODO: Break this down further]
• Cache utilization
  • Hits
  • Misses
  • Instructions per clock (IPC)
  • Last level cache utilization
  • Memory Bandwidth utilization
• Platform Metrics (thermals, fan-speed) [TODO: Break this down further]

Networking

[TODO] Add a note on the vSwitch and add vSwitch specific metrics

At a minimum the following metrics should be collected for a Networking interface:

• Total Packets received and transmitted
• Total Octets (TX and RX)
• Dropped packets (TX and RX)
• Errored frames (TX and RX) [TODO: Break this down further – just tried to do that...]
  • Frame Check Sequence Errors or CRC Errors
  • Runts (frames <64 octets in length)
  • Giants (frames >6000 octets in length)
• Broadcast Packets (TX and RX)
• Multicast Packets (TX and RX)

Other Metrics that should be collected for a Networking interface (if possible):

• Average bitrate
• Average latency

Storage

Disk Utilization

The host CPUs, individually or total usage summed across all CPUs