Foglight APM for Real User Experience 5.9.11


	TIP: By default, a session search returns a maximum of 200 sessions. An APM Administrator can change this limit using the Session Search Result Limit setting in the Configure Advanced Options > Settings dashboard.

Figure 32. Search Sessions dashboard

The Search Sessions table may contain some or all of the following columns. To hide/show columns, click the Customizer icon (beside the Search field) and select the columns to show.

Table 15. Search Sessions table

Column

Description

Session

The Session Explorer and Session Detail View icons appear in this column. You can drill down to session details by clicking these icons.

Status

Indicates the session status using the standard severity icons:

•

•

•

•

•

Not available (session is still in progress)

Custom Fields – Initial Referer

Displays the page the user visited just before starting the session (if any).

Start Time

Corresponds to the time the first hit in the session was initiated.

Stop Time

Corresponds to the end time of the last hit in the session.

Duration

Displays the length of the session since the Start Time.

User Name

If username rules are defined, displays the user name associated with the session. For more information, see “Associating user names with user sessions” in the Foglight APM Administration and Configuration Guide.

# Hits

Displays the number of hits contained within the session at the time of the search.

# Pages

Displays the number of pages contained within the session at the time of the search.

# Sequences

Displays the number of sequences contained within the session at the time of the search.

# Warnings

Displays the number of hits with a warning status contained within the session at the time of the search.

Error Columns

Displays the number of hits with the specified error contained within the session at the time of the search. Show columns for Custom Errors, Reset Errors, HTTP Errors, Client Errors, Server Errors, or Timeout Errors.

Investigating issues reported during real user sessions

When a helpdesk receives reports from real users (internal staff or external users) regarding unexpected errors or slow page performance, technical support staff can use Foglight APM search features to find the problem user sessions. By reviewing what your users experienced, you can form an understanding of what may be causing the problem. You can then escalate the issue to the appropriate person (developer or administrator) for resolution.

For more information, see the following topics:

•

Finding the user session

•

Investigating issues

Finding the user session

You can identify the real user’s session using one or more of the following pieces of information as search criteria.

•

Time period—find out the time period during which the session was active, or find out when the user started or ended their session.

•

Session identifier—if a user’s browser captures the session identifier, instruct the user how to retrieve that identifier.

•

User name—for applications that require a login, request the user’s user name.

•

Client IP address—for an internal application, request the user’s client IP address.

•

Subnet—for an intranet application, find out the subnet used by the application.

•

City—if no other identifying details are known, you may need to search sessions by the user’s city.

•

Page visited before starting session—this information can be useful for picking the correct session out of a list of session search results. You can look at the Initial Referer column to find the page the user visited before beginning the session.

The following workflow assumes that you have the session identifier or user name. If you do not, you need to define an expert search and create match conditions using one or more of the other details as your search criteria. For instructions, see Defining expert searches for sessions.

To find the user session:

Gather information about the user’s session.

Log into Foglight.

In the navigation panel, under Dashboards, click APM > Search > Sessions.

Click Simple Search.

Specify the time period during which the user experienced issues. From the first list, select the state of the session (started, in progress, or ended) during the time period. From the second list, select the time period.


	TIP: If no other options are set, the search returns all sessions of the selected state that occurred within the specified time period.

Optional—specify whether the session is currently active or complete.

Specify either the session identifier or the user name, whichever you have.

Click Search.

The Search Sessions results table displays the search results.

If you have only one match, you can begin investigating the session now. Otherwise, you need to pick out the user’s session from the results list. If you know the session start time, end time, or the page that the user was looking at before beginning the session, you should be able to select the correct session by looking to those columns in the Search Sessions results table.

Investigating issues

You use the Session Explorer to investigate issues. The Session Explorer contains:

•

Complete hit details for the entire HTTP request and response for any hit in the session

•

A visual presentation of each page as originally served by the web server

•

A visual presentation of each page with user input (forms/links)

•

The original HTML source for each page generated by the web server

•

Any errors (HTML or other source) detected by analyzers

•

Session and sequence durations, hit counts, and other aggregate details


	NOTE: This workflow starts from the Search Session results table. However, the process is similar when you drill down from a Real User tile in the Transaction dashboard or when you run a search for hits or sequences.

This workflow presents one way to investigate issues. Your investigation should be guided by the type of problem you are investigating. For example, you may want to skip the session replay and go straight to the hit inspector.

To investigate an issue:

In the row containing the issue you want to investigate, click Session Explorer

The Session Explorer opens. When opened from the Search Hits results table, the hit displayed is the selected hit. When opened from the Search Sequences or Search Sessions results table, the hit details represent the first hit in the selected sequence or session.

If not already selected, click the Replay tab.

The content associated with the selected hit is displayed. Look for navigation clues in the Referer/Navigated To sections above the page content. The Details sections may provide additional information. You can switch between Captured Hits (to see all hits) and Page Visit Order (HTML pages). Select different hits in the user’s path to view the content they saw.


	IMPORTANT: Some content may not be shown in the response replay. For more information on missing content and using the features in the Replay tab, see Replaying sessions, hits, and sequences.

Figure 33. Session Explorer dashboard

To investigate a page further, click the Hit Inspector tab.

In the list of hits in the session table, look for hits that exhibit symptoms of the problem, such as a hit that displays one or more of the following characteristics:

•

Status—look for icons other than the Normal icon. A hit can be set to a non-normal status due to a client or browser error code or when the hit matched some set of conditions defined within a hit analyzer. APM Administrators define and manage hit analyzers.

•

Code—look for client error codes (400+) or server error codes (500+). Remember though that Web 2.0 applications may not return error codes, because they redirect users to a helpful error page rather than a generic error page. In this case, you need to rely on analyzers catching the errors and setting the hit status to non-normal.

•

End-to-End Time—very high end-to-end times may indicate a problem with the amount of content on a page or a very slow web server.

•

Back End Time—very high back end times may indicate a problem with the web server.

•

Exception—any exceptions should be reported to the application developer.

After you identify the hits that contribute to the problem, select each hit in turn and scan the hit details to look for clues about what might be causing the performance issues. Additional details and metrics are available by clicking Metric Updates, Client Details, or Other Information.

Figure 34. Session Explorer Hit Inspector