Re: [onap-discuss] Need Feedback: VES Additional Info structure
The name/value pair array is usually used to allow for adding new parameters
without a change to the model.
Is that not a concern with VES additionaInformationStructures ?
Brian
From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of GUPTA, ALOK
Sent: Tuesday, January 16, 2018 1:58 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Need Feedback: VES Additional Info structure
Importance: High
***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
DCAE ONAP TEAM Members:
We have a request for updating VES additonalInformation Structure in each
Domain to get rid of repeating name and value in the additional name.
Following is an example of current implementation:
"chronicThresholdCount": "3",
"faultFields": {
"eventSourceType": "interface",
"alarmAdditionalInformation": [{
"name": "DIR",
"value": "tx"
}, {
"name": "LOC",
"value": "NEND"
}, {
"name": "TYPE",
"value": "communication"
}, {
"name": "CKTID",
"value": ""
}, {
"name": "agingThreshold",
"value": "300"
}, {
"name": "objType",
"value": "interface"
}, {
"name": "alarmEntityOid",
"value": "ORLDFLPC-0101050934 interface-eth-1/0/C1/1"
}],
"specificProblem": "lossOfSignal",
"alarmInterfaceA": "eth-1/0/C1/1",
"alarmCondition": "lossOfSignal",
"eventSeverity": "CRITICAL",
"faultFieldsVersion": 1,
"vfStatus": "Active"
},
"chronicInterval": "2"
},
The modified structure would look like:
"chronicThresholdCount": "3",
"faultFields": {
"eventSourceType": "interface",
"alarmAdditionalInformation": {
"DIR":"tx",
"LOC": "NEND",
"TYPE": "communication",
"CKTID": "",
"agingThreshold": "300",
"objType": "interface",
"alarmEntityOid": "ORLDFLPC-0101050934
interface-eth-1/0/C1/1"
},
"specificProblem": "lossOfSignal",
"alarmInterfaceA": "eth-1/0/C1/1",
"alarmCondition": "lossOfSignal",
"eventSeverity": "CRITICAL",
"faultFieldsVersion": 1,
"vfStatus": "Active"
},
"chronicInterval": "2"
},
The rationale other than this being compact and reduces event processing time,
for recommended changes are:
1. It inflates the message size by 16 bytes per name/value pair. (So, 64
entries in a message yields 1KB of waste.)
1. It forces message readers to iterate through an array doing string
comparisons at O(n) rather than a typical hash lookup of O(log n). If a message
writer drops 100 entries into that array, my high-speed event processing has to
do 100 operations instead of 6. That's a 16x slowdown! This matters quite a
bit when dealing with 1000s of events per second.
1. We have event processing tools throughout our infrastructure that know
how to pull named values from arbitrary JSON. For example, we have syntax like:
${event.faultFields.alarmAdditionalInformation.alarmEntityOid}. Unfortunately,
these tools are useless when data is in this
array-of-objects-with-name-and-value-keys format. Our tools would have to be
upgraded to support a name/value search like:
${event.faultFields.alarmAddit
[onap-discuss] Need Feedback: VES Additional Info structure
DCAE ONAP TEAM Members:
We have a request for updating VES additonalInformation Structure in each
Domain to get rid of repeating name and value in the additional name.
Following is an example of current implementation:
"chronicThresholdCount": "3",
"faultFields": {
"eventSourceType": "interface",
"alarmAdditionalInformation": [{
"name": "DIR",
"value": "tx"
}, {
"name": "LOC",
"value": "NEND"
}, {
"name": "TYPE",
"value": "communication"
}, {
"name": "CKTID",
"value": ""
}, {
"name": "agingThreshold",
"value": "300"
}, {
"name": "objType",
"value": "interface"
}, {
"name": "alarmEntityOid",
"value": "ORLDFLPC-0101050934 interface-eth-1/0/C1/1"
}],
"specificProblem": "lossOfSignal",
"alarmInterfaceA": "eth-1/0/C1/1",
"alarmCondition": "lossOfSignal",
"eventSeverity": "CRITICAL",
"faultFieldsVersion": 1,
"vfStatus": "Active"
},
"chronicInterval": "2"
},
The modified structure would look like:
"chronicThresholdCount": "3",
"faultFields": {
"eventSourceType": "interface",
"alarmAdditionalInformation": {
"DIR":"tx",
"LOC": "NEND",
"TYPE": "communication",
"CKTID": "",
"agingThreshold": "300",
"objType": "interface",
"alarmEntityOid": "ORLDFLPC-0101050934
interface-eth-1/0/C1/1"
},
"specificProblem": "lossOfSignal",
"alarmInterfaceA": "eth-1/0/C1/1",
"alarmCondition": "lossOfSignal",
"eventSeverity": "CRITICAL",
"faultFieldsVersion": 1,
"vfStatus": "Active"
},
"chronicInterval": "2"
},
The rationale other than this being compact and reduces event processing time,
for recommended changes are:
1. It inflates the message size by 16 bytes per name/value pair. (So, 64
entries in a message yields 1KB of waste.)
1. It forces message readers to iterate through an array doing string
comparisons at O(n) rather than a typical hash lookup of O(log n). If a message
writer drops 100 entries into that array, my high-speed event processing has to
do 100 operations instead of 6. That's a 16x slowdown! This matters quite a
bit when dealing with 1000s of events per second.
1. We have event processing tools throughout our infrastructure that know
how to pull named values from arbitrary JSON. For example, we have syntax like:
${event.faultFields.alarmAdditionalInformation.alarmEntityOid}. Unfortunately,
these tools are useless when data is in this
array-of-objects-with-name-and-value-keys format. Our tools would have to be
upgraded to support a name/value search like:
${event.faultFields.alarmAdditionalInformation[name=alarmEntityOid].value}.
This hardly seems worth doing - it'd be a bit difficult to implement and graft
into our current syntax and in maybe 8 years of using JSON across a lot of
services, I've never seen this construct.
We have two choices:
1. We could replace the old name/value structure with new one, or
2. We could support second structure in addition to first one to allow
both for backward compatibility.
My personal preference is to replace and let collector convert 4.x and 5.x to
the new structure. This impacts current downstream DCAE systems and I would
like to get feedback on the change from ONAP team.
I would be discussing the issue during regularly scheduled DCAE team meeting.
Please advise.
Regards,
Alok Gupta
732-420-7007
MT B2 3D30
ag1...@att.com
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
