VOL-3238: Documentation for Events and Metrics flow
Change-Id: I45615a246069533ee18e7623620b2a2766cb984f
diff --git a/README.md b/README.md
index 3e5f659..e2558ec 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
# Device Management Interface
-##Overview
+## Overview
This repository holds the `.proto` files and documentation for the device management interface.
The proto files and APIs are based on [RFC-8348](https://tools.ietf.org/html/rfc8348) from IETF and WT-383 from BBF
@@ -7,6 +7,8 @@
The device manager will then translate the commands to the device native interface (e.g. Redfish or NETCONF with
proprietary yang models).
+Related documentations can be found in the [docs/](./docs) directory
+
More details are upcoming.
## Meetings
@@ -17,4 +19,4 @@
Meeting link: https://onf.zoom.us/j/92568509208
-Agenda: [google doc](https://docs.google.com/document/d/16CIUUWGfYv9UGT4LxXuHHDvu1q9J4PYowlpijqL27F4/edit?usp=sharing)
\ No newline at end of file
+Agenda: [google doc](https://docs.google.com/document/d/16CIUUWGfYv9UGT4LxXuHHDvu1q9J4PYowlpijqL27F4/edit?usp=sharing)
diff --git a/docs/EventsMetrics.md b/docs/EventsMetrics.md
new file mode 100644
index 0000000..06c6fc2
--- /dev/null
+++ b/docs/EventsMetrics.md
@@ -0,0 +1,30 @@
+# Events and Metrics
+
+The events and periodic metrics are asynchronously sent out by implementations of a Device Manager. A Device Manager implementing this interface should write these to a kafka bus.
+
+Kafka has been chosen as a means to export from the device manager as it is suitable for handling asynchronous events. Persistence for the events and metrics can be easily achieved using kafka. Moreover kafka gives the flexibilites of handling and processing of the events and metrics by different/mulitple north-bound components/processes. Implementations could choose to have different services (with potentially multiple instances) handling the events and metrics.
+
+
+
+The kafka topics to which these are written should be configurable at startup of the components, so that different deployments have the flexibility of choosing those.
+The recomendation is to use **dm.events** for the events and **dm.metrics** for the metrics as the names of the kafka topics.
+
+The two protobuf messages which would be used for this are:
+``` protobuf
+message Metric {
+ MetricNames metric_id = 1;
+ MetricMetaData metric_metadata = 2;
+ ComponentSensorData value = 3;
+}
+
+message Event {
+ EventMetaData event_metadata = 1;
+ EventIds event_id = 2;
+ google.protobuf.Timestamp raised_ts = 3;
+ // Optional threshold information for an event
+ ThresholdInformation threshold_info = 4;
+ // Any additional info regarding the event
+ string add_info = 5;
+}
+```
+Note: The on-demand metrics query using the API `GetMetric` would be passed back over GRPC and not over the kafka bus.
diff --git a/docs/events_metrics.png b/docs/events_metrics.png
new file mode 100755
index 0000000..23f43fd
--- /dev/null
+++ b/docs/events_metrics.png
Binary files differ
