VES: A Modeled Approach
to Monitoring VNF Event
Streams
Bryan Sullivan and Alok Gupta, AT&T
OPNFV VES (VNF Event Stream) Project Objective
Enable significant reduction in effort to integrate VNF
telemetry into automated VNF management systems,
by promoting convergence to a common event
stream format and collection system.
https://wiki.opnfv.org/display/VES
30 Sept 2016
OpenStack Days Seattle
2
Why this is needed
 Telemetry data formats and semantics / expected actions by
management systems vary widely
 For Fault Events, vendors use SNMP, 3GPP Corba, MTOSI, OSSJ etc,
and semantics can differ (e.g. Critical Severity as “1” or “5”)
 For Measurement events (KPI/KCI), vendors deliver CSV or XML based
files, with varying internal data formats
 This variance results in substantial development and maintenance
costs for VNF integration into management systems
 3-6 months development is typically needed
30 Sept 2016
OpenStack Days Seattle
3
Project Scope and Deliverables
 VNF Event Stream Common Event Data Model
 To be developed in collaboration with SDOs and other open source projects
 Integration into the OPNFV platform as a monitoring framework
 A VES Agent that can collect the VNF Event Stream data from the VNF and
deliver it to the VES Collector
 A VES Collector that can consume the VNF Event Stream data, and store the
data in a database backend
 VES plugins for integration with OpenStack infrastructure services such as
Monasca, Vitrage, Congress
 A plan for upstreaming the project code
30 Sept 2016
OpenStack Days Seattle
4
Why this is relevant to OpenStack
•
NFV Service Providers need to monitor and manage all aspects of the environment
• Applications (VNFs and other VFs)
• Physical and virtual infrastructure (compute, storage, network devices)
• Virtual infrastructure managers (Cloud controllers, SDN controllers)
•
OpenStack’s internal telemetry is not a holistic solution for all those needs
• It supports only a subset, primarily focused on the virtual infrastructure it manages
• Challenges applying the telemetry system outside OpenStack, and at scale
•
VIMs can benefit from relevant events they would otherwise not be aware of, e.g.
• Application state, fault, and performance events
30 Sept 2016
OpenStack Days Seattle
5
VES interfaces
Other Management Functions
Application Controller
In scope:
•
Green/solid interfaces
•
Agent/Collector
interface support
library and reference
implementation
•
OpenStack component
plugins
Monasca
Vitrage
Congress
etc
SDNC
30 Sept 2016
VES Collector
OpenStack
Agent code is embedded
in VNFCs, Virtualization
Hosts, and Bare Metal
Hosts
Agents / VNFCs can also
deliver directly to
OpenStack Plugins
Plugins
Collector can
integrate with
other OpenStack
Collectors
Message Bus
VES Agent
VNFC
VES Agent
Direct (REST)
Virtualization Host(s)
Bare Metal Host
OpenStack Days Seattle
6
VES – Common Event Data Model


Header
Domain
VNF Attribute
Timing
Fault
Severity
Source
Spec, Prob
Common Event Data Model

Common Header and Domain Specific Event

Extensible for additional fields or domains
Collector connection and data profile established at VM creation


Connection/authentication/profile parameters injected into VM
Data profile is fully controllable, to optimize telemetry overhead
measurement
KPI
KCI
VF Scaling
Name/Value
30 Sept 2016
Name/Value
SysLogs
Facility
Data
Proc…..
Name/Value
MobileFlow
RptEndPt
OthEndPt
Flow…...
Name/Value
OpenStack Days Seattle
StateChange
OldState
NewState
StateInterface
Name/Value
Other
vProbe
Being
Defined
Name/Value
…..
CLF
Usage
Configuration
Signaling
Name/Value
7
Initial VES Data Model
• UML diagram based upon a YANG representation of the
VES JSON schema
30 Sept 2016
OpenStack Days Seattle
8
Initial VES Data Model
• This illustrates the basic fault
domain event data
• VES data model will be
published in JSON, and easily
adaptable to
– Other representations (e.g.
YANG)
– Control protocols e.g.
HTTP/REST (current agent
code), Netconf, AVRO, gRPC.
Domains with data/volume
size may determine the
protocol used.
30 Sept 2016
OpenStack Days Seattle
9
Use cases with example closed-loop monitoring plugins
Events
VNF
Collector
Event
Processor
PM
(Threshold
Crossing Alert)
Correlation
Policy
Enforcement/
Automation
Scenario 1: False Alarm
Data Bus
Scenario 2: VM Failure
Scenario 3: Scaling Alert
Tickets Generated,
Updated and Closed
Ticketing System
30 Sept 2016
OpenStack Days Seattle
Scenario 1: Failure
Event, Notification
Scenario 2: Payload Processor Failure
Publish an event to Restart VM
Scenario 3: High CPU Utilization
Published an event for service
orchestrator to create a New VF
10
Takeaways and next steps
• Common telemetry data models can improve ROI in
VNF onboarding
• OPNFV will work with SDOs (TM Forum, OASIS, ETSI)
to standardize the VES event data model
• OPNFV will prototype OpenStack services integration as
VES providers/consumers, with blueprints to follow
• Collaborators in the OPNFV VES project are welcome!
30 Sept 2016
OpenStack Days Seattle
11
THANK YOU!
• For more info, stop by https://wiki.opnfv.org/display/VES
• And while you’re there check out other OPNFV projects
– https://wiki.opnfv.org/display/copper (Configuration Policy): Deployment
and use of OpenStack Congress on OPNFV
– https://wiki.opnfv.org/display/models/ (Model-Driven NFV): Deployment
and use of VNF Managers e.g. OpenStack Tacker, Cloudify,
OpenBaton, as tools to drive support/convergence of standard VNF
packages and blueprints
30 Sept 2016
OpenStack Days Seattle
12