Your homegrown getStats() collector is already out of date

You wrote a getStats() collector. It polls every peer connection, sends the metrics you want (filtered or all of them) to your backend and feeds a dashboard. It worked the week you shipped it.

The question is whether it still collects what you think it collects, and whether it will still be useful a year or two (or three) down the road. Since 2021 Chrome removed isRemote, the mediaType alias and the whole track object, and made the callback getStats() throw, so a collector nobody updated is reading fields that no longer exist.

Why a homegrown getStats() collector falls behind

The hard part of building your own WebRTC monitoring is focus. Or should we say maintenance. A good friend of mine once told me that code tends to rot just like any other organic matter. You leave it alone, and it becomes stale. This is true for observability-related code as well.

There's friction here: Observability matters to your company, but it is never the main show.

You build it out of necessity, and nobody on the team earns a living by knowing getStats() inside out. So it gets built once, and then someone tweaks it every few months. Maybe.

Nobody follows the changes in the metrics: new stats that appear, older ones that get decommissioned, fields that move from one object to another. The collector keeps running, the dashboards keep drawing lines, and nothing tells you that a line went flat because the field it reads no longer exists. You end up reactive. You fix things after they break, and only once the breakage has shown up often enough for someone to file a ticket.

A team that does this for a living works the other way around: whatever you are about to bump into, there is a good chance someone already looked at it.

Who keeps the rtcStats collector current

Since 2019, Philipp authored 59 of the 198 libWebRTC stats commits my AI agent could identify by their subject line: the most of any author, with a Google engineer one behind.

When a stat changes in Chrome, there is a good chance he is the one changing it. And if not, you can be sure he knows about it before anyone in your engineering team does. The rtcStats collector follows from there.

Here's the funny thing: collecting all that is open source. rtcstats-js gives you that today. For free. In an easy-to-integrate package. Along with a straightforward collection server that is also free and open source.

And the code itself is extensible, so you can cram your own events and metrics in there as well.

Why would you want to write and maintain that code on your own?

When building your own collector is the right call

Sometimes building is the right call. If the stats are your product, build it. If you have some compelling reason to collect only a select few metrics and not everything, then build your own collector. rtcStats is greedy in that sense: it collects everything it finds that might interest someone. Why you'd want to collect less is a different question, one I can't really find a good answer to, though that doesn't mean there isn't one.

If you need to own your WebRTC observability data, you do not need to build it yourself. rtcStats has you covered already, with free and open source code.

If you need to enrich sessions with your own application data, you do not need to build for that. You can enrich sessions on top of the open source collector.

If you build, build on the rtcStats open source

The WebRTC metrics collection layer is the part nobody on your team will own long term. So don't start from an empty getStats() loop. Start from the rtcstats-js and rtcstats-server packages in the rtcStats monorepo. They are open source, they run in your own infrastructure, the raw data stays yours, and forwarding anything to us is off by default. Keep your pipeline, your storage and your dashboards. Swap the collection layer for one maintained by people who track these changes for a living.

Analysis is harder to justify building: turning thousands of metrics into Observations, Deductions and an Experience Score. The middle path is to self-host the collection and send a selected slice of sessions for analysis. You own the raw data outright and pay for the answer only where an answer is worth paying for. That layer keeps getting better without costing you development cycles.

I laid out the full trade in rtcStats vs building it yourself, and the architecture of a DIY setup on our components in an earlier post.

Start at https://github.com/rtcstats/rtcstats