Console support for event streams

[johanstokking]

Summary:

The console should support displaying real-time event streams.

All entities trigger events when they are created/updated/deleted:

• Applications
• Clients
• EndDevices
• Gateways
• Organizations
• Users
• API Keys and Collaborations of above entities

LoRaWAN traffic also triggers messages while being processed by the stack. This is specifically useful for debugging EndDevices.

Why do we need this?

The purpose of event streams is mostly to let users trace messages through the stack, typically for debugging. Users will go to a single entity page and navigate to the events section. The console will then display some historical events if available (history is not stored by default) and add events as they come in. Users will be able to inspect event details. Users will be able to filter events by event name, and some other fields.

What is already there? What do you see now?

We have the Events API (see api doc). The Events.Stream RPC is mapped to HTTP on a POST /api/v3/events (note the POST). The request contains the identifiers of entities (plural) that the caller is interested in. All event names are selected, and it is not (yet) possible to filter event names server-side. Matching events are streamed as newline-delimited JSON objects in the response.

NOTE: In the future we may add a websocket version of this endpoint, but for now we're only working with this.

We also have the ttn-lw-cli events command that subscribes to the events stream (over gRPC).

The Event message contains the following fields:

• name (string) of the event. An example is application.api-key.create. This name has a translation with key event:application.api-key.create.
• time (timestamp) of the event.
• identifiers one or more entity identifiers of entities related to the event (for example, an OAuth authorize event involves a user and an OAuth client)
• data (optional object) details of the event, can be different for each event type
• correlation_ids (list of strings) used for correlating this event to other events. In the future we may define an API for getting historical events by correlation ID, but that's currently not possible yet.
• origin (string) origin of the event (typically the hostname of the instance/container), so may not say much.

What is missing? What do you want to see?

• SDK support for setting up event streams
  • Note: Although a typical page focuses on a single entity, the API supports subscribing to multiple entities (for example, a gateway and an application), which could be very powerful.
• A re-usable component for displaying event streams
  • Keep some history on the client side
  • Filtering by name (after events are received)
  • Filtering by identifiers (after events are received)
  • Filtering by correlation_ids (after events are received)
• Section in the applications page to display messages related to the current application, see https://github.com/TheThingsIndustries/lorawan-stack/issues/1065
• Section in the gateways section to display messages related to the current gateway, see https://github.com/TheThingsIndustries/lorawan-stack/issues/1068
• Section in the end devices section to display messages related to the current end device, see https://github.com/TheThingsIndustries/lorawan-stack/issues/1067

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/1071 by @bafonins

[johanstokking]

For UX, it's going to be streaming in the browser, pretty much like with the V2 Console today. In terms of memory, I think it would be wise to have a maximum duration (maybe also count) or entries to keep in memory. When you start the stream, there may already be history available (either duration or count is selectable) if the server supports it.

For technicalities, see https://github.com/TheThingsIndustries/lorawan-stack/issues/1640

[bafonins]

I tried several approaches to implement in the console, however none of the seem to work.

Approaches:

1. Using native XMLHttpRequest as suggested here
2. Using fetch and process the response.body stream. Note, that support for streams in the browser is very limited in comarison to nodejs.
3. Using https://github.com/jimhigson/oboe.js

      oboe({
        url: '/api/v3/events/applications/admin-app',
        method: 'GET',
        headers: {
          Authorization: `Bearer ${tk}`,
        },
      })
        .node('!.result', function (result) {
          // message received
        }).done(function (things) {
          // stream done
        }).fail(function (error) {
          // error
        })

Note, that the POST endpoint wont work with oboe, see jimhigson/oboe.js#146
4. Using https://github.com/eBay/jsonpipe

Every request gets into the OPENED (see readyState 1 ) state and is simply pending (so the browser doesnt receive even the reponse headers). However, sometimes when you kill the server you can see buffered events being flushed to the browser.

[htdvisser]

This turns out to be caused by the Gzip middleware not flushing response chunks. I created a PR to fix this: labstack/echo#1317

@bafonins can you try what you did with gzip disabled (Accept-Encoding: identity)?

[bafonins]

Yes, I just verified that the problem is indeed with the gzip middleware. Commented this line.