Improving the service detection

There are known cases where out-of-the-box Plumbr configuration ends up with either services exposed via cryptic names. As a result you would see services similar to the following in Plumbr UI:

Key pressed on “div > list > filter > input#filter” at /user/search

This happens in situations where no human-readable elements were present to use as the identifier on the input field where the user performed the event. As a result of this, Plumbr used a fallback and exposed the DOM tree branch the event took place at. To replace this with a human-readable version, use “aria-label” attribute on such elements, so instead of

<input type="text"/>

you would use

<input type="text" aria-label="Name"/>

After this change, the name of the service will change to Key pressed on “Name” at /user/search for Plumbr. As a side effect, blind people also now have better access to the content of your site, as this is what the aria-label element was originally designed for.

Detecting a service from an URL

Let us explain this approach using a transaction arriving at the following URL as an example:

http://www.example.com/shop/cart/add/iPhone6?quantity=5

As a first step parameters are stripped. Next, service detection parses the URL to use /shop/cart/add/iPhone6 as the input. As seen, the last token identifying the product added to the shopping cart (iPhone6) is actually a parameter of the service. In order to group all interactions adding items to the shopping cart under the same service, Plumbr replaces the iPhone6 token in the URL with the placeholder {1}. As a result, the service detected from the transaction is

/shop/cart/add/{1}.

Using this approach makes it possible to group transactions accessing the same /shop/cart/add service together, regardless of the product you added to the shopping cart.

Certain limitations apply to which tokens can be automatically replaced by a placeholder: by default only tokens containing non-alphabetical characters are replaced.

If an application being monitored contains path parameters consisting only of alphabetical characters, then such services won’t be correctly grouped, i.e., there will be more services reported that is expected. If an application being monitored uses approach where there is only root path ( / ) and services are encoded using request parameters (either using ? or # as a separator), then the services will be grouped too eagerly under one root “/” service. For example both following URLs

/#tab=shoppingcart
/#tab=checkout

will be detected as one root service: “/”

To solve this, it is advised to use custom service grouping (accessible via Settings > Service Grouping Rules). There are two types of grouping rules – prefix based and regular expression based. Prefix matcher is the simplest and it will replace all URLs matching the defined prefix with the desired service name. Regular expression grouping rules are much more powerful, they allow matching request parameters and using groups with back-referencing to construct service names. This allows to overcome limitations of the default URL service detection. For our particular example we could define following regex grouping rule:

Matching pattern:

/#tab=(.*)

Service name pattern:

\1

Will result in two detected services:
shoppingcart
checkout