Included with all LiveKit Cloud projects is "LiveKit Data"—our real-time analytics and telemetry service—which assimilates and integrates data reported by clients and servers into a set of dashboards and visualizations. The goal behind surfacing this information is to give you, the application developer, a clear understanding of what your users experience when they use your application without having to be in a room with them or looking over their shoulders.
One of the tricky parts with designing an observability stack for general-purpose infrastructure is choosing the appropriate information hierarchy and interface. Different use cases may want to surface different data or visualize it in a certain form or sequence. We're continuing to iterate and think about how to adapt LiveKit Data to specific types of applications. Check back often for updates!
LiveKit Data splits analytics data into three specific views:
The project view is the top-level view for your project. It's the default view when you click on the Dashboard sidebar menu item. This view displays the number of active rooms, rooms with participants currently connected to them, the total number of participants connected to your Cloud instance across all rooms ("active participants") and the total bandwidth your project has cumulatively transmitted (the greater of upstream or downstream data transfer).
An aggregated plot of active participants over the past two weeks is also shown in this view, along with a chronologically sorted list of currently active sessions and completed sessions.
Room vs Session
In LiveKit, a
Room is the container construct that houses participants. By default, a room is active/exists when there is one or more participants connected to it; when all participants disconnect, the associated room enters a closed state. While each room is unique, dictated by its
name field, the same room may be active multiple times over a given time period. In order to delineate this in analytics, we've introduced the concept of a session. A session represents an individual instance of an active room (i.e. a room with a specific name being occupied by one or more participants). A completed or finished session is a room which was active for some period of time but subsequently closed.
The Name field for a room is developer-specified, while the Session Id (i.e. RM_aBc123) is generated by LiveKit.
The session view lets you drill into room-specific metrics like the number of total participants that are or were (in the case of finished sessions) connected to a room, the average audio and video quality score aggregated across all participants, and the total bandwidth used. For rooms that have multiple sessions over time, there's an aggregate view of active participants over time. This is useful for spatial/metaverse applications which typically model rooms as persistent "spaces".
This view also contains a list of all participants that joined the session and a log of all LiveKit room events.
The participant view is where things get really interesting! For every participant in a room, LiveKit displays information about the client they're connecting with, their connection stats, and real-time data for the tracks they publish and receive.
So you may be thinking: wait, so a participant has multiple sessions, too? This is admittedly a bit confusing, but there's a simple explanation. Similar to how a room can be open and closed multiple times over a time period, a participant may connect and disconnect (both intentionally and unintentionally) from said room, while it's open, multiple times over a time period. Thus, we model this as a "participant session". In analytics, we'll aggregate all of a participant's sessions together and organize them into a timeline. You can easily switch between sessions and drill into telemetry collected over the duration of that session:
The Identity field for a participant is developer-specified, while the Session Id (i.e. PA_aBc123) is generated by LiveKit.
While track data is collected across the duration of an entire session, only a certain interval may be initially shown. You can use the "zoom window" tool to scale up, down, or shift the time window for the participant's published or subscribed tracks.
An important thing to note for graphs is, while thee data being plotted appears to be continuous, it is actually discrete. Our analytics system records event data every ten seconds and your dashboard renders this data in 30-second intervals. Understanding this will help contextualize annotations and their timestamps that may appear on a chart, providing additional information when client or system events occur.