<Please fill out the Overview, Design and User Experience sections for an initial review of the proposed feature.>

Overview

<Briefly describe the problem being solved, not how the problem is solved, just focus on the problem. Think about why the feature is needed, and what is the relevant context to understand the problem.>

There are limited built-in metrics available about an edge node, its host, and workloads.  Traditional approaches include streaming logs to a remote host, or surfacing them so they can be queried on the edge node by a remote operator logging in.  Each of those approaches has drawbacks and are not edge native.

Design

<Describe how the problem is fixed. Include all affected components. Include diagrams for clarity. This should be the longest section in the document. Use the sections below to call out specifics related to each aspect of the overall system, and refer back to this section for context. Provide links to any relevant external information.>

If an application were to be installed on an edge node, preferably delivered by Open Horizon, that could query the system for information, surface it, and make the data available in an efficient and edge-native manner, that would be ideal.  This may mean updating the node properties, and it may mean making the information remotely queryable without the operator logging in to the edge node.

The design includes 3 layers described below:

• The platform functionality
• The node functionality
• The query and monitoring functionality

The Platform Functionality - Extending Open Horizon as a Platform:

AnyLog extends the Open Horizon functionality delivered to the edge as a platform:

• A shared metadata layer (hosted on blockchain or a master node) that contain policies shared among participating nodes. For example:
  • Policies representing the members of the network.
  • Policies representing the schemas used.
  • Policies representing configurations.
  • Policies representing nodes and users permissions.
  • Any metadata that needs to be shared among nodes of the network.
• A Peer to Peer and secure network using the AnyLog protocol allowing nodes to exchange messages.

The Node Functionality - Extending the functionalities of nodes deployed by Open Horizon:

  AnyLog extends the Open Horizon functionality delivered to the individual nodes by using the platform functionality such that:

• Data that needs to be monitored will be persistent in a local database.
• The schemas that are used to store the data are shared among all participating nodes.
• Each node is extended to include a rule engine that can act on data and status events.
• Each node is extended to include southbound connectors (to ingest data) and northbound connectors (to share data).
• Each node can collect and monitor the target metrics.

The query and monitoring functionality

Nodes members of the network, as well as applications connected to nodes in the network, are able to view all the monitored data as if it is a single and unified collection of data.
Practically, nodes view a virtual database based on the schema published by the shared metadata layer and can issue queries to the data as if the data is centralized.

In addition, a network can be configured such that nodes would push data to an aggregator node periodically, or based on events.

The query or monitoring can view an entire network as a single machine, or dynamically partition the network to satisfy the user view by criteria's determined by the users (and represented in the shared metadata policies).
For example: by locations, by type of software deployed, by owners etc.

User Experience

<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>

User experience is similar to the experience with a cloud/centralized solution:

• From a single point, the distributed data can be queried as if the data is hosted in a centralized database.
  • A user selects a database from a list of virtual databases.
  • A user selects a table from a list of virtual tables.
  • A user issue q query to the table.
  • The user can specify all nodes with relevant data (nodes with data associated to the table), or specify a subset of nodes (for example: nodes deployed in a region or nodes with a named data owner).
• From a single point, all the resources are monitored and managed as if the resources are hosted in a single machine. 
  • User can issue a status request from all nodes or to  a subset of nodes (for example: nodes deployed in a region or nodes with a named data owner).
  • Users can query an aggregator node.
• Using the rule engine, users and processes can be alerted by events on the individual nodes or on the aggregator node.

Command Line Interface

<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use the changed CLI. This section should flow very naturally from the User Experience section.>

Are there any ways to optionally extend the CLI when components are installed?  If not, they we should avoid this.

External Components

<Describe any new or changed interactions with components that are not the agent or the management hub.>

Installing the Anylog agent on an edge node should provide metrics collection and surfacing.

Affected Components

<List all of the internal components (agent, MMS, Exchange, etc) which need to be updated to support the proposed feature. Include a link to the github epic for this feature (and the epic should contain the github issues for each component).>

N/A

Security

<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>

Ideally, the Anylog component should not need root-level access.  

The Anylog component maintains its own P2P network.

APIs

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>

Link to Anylog docs.

Build, Install, Packaging

<Describe any changes to the way any component of the system is built (e.g. agent packages, containers, etc), installed (operators, manual install, batch install, SDO), configured, and deployed (consider the hub and edge nodes).>

Documentation Notes

<Describe the aspects of documentation that will be new/changed/updated. Be sure to indicate if this is new or changed doc, the impacted artifacts (e.g. technical doc, website, etc) and links to the related doc issue(s) in github.>

Test

<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>