The Google Meet integration’s target audience is workspace IT admins and DevEx members. If users set up the Google Meet authentication, then they are just one API call away from accessing other Google product APIs. The two APIs below are shared among Google products and target Meet through a query parameter.
The first API, CustomerUsageReport, gives a metric summary of the previous days; for example: number of calls, lonely meetings, and average_meeting_minutes. If I ran this API today, I could only get a summary report for two days prior to today. The data is too old to put into Datadog retroactively as a metric, as well already aggregated, so this API was skipped.
The second API, Audit Activity, retrieves a list of events that happened within a date time filter. Some event types include leaving a call, creating an abuse report, starting/stopping a presentation, and starting/stopping a poll. From my testing, the API took about 15 minutes to show up in the API after I left a Google Meet call. Because the data is near real-time and granular enough on a participant/meeting level, this API makes sense to flow into Datadog. However, the format of the data is still event-based, so I had to pivot the response in order for the data to make sense in a Datadog metric.
Using an example: If I left the call at 13:19:15, and my integration is polling, at around 13:34:15 the Audit Activity API will say I left the call at 13:19:15. In that event payload, Google reports metrics like what my (audio/video) (received/sent) packet loss (max/mean), seconds where audio was sent, what device type I used, and where my location was (just to name a few). For each string-like value (device_type, location), I appended to a list of tags. For each numerical value like packet loss and seconds where audio was sent, I send Datadog a metric. The timestamp of the metric will be the time the Datadog aggregator sent the metric to Datadog HQ, so around 13:34:15.
The image above omitted many of the other metrics that are given for each call_ended event, but illustrate the pivoting nonetheless. In addition to the 3 metrics being sent (as shown in red), one event is also sent to denote this caller leaving a call. This event is what powers the demographic breakdowns seen in the dashboard screenshot later on.
With powerful metrics like network latency, audio and video packet loss, and network jitter, network admins of workspaces now have the data available to start looking at Google Meet as a whole. Is the whole product suffering from a degraded service or is it just a few participants suffering from latency? Is it the user sending fewer packets or the user receiving too few? In development operations, soft-rules like no-meeting Wednesdays were created to prevent too much context switching on developers. With the Google Meet Datadog dashboard, managers can see when meetings are most often scheduled, how long they last, and who is often in meetings.
Limitations of the Audit Activity API include its event based architecture, making metrics over time based visualizations difficult. Events of a call_ended plotted over time is available, but to see how a user’s network latency has changed over the duration of a meeting is not, as the API reports an aggregated median/mean/max at the time of the participant leaving the call.
Future work from this integration includes the whole suite of Google Products and their APIs. Some Ideas we have in the future are:
Interested in trialing the integration? Check it out in the Datadog Marketplace!
This isn't the integration you're looking for? Missing a critical feature for your organization? Drop RapDev a note at support@rapdev.io and we'll build it!