WebRTC Monitoring: Do you Monitor your Servers or Your Service?

WebRTC monitoring the right way.

When we started out developing testRTC, what we had in mind is a service that helps QA people test their service prior to heading to production. We've built a sleek webapp that enables us to simulate virtually any type of a WebRTC use case. Testers can then just specify or record their script and from there run it and scale it in their tests using testRTC. What we quickly found out was that some were looking for a solution that helps them monitor their service as opposed to manually (or even automatically and continuously) testing their latest build. The request we got was something like this: "can you make this test we just defined run periodically? Every few minutes maybe? Oh - and if something goes awfully wrong - can you send me an alert about it?" What some realized before we did was that the tests they were defining can easily be used to monitor their production service. There reasoning behind this request is that there's no easy way to run an end-to-end monitor on a WebRTC service. The alternatives we've seen out there?

• Pray that it works, and wait for a user to complain
• Using Pingdom to check that the domain is up and running and that the server is alive
• Using New Relic or its poor man's alternative - Nagios - to handle application monitoring. It boils down to testing that the servers are up and running, CPU and memory load look reasonable and maybe a bit of your server's metrics

But does that mean the service is up and running, or just that the machines and maybe even processes are there? In many cases, what IT people are really looking to monitor is the service itself - they want to make sure that if a call is made via WebRTC - it actually gets through - and media is sent and received - with a certain expected quality. And that's where most monitoring tools break down and fail to deliver. This is why a few weeks ago, we've decided to add WebRTC monitoring capabilities to testRTC. As a user, you can set it up by defining a test case, indicate from where in the world you want it to run, define the intervals to run it along with thresholds on quality. And that's it. What you'll get is a continuously running test that will know when to alert you on issues AND collect all of the reports. For all calls. The bad ones and the good ones. So you can drill down in post mortem to see what went wrong and why. If you need something like this, contact us on testRTC - the team would love to show you around our tool and set you up with a WebRTC monitor of your own.