New Feature: Manage Your session.id in Honeycomb’s Web SDK

The session.id field is special in Honeycomb for Frontend Observability. It’s a default option for filtering and grouping, and it’s the basis for session timeline analysis (in Early Access). Now you can control how session.id is set.

In prior releases (< 0.15.0) of the Honeycomb Web SDK, we used our own UUID generator for session.id, and it was not accessible outside of the Web SDK itself. As of version 0.15.0, we give you full control. Here are the relevant changes:

• We use the upstream OpenTelemetry Random ID generator by default for our own generator, on pageload.
• We expose the session factory as an SDK configuration property, so that your engineers can determine how and when to set/expire your frontend’s session.id.

This is backwards-compatible with the current mechanism: if you don’t need to set the session.id yourself, do nothing and it will still be generated by the OpenTelemetry generator. 

How to generate your own session.id

There are a number of cases where you need control over your session generation:

• The session.id is generated by a server
• The session lasts longer than a pageview
• session.id is correlated to some sort of server-side session
• session.id needs to be stored, added to links, or displayed somewhere
• You want to send session.id as baggage to other spans downstream so that your tracing infrastructure can use it without querying the frontend spans

For example, while the HoneycombWebSDK creates the session id for each new tab by default, it’s not accessible to the application. One of our demo applications, based on the OpenTelemetry Demo Telescope Store, now generates its own session.id and stores it in the browser’s sessionStorage. We use this to display its application-generated session.id, so we can show two different “users” running sessions to our backend from one browser. 

Here’s how we do this: first, we configure the sessionProvider HoneycombWebSDK property, which allows us to set the session id by implementing a getSessionId method:

const sdk = new HoneycombWebSDK({
   // rest of config here
  sessionProvider: {
    getSessionId: () => {
      return SessionGateway.getSession();
    }
  }
});

The getSessionId method is called every time a batch of telemetry is sent to Honeycomb (or your Collector), so you can change the session.id whenever it makes sense to do so.

Now we can refer to the session.id in the frontend application with the same SessionGateway.getSession() method. We use it in the footer of our application so we can demonstrate our session timeline view.

Expiring sessions

Are you logging out? You want the session to end, so wherever you’re storing it, just remove it.

In our sessionStorage sample above, we can do this:

sessionStorage.removeItem('session.id')

Cases where this may be desired:

• A user goes from anonymous / not logged in to logged in
• A user logs out
• A browser times out the user session and logs them out automatically
• Your user “assumes a new role / user”

Once you send another span, your logic can create a new session.id.

Seeing the session.id in Honeycomb

You can view your session.id in a query, just group, filter, or use a visualization. Here is an example in the Web Launchpad, grouping by session.id.

Here is a query of our production Honeycomb service, exploring the duration of http.url calls by session:

It visualizes the total duration by logged-in Honeycomb users for 10 minutes:

Now we know who’s actively using our system, and we can run queries to find out what they’re focusing on, in order to best optimize their user experience.

Conclusion

Viewing telemetry in the lens of a session with the application is an important way to understand telemetry. Honeycomb creates a session.id for each web user when the SDK is initialized, and now with version 0.15.0 of the SDK, you can define and manipulate the session.id yourself.

Coming in part two, we’ll show you how to get the most of sessions with Honeycomb queries and the Explore Data feature.