Chat now with support
Chat with Support

Foglight Experience Monitor 5.8.1 - Installation and Administration Guide

Installing and configuring Multi-appliance clusters Configuring the appliance Specifying monitored web traffic Transforming monitored URLs Managing applications Foglight components and the appliance Using the console program Troubleshooting the appliance Appendix: Third party software Appendix: Dell PowerEdge system appliance

Defining user session options

Access the User Sessions page by clicking Configure > Monitoring > User Sessions. The Options section enables you to configure sessionizing, capture and timeout settings.

The appliance can use one of two sessionizing modes in order to detect and capture user sessions. By default, the appliance is configured to detect user sessions by individual hit.

If the appliance is configured to use hits to detect user sessions, every incoming hit is examined for user session variables. This means that a session can be easily identified, but the application needs to provide the same identifier in every hit for the duration of the session.

When the appliance is configured to sessionize by TCP connection, it identifies a user session by detecting the session identification variable in the first few hits, then applies that determination to the remainder of the TCP connection.

For some external applications such as Siebel, PeopleSoft and when monitoring SharePoint®, this mode is useful because it can track a user session across changes in the session identification variable that can sometimes occur during a TCP connection. If your application behaves this way and you have not selected this mode, then the user sessions displayed in the User Sessions Log are fragmented whenever this occurs.

By default, all user sessions are recorded in the database. For performance reasons, it may be desirable not to capture every user session by clearing the Capture all User Sessions check box in the Options section of the User Sessions page.

When the appliance has started recording a user session, it can use timeout periods in conjunction with logout patterns to determine when a user session terminates. The appliance has two timeout configuration settings that affect when a user session is considered terminated.

In the User Session timeout period box, you can adjust the amount of time a user session is inactive before the system considers the session to be terminated and writes the associated record to the database. Generally, you should only need to adjust this setting if your users tend to have long periods of time in which they leave an application inactive. By increasing the timeout period, you can cause user sessions that would have been regarded as distinct to be combined into one record. This setting should reflect the session timeout period that your application enforces.

In the TCP timeout period box, you can adjust the timeout period that the system applies to inactive TCP connections before closing them. You may need to adjust this if your site makes use of proxies that keep TCP connections open without transmitting any data for extended periods of time. This setting should reflect the TCP timeout period that your application enforces.

Configuring client IP tags

By configuring the Client IP tags in the User Session page, you can define the tags of HTTP headers that contain IP addresses of client machines accessing your monitored applications. In typical network environments, client traffic is routed through a proxy server that replaces the originating client IP addresses with the IP address of the proxy server.

The following HTTP headers are industry standards for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer, and display as the default Client IP Tags in the appliance:

For more information, see Configuring client IP tags and Using X-Forwarded-For.

If your site is using different HTTP headers than those listed above, you may notice that the client IP addresses appearing in the User Sessions Log are the same. To ensure that the correct originating IP addresses appear in the appliance web console, you will need to determine which HTTP header (if any) you need to configure in the Client IP Tags list.

If there are no HTTP headers containing the originating IP address, contact your network administrator to determine if this feature can be enabled in your HTTP proxy or load balancer.

This list is in priority order (if you have more than one header containing the Client IP) so make sure that the order reflects the configuration of your network. Use the and arrows to reorder the items in the list. Tags that are not in use on your site may be removed from the list although this is not required.

In the Client IP Tags section, enter the name of the tag that matches HTTP header containing the IP address of the client machine, then click Add.

The list of logout patterns updates to include your addition.

Select the check boxes that corresponds to the Client IP Tag you would like to remove, then click the Delete button.

Augmenting user sessions log information

You can add information in the User Session Log by using the login names as identifiers.

Many applications check the credentials of users logging into the application by displaying a page that prompts the user to enter an account name and password. When the user enters this information, the login name is typically transmitted to the application server in a form (or POST) parameter. The appliance has the ability to extract these fields from the traffic and associate the login name for the user with the user session. This greatly facilitates the use of the User Sessions Log and makes it much easier to identify the user associated with a session.

