Although it might seem daunting, as we’ve seen in this series, manual instrumentation can be straightforward and a powerful tool in a complete observability practice. In this series, we dig into manual instrumentation to see how we can use it to easily build out observability from scratch. In our first post, Manual Instrumentation with Splunk Observability Cloud: The What and Why, we learned about what manual instrumentation is and why you need it. Our second post went through the process of manually instrumenting the backend of a real, un-instrumented full-stack application, commit by commit. In this post, we will look at our un-instrumented frontend and go step-by-step through the process of manually instrumenting it.
Example Application Overview Recap
GitHub repository: https://github.com/splunk/evangelism-public/tree/main/manual-instrumentation
To review, our example application is called Worms in Space. It consists of a React frontend with an Elixir backend and provides a full GraphQL API. Worms in Space allows customers (who happen to be worms) to schedule spacewalks in… space.
Space worms can use the UI or GraphQL API to:
- View available time slots
- Schedule space walks during predefined or custom time slots
- View all scheduled space walks
- Cancel space walks
Here’s what the frontend UI looks like:
And here you can interact with the GraphQL API via GraphiQL:
If you'd like to follow along on GitHub commit-by-commit, check out the GitHub repository, otherwise, you can read on to follow each commit here.
Why Splunk RUM for Frontend Instrumentation?
Splunk RUM (Real User Monitoring) within Splunk Observability Cloud is designed to monitor the performance and user experience of web and mobile applications from the perspective of actual end-users. It collects data directly from the user's browser or mobile device, and provides insights into how real users interact with and experience your application for complete visibility.
When instrumenting a frontend application, it’s important to work with a solution that provides:
- Support for multiple browsers and mobile applications
- Complete instrumentation of full user sessions without degrading performance or user experience
- Out-of-the-box, real-time metrics, dashboards, and charts around performance, user interactions, user sessions, and page loads
- AI-driven analytics to identify performance improvements across every page, resource, component, and third-party dependency
Splunk RUM gives us all these things and more – plus it can be implemented in just a few commits. Let’s dig into the implementation.
Frontend Instrumentation with Splunk RUM
Step 1: Add Splunk RUM Dependency
Git commit: 9d23d770
For full documentation on the Splunk RUM installation process, check out the installation docs. We’re going to install Splunk RUM via NPM, so the first thing we need to do within our frontend application is add the Splunk RUM dependency to our package.json file:
@splunk/otel-web is the Splunk Distribution of OpenTelemetry for JavaScript and abstracts away many of the underlying OpenTelemetry and Splunk-specific details.
Step 2: Configure Splunk RUM
Git commit: e0caea8a
Next, since our application uses Typescript, we’ll configure Splunk RUM in a assets/js/rum.ts file:
This configuration sets the:
- realm: Your Splunk Observability Cloud realm (us0, us1, eu0, etc.). You can find your realm in your Splunk Observability Cloud organization settings. The SDK automatically constructs the correct ingest endpoint from the realm.
- rumAccessToken: Your RUM access token. This is different from APM tokens and has limited, frontend-safe permissions. You can generate a RUM access token by navigating to Settings → Access Tokens in Splunk Observability Cloud.
- applicationName: Your application name as it will appear in RUM dashboards. Choose something descriptive that distinguishes this frontend from other services.
- deploymentEnvironment: Deployment environment (development, staging, production). This enables filtering in RUM views.
Security note: RUM tokens are designed to be exposed in frontend code. They only have permission to send RUM data and cannot access other Splunk Observability Cloud resources.
Step 3: Initialize Splunk RUM in React Application Entry Point
Git commit: d65649fe
We initialize RUM in our application entry point in our assets/js/app.tsx before React starts. You’ll want to do this as early as possible in the application source:
The installation documentation states to import or require the splunk-instrumentation.js file, or in our case, our assets/js/app.tsx file, before other files to ensure that the instrumentation runs before the application code.
With this single initialization, Splunk RUM will now automatically instrument:
- Performance Metrics
- Network Activity
- User Interactions
- JavaScript Errors
For a complete list of data collected by the RUM Browser agent, check out the RUM Browser data model docs.
Step 4: Add Custom Instrumentation for Business Logic
Git commit: ffaec857
While automatic instrumentation covers browser metrics, we add in our manual instrumentation with custom spans to track business-critical operations that are unique to our application. In this example, this critical operation is actually scheduling a spacewalk:
This is just a snippet from our AstronautTimeSlots.tsx file. For the complete implementation, including custom spans for delete operations, and delete operations, see the full source code on GitHub.
These custom spans appear in RUM traces alongside automatic instrumentation, providing complete visibility into user workflows. See custom instrumentation documentation for more patterns.
Let’s now see what this manual instrumentation looks like in Splunk Observability Cloud.
What You'll See in Splunk Observability Cloud
With this instrumentation in place in just three commits, we immediately gain visibility into:
- Key performance metrics like: user sessions, page views, JavaScript errors, and core web vitals
- Browser and device analytics: device type breakdown and performance comparison
- Detailed session breakdowns showing individual user journeys with timelines, waterfall views, errors, and replays
- End-to-end trace views showing frontend and backend correlation
- Out-of-the-box and customizable dashboards, and alerts
Now that our application is instrumented, we can go into Splunk Observability Cloud, navigate to Splunk RUM to see that our worms-in-space-frontend application is now sending RUM data:
Here we can quickly see those key performance networks like page views, JavaScript errors, and web vitals.
If we click into our worms-in-space-frontend from this view we can see a more detailed, filterable view of page views, page loads, and interactions:
And then selecting the specific interaction, we can go into the waterfall view to see the detailed trace breakdown of user interactions and network requests:
In this waterfall breakdown, we can see custom spans that we manually instrumented like our delete_scheduled_walk. We can select this span to explore a more detailed view with the complete span tags that we manually added in our AstronautTimeSlots.tsx file:
Manual instrumentation success via Splunk RUM 🎉.
Wrap Up
In just three commits, we've transformed our un-instrumented React frontend into a fully observable service with Splunk RUM. The combination of automatic instrumentation provided out-of-the-box and the manual instrumentation we added for our specific business logic provides complete visibility into our frontend application performance. This level of observability transforms mysterious production issues into clearly diagnosed problems with obvious solutions so space worms can seamlessly schedule and reschedule their spacewalks at any time.
Join us in our next post to follow along, step-by-step, as we update our Worms in Space application to use the OpenTelemetry Collector.
Ready to manually instrument your own frontend? Start with Splunk Real User Monitoring, and use Splunk Observability Cloud's 14-day free trial to easily visualize your telemetry data in one unified platform.
Resources
