Support for telemetry/events occurring throughout the toolkit

[rsdmike]

Hey Everyone,

As we've begun to start thinking about how we can provide a bit more insight about the events and actions that occur throughout the toolkit, we thought it would be a good idea to get some input from everyone that is using the toolkit on the structure and set of topics we have come up with. We have decided on MQTT and below is what we have in mind thus far:

/mps
/mps/#
/mps/events/#
/mps/events/amt/#
/mps/events/amt/AMT/[MethodName]/   #this one stutters :(
/mps/events/amt/CIM/#
/mps/events/amt/IPS/#
/mps/events/cira/#

General format is /[servicename]/events/[typeofevent]/[detail]

Thoughts to kick off the discussion:

• Should GUID be apart of the topic to subscribe? (i.e. /mps/events/{guid}/amt/AMT/[MethodName]/ )
• Would be able to subscribe to all guids using +, and allows device specific subscriptions, but the GUID is also in the payload

Payload Example:

export interface OpenAMTEvent {
  type: "success"
  message: "Sent Power Action"
  method: "AMT_BootSettingData"
  guid: "123e4567-e89b-12d3-a456-426652340000"
  timestamp: 1622150505178
}

We know more needs to be considered (i.e. which power action was sent). But hopefully at the very least, a thumbs up/down on what we've laid out will help ensure we are on the right track! Any feedback is appreciated 🚀

[matt-primrose]

What if our [typeofevent] list followed our REST API grouping?

• Auth - would event when MPS issues a JWT. This could be a good security warning check, i.e. should never see these events if MPS Auth is disabled
• AMT - broken down by method like described above
• Devices - would handle device connection and disconnection events
• Metadata - would handle metadata updates

the tree would look like:

/mps
/mps/#
/mps/events/#
/mps/events/Auth/#
/mps/events/AMT/#
/mps/events/AMT/[MethodName]/
/mps/events/Devices/#
/mps/events/Metadata/#

[rsdmike]

Metadata is gone, but yes I like this!

[jsastriawan]

MQTT is a good idea especially when we have multiple publishers, ie. multi MPS in Kubernetes scale deployment, however to maintain consistent authentication, network configuration and security profile, a websocket transport should be used. MQTT TCP 1883 and MQTTS 8883 can be used but some network firewall may block that traffic. MQTT over Websocket should be the primary transport on that. Additionally, MQTT should use the same authentication as the REST API.

Aedes is a great candidate for that. Care also should be taken on the rule of broadcasting the events on multi-tenants scenario. Only the users who have rights to a node can receive events from that particular node.

[matt-primrose]

The idea is to use MQTT for inter-service communication. Ideally this communication is just inside of the cloud infrastructure. The broker would be something that the ISV runs and would be responsible for securing access. Multi-tenancy items would also be handled by the ISV as these events would be consumed and parsed prior to sorting into the tenant space.

The current plan is to have a broker reference implementation that we put some security around that can be used to evaluate how this service event feature works.

[rsdmike]

The idea is actually more for outside services (not part of open-amt-cloud-toolkit) to subscribe to events that occurred in the toolkit. So not so much inter-service communication as it is for hooking up to like a TIG stack, or other services in an ISV's cloud to have insight as to whats going on with devices.

[Ylianst]

Matt mailed me asking to comment on this discussion, so I will throw in my quick thinking on this. I may be completely off base becaue not following this work as much as I should. Generally. I like NPM modules that have a well documented JavaScript API and that is it, they represent the ground floor of the module and provide the most flexibility for developers. When you start adding higher level glue like a specific bus type, etc. Your making decisions that a module integrator now has to live with.

With the projects I work on, I grab modules and glue them in my own specific way. The best API in my view is ones that encapsulates the domain of expertise but no more. This is why I had to drop GreenLock and use Acme-Client instead for Let's Encrypt support. GreenLock made too many assumptions about how the library was going to be integrated into a solution.

Totally ok with new modules that integrate an MQTT interface, but this should be an option, the baseline module should not. Of course, I consider all of MeshCentral to be a single MicroService with it's own DB and state. I would not consider an MPS server to be a MiroService on it's own.

[rsdmike]

Yup, I think same page this is a totally optional component -- that is off by default.