NAM Console ► Deployment ► Manage devices, NAM Probe Configuration ► Open configuration, Global ► Front-End Monitoring ► Web ► HTTP Express
The HTTP Express section is devoted to setting global parameters for the HTTP Express analyzer.
HTTP general configuration options for the HTTP Express analyzer are limited to the options related to the HTTP sessions and session timeouts. You can set them globally for the NAM Probe or individually for particular software services.
For this task, you should be familiar with
- creating user-defined software services for this protocol
- accessing and modifying global settings for a NAM Probe and settings for a service
Configuration options related to general settings for a NAM Probe for this protocol analyzer are also under the HTTP Options tab for individual user-defined services.
- Configure options available in the General section.
The list of configuration options includes:
Last packet HTTP session timeout
If the time since the last packet for an HTTP session is longer than this value (in seconds), the hit is considered finished and closed. This timeout period is configured globally for all software services.
Report analyzed HTTP method
If this option is selected, the string “POST” or “GET” will fill the Request method DMI dimension. This option can be set globally for all software services or configured for a specific user-defined software service. Specific settings take precedence over global settings.
Treat a client RST packet sent by the session as closing session
If this option is selected, the protocol analyzer treats a client RST packet sent by the session as closing the session instead of aborting it if there was no content length header. It is configured globally for all software services.
URL auto-learning can be configured globally for all HTTP software services or configured for an individual user-defined software service. You can also have a separate global configuration for default HTTP and HTTP Express analyzer based software services.
For this task, you should be familiar with
- creating a user-defined software service for this protocol
- specifying rules containing essential components such as the IP address and port of the software service to be monitored
- creating URL definitions for your rules
Configure global settings
Select the Enable URL auto-learning check box to enable auto-learning for all services based on this protocol.
Define the size of reported URLs pool.
If necessary, you can change the default size of reported URLs pool. The pool is shared among all monitored servers. The auto-learning algorithm aggregates the loads of all URLs for all servers - the server IP, port or any other attribute of the server is not taken into account by the auto-learning algorithm. Any member of the pool will be reported for all servers, regardless the activity on individual servers.
- Adjust the auto-learning algorithm.
Click Advanced settings to show the properties so you can adjust the behavior of the auto-learning algorithm.
- Specify whether URL auto-learning is to be limited to synthetic agents.
Because the HTTP Express analyzer does not support synthetic agent recognition, this option is not available for HTTP Express.
- Save or publish the configuration.
Click **Save** to save your changes and continue with configuration.
Click **Save and Publish** to immediately update the devices configuration.
Optional: configure the settings at the software service level
From the top menu, select Software Services ► Manage Software Services.
Select a software service from the list.
Click in the row corresponding with your service to display a set of rules for this service on the Configuration tab.
- On the Configuration tab, select Edit manually from the Actions context menu for a selected rule.
The Edit Rule pop-up window appears. In this window you can edit and delete the existing rules, or add new rules.
Click the URL Auto-Learning tab.
Enable or disable URL auto-learning.
A user-defined software service has the following options:
To turn URL-auto learning off for this service.
To use global settings for all services based on this protocol.
To specify custom values for URL auto-learning settings for this software service.
To monitor all URLs for this software service. The option is not supported by the HTTP Express analyzer.
- Optional: Adjust the auto-learning algorithm.
This is only possible if you select Custom Settings (see the previous step).
Click Advanced settings to show the properties so you can adjust the behavior of the auto-learning algorithm.\
Content type monitoring
By default, a NAM Probe recognizes only HTML objects as pages, but it can be configured to treat other types of objects as HTML pages to be monitored. Such objects may include, for example, images, embedded objects such as Flash objects, and objects that require third-party plug-ins to render.
- Add a content type to the table listing objects recognized as monitored pages.
To have the NAM Probe treat a certain content type as a monitored page, right-click the Objects recognized as pages table and select Add from the context menu (or click the icon) to add a new entry.
For each entry, you can set the following options:
Enable URL auto-learning mechanism for pages of the selected content-type.
Treat as HTML
For asynchronous web applications, partial page updates are not declared as
text/html, so the NAM Probe does not handle such events using HTML-based monitoring features. Select Treat as HTML for update information content types (typically
text/xml) to be able to recognize partial page updates as pages, report page elements, enable frame recognition, recognize the page name, apply response based rules, and report metrics and attributes. Otherwise, you will only be able to calculate basic performance metrics for partial page updates.
text/html content type is the default for pages and it cannot be removed from the list. Accordingly, the
text/html pages are always treated as HTML and Treat as HTML is always set to
true and cannot be modified.
These entries must be compatible with those of the
Content type field in the HTTP header. Many instances of the parameters are allowed, one for each content type to be recognized as a page. For example,
image/gif are valid entries for an Objects recognized as pages table.
- Configure page filtering based on the content of the URL.
Filtering is governed by a configuration property defined in the Filtering out pages list. URLs to which the filtering criteria in the list apply are not reported in the performance data files.
This can be useful if, for example, a client requests a page composed of HTML content and a number of images, but some of the requested images are missing. The web server would respond with an HTTP error code, but if it responds with an HTML page stating that an element is missing, this would be recorded as a legitimate page load and would misleadingly raise page volume reports and should be filtered out. In such cases, you could use the Filtering out pages list to prevent such pages from being recorded.
The default list contains the following entries:
- What to do next
In addition to monitoring based on content type derived from the HTTP header, you can specify objects to be included in auto-learning as described in URL Auto-Learning. Note that this feature refers to the content of a field in the HTTP header, and not to a string contained in a URL being loaded.
Character encoding support
For this task, you should be familiar with creating user-defined software services for this protocol.
Enabling the internationalization option for HTTP services makes it possible to recognize the character encoding of HTTP content.
Enable character encoding support by selecting the Support Internationalization check box.
By default, this option is disabled.
Select the required encoding from the Force a default encoding list.
This makes it possible to apply a specific encoding regardless of the automatically detected one.
Select the Auto-Detection Algorithm to automatically detect monitored content encoding.
This makes it possible to narrow down the choices of encoding where the algorithm is not able to identify a specific language.
For Chinese encodings, there is no auto-detection; all encodings must always be specified manually.
Recognition and parsing of URLs
The global configuration settings for recognition and parsing of URLs are inherited by all user-defined software services for HTTP. Global settings can be overridden by specific settings for a particular user-defined software service.
The default values for these settings should be sufficient for most purposes and care should be taken when modifying them.
Select the method of truncating URLs.
In the field Method of Truncating URLs, select the method of truncating URLs when monitoring HTML page loads:
URLs are not truncated.
Cut after last slash
URLs are truncated after the last slash (“/”) character.
Cut after first separator
URLs are truncated after the first separator (see below for separator definitions). If cutting according to separators is selected and if the set of defined separators is empty, the URL is not cut, which is equivalent to specifying No cut.
Specify characters to be recognized as separators.
In the First parameter separators field, type characters to be recognized as separators between URLs and their parameters.
In the Parameter Separators in URL field, type characters to be recognized as separators between consecutive parameters in URL and POST body.
In the Parameter Separators in HTTP Header field, enter characters to be recognized as separators between consecutive parameters in the HTTP header.
If monitored pages may include the question mark (“?”) character as the value of a parameter, it is necessary to remove it from the list of previously defined separators.
Define the order of searching for parameters.
When defining a specific user-defined service to be monitored, you can indicate whether you want parameters extracted from the URL or from the URL request, or from any combination of these.
However, the order in which these components of the HTTP packet are searched is determined here for all HTTP services, and the first parameter that matches the search criteria is accepted. In the Search for Parameters First section, select In POST Body to cause the POST body to be searched before the URL. Selecting In URL Request will cause the URL to be searched before the POST body. The HTTP header is always searched last.
By configuring the availability, you can determine which attempt failures are included in the availability metric calculation.
You can configure HTTP Express availability globally or at the software service level.
- For global configuration, open the NAM Probe configuration and go to Global ► Web ► HTTP Express ► Availability.
- For the software service level, select the Availability tab in the Edit Rule window.
For HTTP Express, you can determine whether the following HTTP errors, all disabled by default, should be included in the calculation of
Failures (transport) metric.
- HTTP client errors (4xx)
- HTTP server errors (5xx)
- HTTP unauthorized errors
- HTTP not found errors
For more information, see Web - Errors.