diff options
author | Filip Krzywka <filip.krzywka@nokia.com> | 2018-09-25 10:57:17 +0200 |
---|---|---|
committer | Filip Krzywka <filip.krzywka@nokia.com> | 2018-10-01 09:42:08 +0200 |
commit | 4bb79b722985784e650243248e7450e279485fa9 (patch) | |
tree | 6fc5980f98c66d6a2467d872df402b5435536e78 /docs/sections/services/ves-hv/design.rst | |
parent | 19736a929017aaa9801b268ca8387745cd1a90ca (diff) |
HV-VES main documentation draft
Change-Id: I2416a73b703494bdbc8ef35c3608711ea2807018
Issue-ID: DCAEGEN2-831
Signed-off-by: Filip Krzywka <filip.krzywka@nokia.com>
Diffstat (limited to 'docs/sections/services/ves-hv/design.rst')
-rw-r--r-- | docs/sections/services/ves-hv/design.rst | 51 |
1 files changed, 51 insertions, 0 deletions
diff --git a/docs/sections/services/ves-hv/design.rst b/docs/sections/services/ves-hv/design.rst new file mode 100644 index 00000000..8e7ce7ad --- /dev/null +++ b/docs/sections/services/ves-hv/design.rst @@ -0,0 +1,51 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Design +====== + + +Compatibility aspects (VES-JSON) +-------------------------------- + +HV-VES Collector has been designed as a high-volume variant of the existing VES(JSON) collector, and not a completely new collector. +HV-VES follows the VES-JSON schema - as much as possible + +- It uses a Google Protocol Buffers ( GPB/PROTO ) representation of the VES Common Header +- The PROTO files tend to use most encoding effective types defined by GPB to cover Common Header fields. +- It makes routing decisions based mostly on the content of the "Domain" parameter +- It allows to embed Payload of different types (by default PERF3GPP domain is included) + +Analytics applications impacts + +- An analytics application operating on high-volume data needs to be prepared to read directly from Kafka +- An analytics application need to operate on GPB encoded data in order to benefit from GPB encoding efficiencies +- It is assumed, that due to the nature of high volume data, there would have to be dedicated applications provided, +able to operate on such volumes of data. + +Extendability +------------- + +HV-VES was designed to allow for extendability - by adding new domain-specific PROTO files. + +The PROTO file, which contains the VES CommonHeader, comes with a binary-type Payload parameter, where domain-specific data shall be placed. +Domain-specific data are encoded as well with GPB, and they do require a domain-specific PROTO file to decode the data. +This domain-specific PROTO needs to be shared with analytics applications - HV-VES is not analyzing domain-specific data. + +In order to support the RT-PM use-case, HV-VES includes a "PERF3GPP" domain PROTO file, as within this domain, +the high volume data is expected to be reported to HV-VES collector. +Still, there are no limitations to define additional domains, based on existing VES domains (like Fault, Heartbeat) +or completely new domains. New domains can be added "when needed". + +GPB PROTO files are backwards compatible, and such a new domain could be added without affecting existing systems. + +Analytics applications will have to be as well equipped with this new domain-specific PROTO file. +Currently, these additional, domain specific proto files could be simply added to respective repos of HV-VES collector. + +Implementation details +---------------------- + +- Project Reactor is used as a backbone of the internal architecture. +- Netty is used by means of reactor-netty library. +- We are using Kotlin so we can write very concise code with great interoperability with existing Java libraries. +- Types defined in Λrrow library are also used when it improves readability or general cleanness of the code.
\ No newline at end of file |