Active observability

This is the suggested approach when what you want is to build a full Observability solution for your WebRTC application.

What you want to do is beyond collecting logs, metrics and traces for troubleshooting; getting to the realm of monitoring the whole deployment, finding issues before they are reported and predicting future trends of your service.

Here, you make use of the rtcstats open source project, integrating rtcstats.js to your client code and setting up your own instance(s) of rtcstats-server. Your main focus though isn't on the file storage of rtcstats-server but rather on the database.

Storyline

The storyline goes something like this:

1. You want to be able to measure and monitor every aspect of your service at scale. From a bird's eye view, drilling down to a single session
2. Get rtcstats-js integrated in your web client code, so it can collect WebRTC traces
3. Setup your own rtcstats-server. Be sure to setup JWT authorization and configure how to identify calls and sessions collected
4. Direct your rtcstats-js to send its data to your rtcstats-server
5. Learn the schema of rtcstats-server's database and enrich your own BI database with it
6. Also, periodically (usually every few days), remove older rtcstats files to keep your storage costs at bay

This lets you do the ad-hoc debugging and troubleshooting TBD:LINK listed in another approach. At the same time, it offers the ability to query the database across multiple WebRTC related features to gain insights on your deployment. Here, you can use the sample queries we have in rtcstats-server or create your own.

NOTE:

• All of the above can be done using open source and a free rtcstats.com account
• We offer several support plans for the open source project. If you are interested to learn more, reach out to us
• On one of our paid plans, you will also have Observations and AI summaries, which will reduce your time to get to the root cause drastically. If you are interested in trialing these features, do let us know

Reasoning

Let's review quickly what are the advantages and challenges of this approach:

Advantages

• Easily troubleshoot and debug ANY session of ANY user in your application
• No more need to go back to users asking them to generate and send webrtc-internals files
• The SQL database created here is used for BI and monitoring purposes. You can proactively query it to understand trends and behaviors in your deployment
• No need to pay us anything (unless you want to - we won't complain)

Challenges

• Requires more engineering and DevOps effort to get started

Alernative routes

Here, there are a few different ways to get this integration in place.

Check the routes suggested in the ad-hoc debugging and troubleshooting TBD:LINK section as well

For higher resolution of information in your Observability system, you can automatically upload using the API any or all of the sessions collected by rtcstats-server to rtcstats.com.

This approach will add the Observations generated by rtcstats.com to your BI database, enabling finer granularity of insights and querying. Alternatively, you can decide to do that only to select session: from specific users, certain locations, based on specific extracted features, etc.

The more analysis you glean out of sessions the finer and more nuanced the details you will be able to extract out of your deployment. It is up to you to decide which level of granularity you need.

Our suggestion

For WebRTC applications in production with more than 100,000 sessions a month, this should be the approach to take.

It gives you complete visibility into your users base and can be used to troubleshoot any issue, while also providing you a good grasp of your deployment as a whole.