.. literalinclude:: VesEvent.proto
:language: protobuf
-HV-VES makes routing decisions based mostly on the content of the **Domain** parameter in the VES Common Event Header.
+HV-VES makes routing decisions based on the content of the **domain** field or **stndDefinedNamespace** field in case of stndDefined events.
The PROTO file, which contains the VES CommonEventHeader, comes with a binary-type Payload (eventFields) parameter, where domain-specific
data should be placed. Domain-specific data are encoded as well with GPB. A domain-specific PROTO file is required to decode the data.
API towards DMaaP
=================
-HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
+HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain (or stndDefinedNamespace) and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
- **Kafka record key** is a GPB-encoded `CommonEventHeader`.
- **Kafka record value** is a GPB-encoded `VesEvent` (`CommonEventHeader` and domain-specific `eventFields`).
In both cases raw bytes might be extracted using ``org.apache.kafka.common.serialization.ByteArrayDeserializer``. The resulting bytes might be further passed to ``parseFrom`` methods included in classes generated from GPB definitions. WTP is not used here - it is only used in communication between PNF/VNF and the collector.
-By default, **HV-VES** will use routing defined in **k8s-hv-ves.yaml-template** in **dcaegen2/platform/blueprints project**.
-Currently there is one domain->topic mapping defined: perf3gpp->HV_VES_PERF3GPP
+By default, **HV-VES** will use routing defined in **k8s-hv-ves.yaml-template** in **dcaegen2/platform/blueprints project** when deployed using Cloudify.
+In case of Helm deployment routing is defined in values.yaml file in HV-VES Helm Chart.
.. _supported_domains:
Supported domains
=================
-As for now **HV-VES** supports only **perf3gpp** domain
+Domains that are currently supported by HV-VES:
+
+- perf3gpp - basic domain to Kafka topic mapping
+- stndDefined - specific routing, when event has this domain, then stndDefinedNamespace field value is mapped to Kafka topic
For domains descriptions, see :ref:`domains_supported_by_hvves`
.. note:: *MeasResult.p* can be used to reduce the event size when more than half of the values in the event are zero values, and these values are not sent to ONAP. Only non-zero values are sent, together with their *MeasInfo.MeasTypes* index (*MeasResult.p*).
-
-
-
-
+.. _stndDefined_domain:
+
+stndDefined domain
+------------------
+
+The purpose of 'stndDefined' domain was to allow collection of events defined by standard organizations using HV-VES,
+and providing them for consumption by analytics applications running on top of DCAE platform.
+
+All events, except those with 'stndDefined' domain, are routed to DMaaP topics based on domain value. Events with
+'stndDefined' domain are sent to proper topic basing on field 'stndDefinedNamespace'.
+
+This is the only difference from standard event routing, specific for 'stndDefined' domain. As in every other event
+routing value is being mapped for specific Kafka topic. Mappings to Kafka topics are located in HV-VES Helm Chart
+values.yaml file. Four of them are by default available in HV-VES:
+
++-------------+--------------------------------+--------------------------------------+
+| Domain | StndDefinedNamespace | Kafka topic |
++=============+================================+======================================+
+| stndDefined | ves-3gpp-fault-supervision | SEC_3GPP_FAULTSUPERVISION_OUTPUT |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-provisioning | SEC_3GPP_PROVISIONING_OUTPUT |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-heartbeat | SEC_3GPP_HEARTBEAT_OUTPUT |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-performance-assurance | SEC_3GPP_PERFORMANCEASSURANCE_OUTPUT |
++-------------+--------------------------------+--------------------------------------+
- HV-VES uses a Google Protocol Buffers (GPB, proto files) representation of the VES Common Header.
- The proto files use most encoding-effective types defined by GPB to cover Common Header fields.
-- HV-VES makes routing decisions based mostly on the content of the **Domain** parameter.
-- HV-VES allows to embed Payload of different types (by default perf3gpp domain is included).
+- HV-VES makes routing decisions based on the content of the **domain** field or **stndDefinedNamespace** field in case of stndDefined events.
+- HV-VES allows to embed Payload of different types (by default perf3gpp and stndDefined domains are included).
Analytics applications impacts
In order to support the RT-PM use-case, HV-VES uses a **perf3gpp** domain proto file. Within this domain, high volume data are expected to be reported to HV-VES collector.
Additional domains can be defined based on existing VES domains (like Fault, Heartbeat) or completely new domains. New domains can be added when needed.
+There is also **stndDefined** domain supported by default in HV-VES. Events with this domain are expected to contain
+data payload described by OpenAPI schemas. HV-VES doesn't decode payload of stndDefined events thus it does not contain
+specific **stndDefined** proto files. The only difference of **stndDefined** domain is its specific routing. More
+details of stndDefined routing: :ref:`_stndDefined_domain`.
+
GPB proto files are backwards compatible, and a new domain can be added without affecting existing systems.
Analytics applications have to be equipped with the new domain-specific proto file as well.
"bootstrap_servers": "message-router-kafka:9092",
"topic_name": "HV_VES_HEARTBEAT"
}
+ },
+ "ves-3gpp-fault-supervision": {
+ "type": "kafka",
+ "kafka_info": {
+ "bootstrap_servers": "message-router-kafka:9092",
+ "topic_name": "SEC_3GPP_FAULTSUPERVISION_OUTPUT"
+ }
+ },
+ "ves-3gpp-heartbeat": {
+ "type": "kafka",
+ "kafka_info": {
+ "bootstrap_servers": "message-router-kafka:9092",
+ "topic_name": "SEC_3GPP_HEARTBEAT_OUTPUT"
+ }
}
}
}
For every JSON key-object pair defined in **"stream_publishes"**, the key is used as domain and related object is used to setup Kafka's bootstrap servers and Kafka topic **for this domain**.
-When receiving a VES Event from client, collector checks if domain from the event corresponds to any domain from Routing and publishes this event into related topic. If there is no match, the event is dropped. If there are two routes from the same domain to different topics, then it is undefined which route is used.
+When receiving a VES Event from client, collector checks if domain (or stndDefinedNamespace when domain is 'stndDefined') from the event corresponds to any domain from Routing and publishes this event into related topic. If there is no match, the event is dropped. If there are two routes from the same domain to different topics, then it is undefined which route is used.
For more information, see :ref:`supported_domains`.
Code Review / dcaegen2.git / commitdiff