Request Metrics Documentation
Request Metrics is quickly evolving and rapidly adding new features. If something is unclear or you have questions please email us.
Table of Contents
async attribute to prevent render blocking.
Installing From the CDN
The easiest way to get started is by including the script from our hosted CDN. We use the same CDN service that hosts jQuery, so it should be reliable and fast. However, you may also feel free to pull the agent script and host/bundle it yourself if you're extra paranoid (we don't blame you).
Note: Be sure to include your application's token in a
data-rm-token attribute. When the agent initializes itself it will find the token and you're off to the races.
If for some reason you'd prefer to tell Request Metrics when to initialize, you can do that too.
Installing from NPM
It's common to have URLs with ID numbers or GUIDs in the segments. Consider:
It would be nice if those two URLs were grouped together inside of Request Metrics so that we could aggregate the performance across them. They are almost certainly running the same code, so we've devised a few options to help roll them up.
Automatic Segment Grouping
If we encounter a URL path segment that "looks" like an ID, we will automatically group all urls with that segment together. From our example above, those two URLs would both be grouped as:
We run a number of regular expressions against each URL segment to determine whether we think it's an ID. Anything with 2 or more numbers, or that looks like any common form of UUID, will automatically be grouped. We use the preceding segment to determine the grouping name. This mostly works for simple URL schemes but of course the real world is more complicated!
Manual URL Grouping Rules
It's impossible for us to automatically group every possible URL in a way that meaningfully reflects the application. So we've built out a suite of tools to create "URL grouping rules". Consider:
In these URLs there are multiple subdomains involved, multiple API versions, and the product IDs are custom to the application. We would still like to group the subdomains together, the API versions (they are all 1.x) and the product IDs. With our URL grouping rules you can group these like so:
You can also create conditional groupings. This way the rule will only apply if the subdomain or path segment matches certain criteria (subdomain contains "us-east" for example).
How can I Make My Own Rules?
We are still figuring out how best to expose the URL grouping rules UI to our customers. If you have URLs you'd like grouped, please send an email to firstname.lastname@example.org and let us know! We're very responsive and will be able to walk through your options. Once we've refined the UI based on customer use cases we'll release it for everyone to use.
If you have additional URLs you want ignored, please reach out to us and let us know. Over time we will fine-tune the global ignore list and allow custom ignore rules that you can create yourself.
Do You Store Any User Identifying Information?
Nope. We believe in end-user privacy. We do not track or store any personally indentifiable information. In addition, we do not sell your information to anyone, ever.
How Do You Calculate Distinct User Counts Then?
We create a hash of the user agent string and IP address and apply it to a HyperLogLog data structure. At no time is the user agent or IP address persisted. Due to the way HyperLogLog works, larger user counts are close estimates as opposed to exact.
Can Request Metrics Monitor Service Workers Too?
Yes! The agent will work inside a service worker context and monitor performance of AJAX endpoints.
I Have Other Questions, How Can You Be Contacted?
Please email us at email@example.com for any questions, comments, complaints or philosophical software development discussions. Our entire engineering team monitors that inbox so you will get a reply sooner than later.
Request metrics is rapidly iterating on new features. Here's some of the things we're working on. We also take customer feedback in to account. If there's a feature you want sooner, or something not on this list, let us know!
Custom URL Grouping Rules
We have an internal-only admin UI to build custom URL grouping rules right now. It works well for the use-cases we've seen so far. We will be releasing it to end-users once we're confident it's understandable and solves the majority of URL grouping scenarios.
Custom Ignore Rules
Much like URL grouping rules, we want to get a sense of the URLs customers want to ignore before we expose a UI. The capabilities exist in the system but are currently "admin only" at the moment. Contact us if you need custom ignore rules!
Better Time Range Comparisons
Tracking performance over time is important. We want to offer some better comparison tools and a weekly summary that shows this week's traffic compared to last week's.
User Geographic Location
We plan to start capturing the rough geographic location of users. This will most likely be based on IP lookup. As with distinct user counting we will only store the anonymized data set.
Most modern browsers are fast, but knowing whether it's Firefox or Chrome or Edge can still be an interesting signal. We plan to start capturing macro browser statistics.
We want to add new kinds of alerts (maybe when a page goes from "OK" to "Slow", for example) and perhaps offer some kind of uptime checking.
An NPM package will be coming sooner than later so you can integrate the Request Metrics agent into your front-end build process.