Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added details describing enrichment added in Jira DCAEGEN2-116

...

Jira:


Detailed Description:

This CDAP application is driven by the VES collector which outputs to Message Router.  This Message Router topic is the source for the CDAP application which will read each incoming message. If a message meets the Common Event Format (CEF, v28.3) as specified by the VES 5.3 standard (AttServiceSpecification-VesEventListener-v5.3.docx, Rev: 5.3, 6/22/17), it will be parsed and if it contains a message which matches the policy configuration for a given metric (denoted primarily by the "eventName" and the "fieldPath"), the value of the metric will be compared to the "thresholdValue".  If that comparison indicates that a Control Loop Event Message should be generated, the application will output the alarm to the Message Router Sink topic in a format that matches the interface spec defined in the ONAP Control Loop Operational Policy (see section titled "Control Loop Event Messages").

...

JSON Field

JSON sub-field

Populate Using

Description

{


closedLoopControlName

closedLoopControlName included in the DCAE configuration Policy

The unique ID for the Control Loop. It is created by the CLAMP platform during Control Loop design.

The DCAE Micro service that publishes this event structure MUST include this ID.

version

version included in the DCAE configuration Policy

The version of the Control Loop event message. Should be '1.0.2'.
requestID

Generate a UUID for this output message

For the control loop, when an instance of the Control Loop occurs, this unique ID must be created. The same ID

must be forwarded for both the ONSET and the ABATED control loop messages.

closedLoopAlarmStart
commonEventHeader.startEpochMicrosec from the received VES measurementsForVfScaling messageWhen the alarm was first detected.
closedLoopEventClient
Concatenate name of this DCAE instance and name for this TCA instance, separated by "."For monitoring/logging/auditing purposes, if there is an instance ID of the DCAE micro service this field should be populated with it.
target_type
"VNF"The type of the target: VM or VNF. Future PNF(?).
target
"generic-vnf.vnf-id" or "vserver.vserver-name"

This is the name of the field within the A&AI sub-tag that indicates the actual entity Node details. There should be a matching node field within the A&AI subtag holding this value.

AAI{
Contains the A&AI Node-Attribute list.

generic-vnf.vnf-id

commonEventHeader.reportingEntityName from the received VES measurementsForVfScaling message (value for the data element used in A&AI)



generic-vnf.in-maintvalue

If the A&AI enrichment query added in JIRA

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-116
is successful, the TCA response will contain additional fields obtained from A&AI. Notice that the examples shown here are for the case where the target_type is VNF. See Note 1 below for the values corresponding to the case where the target_type is VM. For more design details see VES event enrichment for DCAE mS.


generic-vnf.is-closed-loop-disabledvalue

generic-vnf.orchestration-statusvalue

generic-vnf.prov-statusvalue

generic-vnf.resource-versionvalue

generic-vnf.service-idvalue

generic-vnf.vnf-namevalue

generic-vnf.vnf-typevalue

}

}from
"DCAE"The ONAP platform component publishing this message. If DCAE, then it should be 'DCAE'.
policyScope
policyScope included in the DCAE configuration PolicyThe version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller.
policyName
policyName included in the DCAE configuration PolicyThe version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller.
policyVersion
policyVersion included in the DCAE configuration PolicyThe version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller.policyVersionpolicyVersion included in the DCAE configuration PolicyThe version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller.closedLoopEventStatus"ONSET"controller.
closedLoopEventStatus
"ONSET"

Note 1:  For the case where the VES reporting entity is a VM, the following enrichment fields will be added to the AAI object:

"AAI": {
    "vserver.in-maint": value,
    "vserver.is-closed-loop-disabled": value,
    "vserver.prov-status": value,
    "vserver.resource-version": value
    "vserver.vserver-id": value,
    "vserver.vserver-name": value,
    "vserver.vserver-name2": value
    "vserver.vserver-selflink": value    
} 



For the vFW demo, a sample output alert sent to MR is as shown in Sample 3.  Note, this output will correspond to a control loop where the config policy contains:

...

Table 2: Configurable Properties Exposed through the Policy Interface

JSON FieldJSON sub-fieldJSON sub-fieldDescriptionNotes
{



domain

the domain datatype of the VES messageMust be measurementsForVfScaling
metricsPerEventName[ {
an array that describes parameters associating a closed loop flow to the policy governing this TCA instance

eventName
a unique identifier that represents an event name that this TCA instance will act onFrom VES 5.3 spec: 

"It should be understood that events are well structured packages of information, identified by an eventName, which are asynchronously communicated to subscribers who are interested in the eventName.  Events can convey measurements, faults, syslogs, threshold crossing alerts and others types of information.  Events are simply a way of communicating well-structured packages of information to one or more instances of an Event Listener service."


controlLoopSchemaType
this is a field which will be used to derive the schema of the Control Loop Event MessageValid values for the Amsterdam release:  VM | VNF

policyScope
the scope of this policy message

policyName
a name identifying this policy message

policyVersion
a version identifying this policy message

thresholds[{an array of one or more thresholds that are managed as part of a given closed loop


closedLoopControlNamethe name that specifies which control loop this TCA instance is a part of


versionthe version of the control loop


fieldPatha value used to derive the metric within VES message that this TCA will apply toexpected to be part of a measurementsForVfScaling domain event message


thresholdValuethe value of the metric which will trigger this thresholdmust be numeric


directionDirection of the thresholdvalid values: LESS | LESS_OR_EQUAL | GREATER | GREATER_OR_EQUAL


severityan identifier specifying the precendence of this threshold evalution; thresholds will be evaluated from highest severity (CRITICAL) to lowest (NORMAL); a given VES message will only trigger one thresholdvalid values: CRITICAL | MAJOR | MINOR | WARNING| NORMAL


closedLoopEventStatusan identifier used to describe whether this threshold should be associated with a control loop ONSET action or whether it would describe a condition that indicates such a condition has ended (i.e. the condition has ABATED).  Note that ABATED alerts will be correlated to ONSET events based on the following key fields (9/11/17, TODO:  add key fields here)valid values:  ONSET | ABATED


}, { },...]One or more thresholds may be defined; as noted above they will be evaluated based on severity; thresholds with closedLoopEventStatus of ABATED will be evaluated prior to ONSET thresholds

}, { }, ...]
One or more metricsPerEventName definitions may be provided to a TCA instance

As compared to the ONAP R0 release where the configuration policy was flattened into a series of key-value pairs, in the ONAP R1 release, such config info will be passed from the controller to the CDAP app as a complex json object.  A design goal for creating the schema for this policy model was to insure that the model was extensible so that a single instance of TCA could handle one or more use cases without alteration to the schema.  That said, for the Amsterdam/ONAP R1 release, we are expecting to have a single instance of TCA deployed via CLAMP for each use case.  Samples 5 through 7 illustrate a sample config policy that is expected with each use case while Sample 8 shows how a single instance could receive the policy config for all use cases.

...