Allow hook for LiveDashboard historical data at client connection

Telemetry poller is not saving any events. It periodically triggers the emission of certain telemetry events, which are not triggered by explicit actions, like e.g. current memory usage.

One thing I did when testing the charting was just hit the endpoint with a load testing tool. This will quickly bring stress to your system and fill up your metrics cache. The complexity here lies in the details. Events might be quite big (which is not a problem for just dispatching, but might when kept around). Short bursts to the system will fill up any timebased solution to extends maybe not accounted. Generally keeping much data around in memory can be problematic (see the topic on tz_world here on the forum), you don’t want to bring an application to crash for OOM reasons. Then there’s – as correctly noted - the problem of many metrics for the same base event.

I guess Jose’s point is that those are best solved first before thinking about best hooking the result into live_dashboard.

1 Like

Yes, this seems fair and relevant, but like its one of the reasons we’re doing this as a hook where each user can decide exactly which pieces of history they keep around for how long based on their particular event size and frequency… in my example, I’m not keeping history for all metrics, just for some custom ones in a specific namespace/ “event_name”. I guess I’m not sure how general or broad to make the examples, or whether perhaps to make a few examples highlighting these tradeoffs etc? But thanks for the idea of loadtesting, that seems useful, did you use anything that’s an easy reference for me to leverage or just some one-off code you threw away?

I just used an of the shelf cli tool:

Thanks! I see the tz_world discussion here Tz_world / timezone_boundary_builder update

I wonder if maybe should just have a second example that pulls/pushes history from/into Redis or Postgres or something as an alternative for where keeping this data in memory is a concern, but would also like to understand/cover José’s concerns about when to possibly not resend some events and/or when reflecting on tags or other metric metadata may impact the response, so anyone using those who can help me test out the implementation in real world condition, hope to hear from you!