Skip to main content


Article

How to get the most from Real User Monitoring

By Collin Chau

Real user monitoring, or RUM, is by no means a new idea. For years, developers and operations teams have been deploying RUM tools to collect basic performance data about websites and other applications. RUM systems run JavaScript in user browsers to collect actual performance statistics from real users of the app.

Like many other cornerstones of development, however, the RUM workflows that worked in the era of Web 1.0 no longer suffice today. Applications have evolved significantly as businesses have transitioned to cloud-native environments driven by fast-moving continuous integration/continuous delivery (CI/CD) pipelines. Preventing new releases from leading to degradations in application performance is a critical priority for teams that are pushing out multiple builds each day, or even each week.

At the same time, customer journeys have grown more complex; instead of loading just a handful of static pages, a customer today might navigate through a complicated web of dynamically generated content that is tailored to his or her profile and priorities. Given this diversity in use cases, monitoring only some customers’ activities is no longer enough to provide optimal performance for all customers. You need to track all users to catch the performance problems that may arise.

All of the above means that it’s time to rethink the approach your team takes to real user monitoring. Not only do toolsets need to evolve, but philosophies and workflows also must change in order to meet the monitoring and performance optimization needs of modern software environments.

The what and why of RUM

As seasoned developers know, RUM, which focuses on collecting and analyzing data from real-world transactions within a software environment, is one of the core pillars of application performance optimization.

Because RUM leverages data from actual users, it delivers insights that other types of monitoring strategies — such as synthetic monitoring, which uses data from simulated transactions — cannot deliver reliably on their own. Synthetic monitoring is useful for testing new application releases prior to deployment into production based on simulated transactions. Once the application is deployed, RUM helps developers measure performance on the basis of actual user interactions. This way, developers can understand the performance pitfalls that impact their actual users.

The challenges of RUM

Measuring simple metrics, like the loading time for individual pages, might have sufficed in an era when developers were managing single-page applications and all users were viewing the same content.

In today’s world, however, applications are too complex to be monitored effectively using only simplistic, page-level metrics. Instead, teams need to track the responsiveness of all of the components of their applications. They must measure performance not just at the page level, but at the level of each item that is part of each page. They must also be able to map responsiveness issues in individual components to backend services that cause delays. Further complicating this is that different users requesting the same page may call different backend services due to the dynamic nature of modern applications. Simply knowing that one part of your web page or app is not responding to requests quickly is hardly enough to enable effective remediation or to deliver the best possible experience to every user.

Traditional RUM also does a poor job of helping developers understand the relationship between application problems and backend code changes — especially in a fast-moving CI/CD pipeline where code is updated constantly. If your monitoring tools tell you only what is happening on the frontend, without being able to correlate frontend spans with backend traces, you are shooting in the dark when it comes time to find the bad backend code that leads to a bad user experience.

A lack of correlation between RUM data and other sources of visibility may be a limitation, too. To gain complete visibility into your environment and make data as actionable as possible, you need to combine data about real user transactions with synthetic monitoring data, log analytics, application performance metrics and any other information you can collect in order to contextualize and make sense of the issues exposed by RUM.

Getting more out of RUM

Businesses that seek to leverage the greatest value from RUM tools and to deliver the best customer experience can take several steps to avoid the pitfalls described above and build a RUM strategy that aligns with the needs of modern, cloud-native applications.

Trace every part of every transaction

One basic step toward RUM optimization is to collect transaction data from both the application frontend and backend, then correlate and analyze that data automatically.

Traditional RUM solutions don’t do this. They provide full ingestion only for frontend transactions and rely on a sampled approach for backend transactions. They also force developers to correlate frontend spans and backend traces manually, making it hard to identify meaningful patterns.

By analyzing every part of every transaction and correlating frontend with backend data, developers gain end-to-end visibility into user activity, rather than the incomplete insight that partial data tracing provides.

Full-fidelity data ingest and real-time analytics

End-to-end transaction tracing is only useful if you can also interpret transaction data quickly. The huge volume of data created from this level of tracing means you need real-time streaming analytics powered by AI and machine learning to make sense of the firehose.

Streaming analytics that parse all transaction data help developers understand complex relationships within the data, such as how a backend provided by a third-party service impacts frontend browser performance.

In addition, by configuring alerts based on real-time data analytics streams, developers can identify and react to problems quickly. RUM becomes a path for real-time problem resolution, rather than only supporting retrospective analysis.

Map problems to your runtime architecture

Similarly, being able to trace surface-level problems to the individual services that cause them is critical, especially in modern, highly distributed, microservices-based environments. To do this, you need to be able to trace transactions from the application frontend where they originate through the various backend (and potentially third-party) services that handle them. Your RUM tools must be able to determine how the frontend service passes the request to other services and how data is processed as it flows through your runtime environment.

This is important not just for identifying how performance trends map to application code, but also for helping developers understand how seemingly different issues are related to each other. When developers can establish the relationship between multiple trends, they are in a stronger position to know which changes to prioritize and even which application release candidates to deploy or (if necessary) roll back. Without this deep visibility into how performance relates to the application architecture and code, teams can only understand each pattern in isolation, which makes it difficult to keep CI/CD operations running smoothly.

Here again, simplistic metrics like overall page load time are hardly enough to deliver the type of actionable observability that teams require to solve issues before they become critically disruptive to customers. They provide only high-level, monolithic insight into application performance.

Leverage open standards

Developers don’t want to be locked into one vendor’s RUM tooling or instrumentation or learn complicated proprietary instrumentation frameworks.

Instead, they want to use an open instrumentation solution that unlocks their application data for measurement via the RUM tooling of their choice.

Developers can achieve this by building their RUM strategy around tools that instrument data ingestion based on frameworks like OpenTelemetry, which provides open, community-defined standards for data collection. An open approach assures that your instrumentation will work with any standards-compatible RUM tool you choose to deploy and eliminates the need for your development team to build bespoke instrumentation within your applications, which is a tedious and complex task.

Conclusion

RUM remains a crucial part of any observability strategy. However, RUM solutions that expose only basic metrics (like single-page page load time) fall far short of delivering the type of actionable visibility that teams require in today’s complex, cloud-native world. Take your RUM strategy to the next level by leveraging tools like Splunk RUM, which provides full-fidelity, end-to-end visibility by tracing all user transactions.

Part of the Splunk Observability Cloud, it is now easier to contextualize RUM data with visibility insights across your complex system, for a customer-centric approach to identify and respond to any issues that might impact your end user’s engagement with your website or application - watch this demo to learn more before you start your free trial.

When it comes to monitoring the digital experience for your end users, there are different types of monitoring. It’s important to know the benefits associated with each, to choose the one that best meets your business needs today. Download this whitepaper to help you make sense of Digital Experience Monitoring that empowers your businesses to translate real user data into real-world customer experience optimizations.

Alt

Guide

SRE and the Four Golden Signals of Monitoring

Learn More
Alt

Guide

Faster, Smarter Resolution: The Incident Response Guide for Kubernetes

Read Now
Alt

Guide

Why DevOps Matters: A Guide for Collaborative Transparency in Incident Management

Learn More
Get started with a free trial of Splunk Observability Cloud today.