Plumbr now monitors the experience of each individual user

Plumbr has been known for our capability of exposing how different parts of your applications behave for end users. Additionally, Plumbr has been linking the root cause for poor performance to the impacted user interaction:

As of today, Plumbr is able to expose even more insights to end user experience. The latest version of Plumbr is now capable of capturing the identity of the user interacting with the application:

This change makes answering following questions a pleasure:

• How many daily/weekly/monthly active users do I have?
• What functionality does a particular user use the most?
• Which users were not satisfied with the performance during last week?
• Which bottlenecks in source code are currently affecting my users the most?
• Did the user really add the item in question to the shopping cart as he claims in the support ticket?

The early feedback from customers in the beta program has been overwhelming. This is what the CTO of Telema, an electronic data interchange company, told us:

If this sounds like an awesome level of transparency to have, go ahead and either upgrade your existing Plumbr installation or take us to a test run with the 14-day free trial.

If you are interested in how Plumbr is able to capture the user identity, bear with me a bit longer so I can walk you through the technical details.

Implementation of the solution

It all starts with distinguishing different users. This is done by the Plumbr Agent planting a cookie to the HTTP response sent back to the browser. The cookie is persisted by the browser and the subsequent requests from the same browser will be linked with the same cookie. From this the limitations of the user identity detection are also transparent – the users are identified only for browser-based web applications. Swing or EJB applications do not yet expose the users.

In any case, planting the cookie gets us only half-way, as we are still missing the identity of the user.

User identity is extracted from a specific HTTP session attribute. As Plumbr Agent is able to access the attributes added into the session context, all that the Agent needs is to know the location of the correct attribute to be used. To illustrate the concept, consider the following two examples:

• getSession().getAttribute(“USER”).getEmail()
• getSession().getAttribute(“SECURITY_PRINCIPAL”).getUserContext().getUsername()

Both examples retrieve the user identity from a HTTP Session attribute. In the first example the attribute is stored under the key “USER” and the email of the user is used to identify the user. The second example is retrieving the attribute with the key “SECURITY_PRINCIPAL” and fetching the username from UserContext to be used as the identifier.

By default, Plumbr supports two frameworks for identity capturing:

• Spring Security. If the application monitored by Plumbr is using the authentication built into the Spring Security library, Plumbr will extract the user’s identity from org.springframework.security.core.userdetails.UserDetails#getUsername()
• Java Authentication and Authorization Service (JAAS). If the application Plumbr is monitoring is storing the security.Principal instances in the HTTP Session then Plumbr will extract the identity from java.security.Principal#getName().

As a result of supporting these two frameworks, out-of-the-box Plumbr identifies users for roughly 45% of all applications. In case Plumbr does not detect the identity or you wish to change the identity attribute used, you can configure the location of the identity yourself.

If you made it this far in the post, you can surely find the three more minutes it takes to set up Plumbr yourself. Go and start the trial, attach the agent to your Java app and expose the real users in your applications.