In the Login Variables section, you can define the names of variables that are used to contain login names in your application. While login variables are typically contained in form variables, the system can also extract them from cookies or query variables embedded in a URL.

With this configuration setting, you are able to see the login names of your users in the Identifier column of the User Sessions Log and in the All Metrics View report. You can also define an alarm based on the value of the login name that triggers whenever it matches a pattern that you define.

In the Login Variables section, enter a variable that will be used to identify a user login, then click Add. The list of login variables is updated to include your addition.

Instead of entering variable names manually, you can choose the auto-discovery links to have the system generate a list of variables that are used to log in to the monitored application in the network traffic. For information about NTML authentication, see Extracting login names from NTLM.

1
On the User Sessions page, in the Login Variables section, click Auto-Discover Login Variables.
2

NTLM is a suite of authentication and session security protocols used in various Microsoft® network protocol implementations. Originally used for authentication and negotiation of secure DCE/RPC, NTLM is also used throughout Microsoft's systems as an integrated single sign-on mechanism. It is recognized as part of the Integrated Windows Authentication stack for HTTP authentication; however, it is also used in Microsoft implementations of SMTP, POP3, and IMAP (all part of Exchange).

Foglight Experience Monitor has the ability to decode NTLM authentication exchanges between clients and web servers, and extract the login name that users enter when logging into an NTLM-enabled system. To enable this functionality, you need only to add Authorization to the list of Login Variables. No other action is required.

NOTE: Authorization will also show up when you choose the Auto-Discovery Login Variables function if NTLM exchanges are found in the monitored traffic.

Select the check boxes that correspond to the login variables you would like to remove, then click the Delete button.

Using logout patterns to detect completed sessions

By default, the appliance considers a user session active until the timeout period has expired. (See Defining session timeout periods for more information about timeout periods.) Defining logout patterns helps the appliance determine if and when a user has actively logged out of their application. Being aware of a user that actively logs out, compared to waiting for a timeout period to be reached, means the user session is written to the User Sessions Log more quickly than it would be otherwise. This can assist with the troubleshooting of user issues in real time.

In the Logout Patterns section, you can enter a regular expression (e.g., .*logout.*) that matched against the URL that the user is accessing. If the user accesses a page that matches any of the defined logout patterns
(in this example, https://company.com/app/sessions?logout=true), the user session is considered terminated and the record is written to the database.

In the Logout Patterns section, enter a regular expression meant to match a logout pattern in a URL, then click Add.

The list of logout patterns updates to include your addition.

Select the check boxes that correspond to the expressions you would like to remove, then click the Delete button.

Some applications embed session identifiers in the path of a URL. For example the following URL:
http://yoursite/yourpage.asp/234agt438c3k/index.html
uses 234agt438c3k as the session identifier.

If your applications identify user sessions by this method, you can define a path rule that the system uses for session identification.

For general information on how transformations are performed on the path portion of URLs, see Defining path rules. For specific information, see Managing variable rules.

Many network environments make use of Proxy servers that service the requests from clients by forwarding these requests to other servers. A client connects to the proxy server, requesting a web page, and the proxy server provides the page by connecting to the specified server and requesting the page on behalf of the client. Typically, the proxy server alters the client's request by removing the client's IP address and replacing it with the IP address of the proxy server itself so that it can receive the response from the application server before forwarding it on to the client. If this type of proxy server is in use on your network then you may see that the user sessions log displays the same IP address for all user sessions that are displayed as shown in the following illustration.

The X-Forwarded-For (XFF) HTTP header is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy. XFF headers are supported by most proxy servers, notably Squid, Apache™ mod_proxy, F5 Big-IP, Blue Coat ProxySG, Cisco Cache Engine, Finjan's Vital Security, and NetApp NetCache.

By enabling XFF headers in your proxy server, you allow the appliance to extract the user's IP from that header and display it in the user sessions log. See the documentation for the proxy server you have to determine how to enable XFF headers. No action is required in the appliance as it automatically searches for the XFF header by default.

Related Documents