Web - HTTP

NAM Console ► Deployment ► Manage devices, NAM Probe Configuration ► Open configuration, Global ► Front-End Monitoring ► Web ► HTTP

For these tasks, you should be familiar with

  • Creating user-defined software services for this protocol
  • Creating accessing and modifying global settings for a NAM Probe and settings for a specific service
  • Creating URL definitions for your rules

Global settings for the HTTP analyzer refer to the following:

General

HTTP general configuration options are options related to a variety of settings such as timeout values, redirection handling, session recognition, multi-frame page handling, and cookie handling. They can be set globally for the NAM Probe or individually for particular software services.

Note

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.

To configure general options for monitoring this protocol:

The list of configuration options available in the General section:

Redirect timeout

This timeout period, expressed in seconds, is configured globally for all software services.

HTTP redirects are stored until either a matching target URL is seen or a timeout expires. If the redirect target page has not been seen by the time the redirect timeout expires, the NAM Probe reports the URL with all transactional metrics equal to zero and the redirect is referred to as an orphaned redirect. The URL reported is taken from the orphaned redirect.

Cascaded unauthorized hits timeout

Cascaded unauthorized hits older or equal to this timeout (in seconds) are treated as unauthorized. In case of a mixed cascade, redirects and unauthorized hits, the head of cascade determines which timeout should be used, Redirect timeout or Cascaded unauthorized hits timeout.

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.

Hit session timeout

Maximum time delay allowing a hit to be linked to a page. The value is specified in seconds, with a resolution of one-tenth of a second, and is configured globally for all software services.

User agent timeout

Time in minutes after which a user agent will be erased from the cache. The value is configured globally for all software services.

Maximum header length

Maximum size in bytes of the buffer that the HTTP header can be assembled into before considering it incomplete and proceeding with its processing. This option is available only in HTTP mode of the HTTP analyzer. The value is configured globally for all software services.

Maximum request body length

Maximum size in bytes of the buffer that HTTP request body can be assembled into before considering it incomplete and proceeding with its processing. This option is available only in HTTP mode of the HTTP analyzer. The value is configured globally for all software services.

Maximum response body length

Maximum size in bytes of the buffer that HTTP response body can be assembled into before considering it incomplete and proceeding with its processing. This setting can be adjusted only for Oracle Forms over HTTP profile. Default value of "0 " will be used for other analysis profiles.

Report URL after redirect

This option causes addresses after the last redirection to be reported for redirected pages. By default, redirections are reported as addresses of the originating page, before redirection takes place. The final target page will be reported regardless of how many redirects are detected in between.

The 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. It is not supported by HTTP Express analyzer.

Report analyzed HTTP method

If this option is selected, the string “POST” or “GET” will fill the Request method DMI dimension. However, this will not prefix the URL unless you set
http://cas_ip_address/userpropertiesadmin?KEYS=PREFIX_URL_WITH_HTTP_REQUEST_METHOD
to true. Prefixing is typically used for creating transactions where the same URL can be seen once as POST and the other time as GET, but business logic depends on it.

The All methods option allows for processing all detected HTTP methods including the WebDAV HTTP extension. The extended WebDAV methods automatically identified include:

  • PROPFIND Retrieves properties and a directory hierarchy of a remote system.
  • PROPPATCH Changes and deletes multiple properties is a single operation.
  • MKCOL Creates directories or collections.
  • COPY Copies a resource from one URI to another.
  • MOVE
    Moves a resource from one URI to another.
  • LOCK
    Puts a lock on a resource.
  • UNLOCK
    Removes a lock from a resource.
Note

Monitoring WebDAV software services requires a specific configuration option. In order to properly report a hit as a separate operation, you must define a URL with regex matching all URLs (http://.*) and content types.

Treat a client RST packet sent by the session as closing session

If this option is selected, the protocol analyzer will treat 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.

Accept all HTTP response codes

By default, the HTTP decode ignores hit content type with response code above 300. As a result, many 400-500 responses are marked as text or html when in fact they are not HTML documents. When switched to checked, the HTTP decode treats all response codes equally.

Configure page and session recognition based on cookies

You can use cookies to distinguish between separate HTTP pages and sessions. This is useful when, for example, a number of distinct users are hidden behind a shared load balancer or a proxy server.

Select client IP address extraction method.

  • To turn off automatic client IP address extraction, select Off.

  • To extract the client IP address from a header tag, select Header tag and type the name of the HTTP header field containing the real client IP information.

  • The string extracted by the regular expression becomes the real client IP address reported to the report server.

    The following is an example of extracting the value of REMOTE_ADDR field from the HTTP header.

    An HTTP header might contain the following information:

    GET http://www.slow-server.com/login.jsp HTTP/1.1
    Accept: */*
    Referer: http://www.slow-server.com/
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
    Host: www.slow-server.com
    Connection: Keep-Alive
    Cookie: FPB=061j8hura11q56cv; CRZY9=t=1;
    REMOTE_ADDR: 10.1.0.2
    

The following regular expression extracts the address 10.1.0.2 from the REMOTE_ADDR field:

%0d%0aREMOTE_ADDR:%20\([^%0d%0a]*\)%0d%0a

The expression must contain a single sub-expression delimited by pairs of characters “\( ” and “\) ”. The expression in this example states that the search string should start at the beginning of a header line and end at the end of the line (note the use of % to denote the hex values of the carriage return and line feed characters). The line should start with the string “REMOTE_ADDR: ”. The sub-expression to extract is a string of characters different than ASCII CR or LF, and it should occur after the space following “REMOTE_ADDR:

For details on how expressions are used, see Extracting user identification.

  • To use the real client IP address as both the user ID and the user IP address, select Try to convert user name to IP address.

Page assembly

Page assembly options concern methods of assigning individual hits to pages (assembling pages from a number of hits).

Regular hits

Configure options available in the Regular hits section. The options relate to various flavors of cross-site hit assignment (assembling pages from hits requested or loaded from a number of hosts).

  1. Decide whether to enable cross-site hit assignment.

    Select Enable cross-site hit assignment to enable page components loaded from different hosts to be recognized as belonging to the same page loaded as a result of a single transaction.

  2. Decide whether to enable multi-client cross-site hit assignment.

    Select Enable multi-client cross-site hit assignment to enable HTML page components that belong to one page, but that are requested by a number of parallel proxy servers on behalf of a single client, to be recognized as belonging to the same page loaded as a result of a single transaction. Such a situation may occur if client traffic is directed through a number of proxy servers for each TCP/IP session.

  3. Decide whether to enable multi-client real IP cross-site hits assignment.

    Select Enable multi-client real IP cross-site hit assignment in deployments with the NAM Probe monitoring traffic from a number of load balancers. This way, the cross-site hit assignment is based on the real IP address of the client extracted from the X-forwarded-for HTTP header field.

  4. Decide whether to enable hit assignment for different combinations of operating systems, browsers, and hardware.

    Select Enable hit assignment for different OS/Browser/Hardware combinations to enable HTML page components that belong to one page, but that are requested by hosts with a different operating system, browser, and hardware combination than the one detected in the first hit, to be recognized as belonging to the same page loaded as a result of a single transaction.

  5. Decide whether to assign a hit to a page when no referrer is found.

    Select Assign hit to page when no referer found to assign a hit to a single page load if the analyzer has only one page load in progress and a new hit occurs that has no Referer field.

    This option is configured globally for all software services for this protocol.

Redirects

Configure options available in the Redirects section. These options control the way pages are assembled in the case of redirects.

  1. Choose keys used to assemble pages in the case of redirects.

    You can enable redirects identified by the same client IP, real client IP, user name, software service name, or OS/browser/hardware combination to be recognized as belonging to the same page loaded as a result of a single transaction. The real client IP is useful when monitoring the traffic from a number of load balancers. This way, you can use the real IP address of the client extracted from the X-forwarded-for HTTP header field as a key for redirects.

  2. Decide whether to report redirections from HTTPS to HTTP.

    In the redirect from HTTPS to HTTP, the referrer is not set. Select Report redirections from HTTPS to HTTP to report this kind of redirect.

  3. Decide whether to report a redirect as a page.

    You can configure page redirects as single regular pages and report them separately. This makes it possible to combine the redirects with the originating or target page (depending on the setting in Report URL after redirect). In this way, redirects can become operations and you can create transactions consisting of more than one step.

    Redirects are commonly used with login procedures. For example, if your web service requires login and four redirects occur, you can select Report redirect as page for the second URL and obtain a two-step transaction. This makes it possible to observe in greater detail where the problem occurs after it has been reported.

    Reporting of redirects as pages can be configured per server, per URL, and per URL parameter. If you do not select this option per URL, it inherits the value from the related per-server configuration.

    Default: not selected.

Multi-frame pages

It is possible to recognize framesets as single pages. This can be performed dynamically, by analyzing HTML tags, or statically, by explicitly defining framesets.

  1. Decide whether to enable multi-frame page recognition.

    Select Enable multi-frame page recognition to enable the entire mechanism of frame recognition—automatic frame recognition and static frame recognition—at all levels: global, service, and URL.

  2. Decide whether to enable automatic multi-frame page recognition.

    Select Enable automatic multi-frame page recognition to enable frame recognition based on analyzing HTML FRAMESET and IFRAME tags.

URL auto-learning

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.

Configure global settings

  1. Select the Enable URL auto-learning check box to enable auto-learning for all services based on this protocol.

  2. 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.

  3. Adjust the auto-learning algorithm.

    Click Advanced settings to show the properties so you can adjust the behavior of the auto-learning algorithm.

  4. 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.

  5. 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: settings at the software service level

  1. From the top menu, select Software Services ► Manage Software Services.

  2. 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.

  3. 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.

  4. Click the URL Auto-Learning tab.

  5. Enable or disable URL auto-learning.

    A user-defined software service has the following options:

    Off

    To turn URL-auto learning off for this service.

    Global Settings

    To use global settings for all services based on this protocol.

    Custom Settings

    To specify custom values for URL auto-learning settings for this software service.

    All

    To monitor all URLs for this software service. The option is not supported by the HTTP Express analyzer.

  6. Optional: Adjust the auto-learning algorithm.

    This is only possible if you select Custom Settings.

    Click Advanced settings to show the properties so you can adjust the behavior of the auto-learning algorithm.

User identification

Ensure that the HTTP analyzer is set to HTTP mode.

The enhanced method of extracting and processing user identification for HTTP can be configured globally for all HTTP software services configured on NAM Probes set to work in HTTP Mode, or it can be configured for a specific user-defined software service on the User Name Recognition tab.

  1. Open the User Name Recognition screen for a particular user-defined software service or open the corresponding screen for Global settings.

  2. Select or clear Enable User Name Recognition for a specific service.

    This option is available only for a specific software service. Clearing the setting here disables it for this service only, regardless of any global settings for HTTP. Selecting it gives you the choice of using global settings or of selecting settings specific for the given service. Service-specific settings always take precedence over global settings.

  3. Select a search policy.

    Add new or select an existing policy, that is a container for a set of detection rules. Right-click a cell in the Available Policies table and select Add or Edit.

Adding detection rules

To add user name rules, right-click a row in the User recognition rules table and select Add or Open. User Recognition Rule Definition dialog opens. At least one user rule is required for user recognition mechanism.

  1. Choose a type of user recognition rule.

    When adding the detection rules used to identify the user names, you have to follow one the following scenarios.

    Ack URL (User session context, acknowledge URL)

    The user name recognition is performed in the context of a particular user session and a login is validated by redirection to a special acknowledge URL. All monitored hits must contain the session ID, but only the ACK hit is the first one to contain the user name. Besides user and session ID rules, you need to provide the acknowledge URL (as described in the procedure) for the NAM Probe to be able to discover a user session and retrieve the user name.

    Session ID (User session context)

    The user name recognition is performed in the context of a particular user session. All monitored hits must contain the session ID, but only a single login hit contains the user name. Besides user detection rules, you need to define session ID rules as well.

    User Name (Non-context)

    The user name recognition is performed individually per hit, consequently each hit must contain a user name. You only need to add user detection rules as described in Step 1

  2. Choose where to search for a value.

    You can retrieve the user names and session identifiers from a number of entities, referred to as search scopes.

  3. Optional: Configure the Host and path settings.

    Enter the following to filter the traffic used for user name recognition.

    • Host pattern Server host name.
    • Path pattern The leading part of a URL. Only hits beginning with this string will be matched. This parameter is optional. If it is not specified, the path is assumed to be “/” and it will match any requested URL.
  4. Configure the search and transformation rules to be applied. It is sometimes difficult to perform a successful match resulting in a legible string in one pass. In such situations, you can perform further transformations to your initial search result.

    Right-click a row in the Apply following search and transformation rules table and select Add or Open. Search or transformation rule definition dialog opens.

  5. Advanced settings

    Match only when response has one of the indicated HTTP status codes. The HTTP status codes can be defined by providing the HTTP status code range. Use the official HTTP status codes to narrow down qualifying responses.

    • (100 - 200) Informational
    • (200 - 300) Success
    • (300 - 400) Redirection
    • (400 - 500) Client error
    • (500 - 600) Server error

Detecting single sign-on (SSO) users

If you have an SSO user across various software services, you can still report this person as the same user as long as you apply the following configuration.

Configure the first software service to detect a user and associate that user with particular cookie value. You need to define a search pattern matching a particular cookie value. When defining other software services, make sure the following conditions are met.

  1. You keep the same name of the policy.
  2. The cookie name may vary among software services.
  3. The cookie value you search for must be the same as in the original software service.

Sequenced transactions and header data

In this section you can turn on and off generation of performance data on sequenced transactions and headers, enable data filters and define filtering criteria.

General

If you are interested in obtaining information based only on aggregated monitoring data on your reports, and not in per-URL data, you can globally disable data generation for transactions and ADS data and ADS header data in the NAM Console.

Configuration options for logging of transactions and ADS data and ADS header data are defined globally for all services, though logging can then be disabled for individual user-defined services.

To configure logging of transactions, ADS data and ADS header data on a specific NAM Probe:

Configure global settings

Select to generate or not to generate monitoring data.

Select or clear the option entitled Generate sequenced transaction ADS data and ADS header data.

Note

This global option affects data generation for all HTTP-based services and takes precedence over them. Clearing this option here will cause no such data generated for any HTTP services, even if data generation is enabled for an individual user-defined service.

If you do not require this type of data to be generated and have cleared the option, proceed to save or publish the configuration. Otherwise, proceed to the next step.

Optional: Configure data generation for explicitly defined URLs only.

If you require data to be generated only for URLs that have been explicitly defined in user-defined services or recorded through auto-learning, select the Generate data only for explicitly defined URLs check box. Monitoring this data for default services will then be turned off.

Optional: Select content type information to be saved.

Select or clear the option entitled Save all content type in addition to HTTP hits to log or not to log hits other than HTTP.

Optional: Configure masking of personal information.

Provide masks to avoid explicit logging of personal data. The masks should be specified by clicking the context menu in the Parameter masks section of the configuration screen.

Optional: Specify the maximum size of POST data saved.

Specify the number of bytes in the edit box of this name.

Optional: Specify the maximum size of cookie data saved.

Specify the number of bytes in the edit box of this name.

Optional: Specify custom tags to be extracted.

The custom tags functionality allows you to select a whole field in the HTTP header to write to the vdata files.

Right-click the table entitled Custom tags and select Add from the pop-up menu. In the Custom Tags pop-up window, specify the following information:

Name

The name of the field to report in the vdata file.

Syntax: letters, numbers, hyphens, and brackets are acceptable; other characters, including spaces, are forbidden.

Pattern

The field name to extract from the HTTP header.

Syntax: the whole field name with the colon. For example: Cookie:, Host: or Content-type:.

Extract from

Defines the source of data: HTTP request, HTTP response, or HTTP request and response. Choosing None will result in no tags being extracted.

Click OK to confirm the configuration.

Optional: disable logging transactions, ADS data, and ADS header data for individual services

If you disabled data generation, you cannot enable it for an individual software service. If data generation is enabled in the global level, however, you can still disable it for a selected service.

  1. From the top menu, select Software Services ► Manage Software Services.

  2. 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.

  3. 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.

  4. Click the HTTP Options tab.

  5. In the Data Generation section, clear the check boxes labeled Transactions and ADS Data or ADS Header Data as needed.

    By default, generation of transactions and ADS data is enabled.

Content type monitoring

You can also configure it at the software service and URL level.

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.

  1. 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:

    • Auto-Learning Enabled
      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.

      The text/html content type is the default for pages. It cannot be removed from the list, and Treat as HTML is always set to true.

      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/jpg and image/gif are valid entries for an Objects recognized as pages table.

    • Search in response body
      Applies to NAM 2018
      Whether to parse the response body for the selected content type. When this is not selected, frame and user recognition, as well as data mining rules, are not applied to the response body for this content type.

    • Search for all response codes
      Applies to NAM 2018
      Whether to apply all the settings (for the selected content type) above for all response codes. When this is not selected (by default), the Treat as HTML and Search in response body flags are used only for response codes in the 2xx range. Select this if, for example, you want to extract a custom operation attribute from the response body from a "500 Service Unavailable" response in conjunction with the Search in response body setting.

  2. 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:

    • .css
    • .htc
    • .gif
    • .jpg
    • .jpeg

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 (above). 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.

Browser recognition

NAM has pre-configured rules for recognizing synthetic agents and browsers, but you can define additional recognition rules for checking the User-Agent field of the HTTP request-header.

Add browser

To add an agent or browser definition pattern:

  1. Right-click the Browser Recognition table and select Add.
  2. Specify whether it is a browser or a synthetic agent.
  3. Specify the name and version
    For a synthetic agent, you have to provide its predefined identity (in the 50 to 150 range).
  4. You can override the global Hit Session Timeout value for all software services.
    • This is the maximum time delay allowing a hit to be linked to a page.
      The value is specified in seconds, with a resolution of one-tenth of a second.
    • Synthetic agents may require a higher Hit Session Timeout value because, unlike real users, they always load the full page contents and all of its elements. Real users, especially if they access frequently visited page, load many page items from the browser cache instead.
  5. Define a simple search pattern or a regular expression by which this browser or agent can be recognized.
    In HTTP communication, the User-Agent request-header field contains information about the user agent originating the request.
    • A simple pattern matches when the entire string is found anywhere in the User-Agent field.
    • A regular expression matches when the expression evaluates to true for the contents of the User-Agent field.
      Click Test to open the expression test window.

Add pattern to browser

To add an additional pattern to match against the selected agent or browser definition, right-click the Browser Recognition table and select Add Pattern to Browser.

Open

To modify an existing agent or browser definition, right-click the definition in the Browser Recognition table and select Open.

Delete

To delete an existing agent or browser definition, right-click the definition in the Browser Recognition table and select Delete.

Operating system recognition

Operating System Recognition lists rules for recognizing operating systems.
Right-click in the Operating System Recognition table to add, open, or delete an operating system rule.

  • Name : the operating system name to be used in the reports in case of a successful match.
  • Pattern : when defining the search pattern, you can use either a simple pattern or a regular expression search.
    • A simple pattern matches when the entire string is found anywhere in the User-Agent field.
    • A regular expression matches when the expression evaluates to true for the contents of the User-Agent field.
      Click Test to open the expression test window.

Hardware recognition

Hardware Recognition lists rules for recognizing hardware.

Right-click in the Hardware Recognition table to add, open, or delete a hardware rule.

  • Name : the hardware name to be used in the reports in case of a successful match.
  • Pattern : when defining the search pattern, you can use either a simple pattern or a regular expression search.
    • A simple pattern matches when the entire string is found anywhere in the User-Agent field.
    • A regular expression matches when the expression evaluates to true for the contents of the User-Agent field.
      Click Test to open the expression test window.

Character encoding support

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.

Note

For Chinese encodings, there is no auto-detection; all encodings must always be specified manually.

Dynatrace integration

Use this screen to set the timeout for rtmgate restart.

Recognition and parsing of URLs

NAM Console ► NAM Probe Configuration ► Global ► Front-End Monitoring ► Web ► HTTP ► Recognition and Parsing of URL

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.

Note

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:

No cut

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.

Note

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.

Availability

You can configure HTTP availability globally or at the software service level, user-defined URL level and at the URL with parameters level. overriding the global settings.

For global configuration, open the NAM Probe configuration and go to Global ► Web ► HTTP ► Availability. For the software service level, select the Availability tab in the Edit Rule window. For the URL level, select the availability tab in the URL Monitoring screen and for the URL with parameters select the Availability tab in the Parameters Monitoring screen.

In HTTP availability reporting, for each failure category, you can control the error classification by using following options available in the list next to each of the available transport and application errors:

  • Any component
    Error is classified as failure if occurred in any component (hit) of the operation.
  • Subset
    Error is classified as a failure only if occurred in components (hits) matching the regular expression provided in the accompanying field.
  • Base component
    Error is classified as a failure only if it occurred in the base component (main hit) of the operation.
  • Any component (monitored URL)
    Similar to Any component, but failure reporting is narrowed to monitored URLs, that is user defined URLs and reported auto-learned URLs.
  • Subset (monitored URL)
    Similar to Subset, but failure reporting is narrowed to monitored URLs, that is user defined URLs and reported auto-learned URLs.
  • Base component (monitored URL)
    Similar to Base component, but failure reporting is narrowed to monitored URLs, that is user defined URLs and reported auto-learned URLs.
  • Disabled
    Error is not classified as a failure.

Failures (transport)

  • Incomplete responses
    You can determine whether the following types of incomplete responses should be classified as failures (transport).

  • Partial response (standalone hit)
    An incomplete response observed for a hit without an operation context, classified as a Dead hit. This pertains to situations when server started the response but never finished due to a timeout or other problems.

  • Aborted response (standalone hit)
    An incomplete response observed for a hit without an operation context, classified as a Break. This pertains to situations when server started the response but aborted it before completion with TCP reset.

  • No response
    A request hit with no response from a server. This pertains to situations when server did not respond at all or responded in unrecognizable way.

  • Partial response
    An incomplete response with a Dead hit status. This pertains to situations when server started the response but never finished due to a timeout or other problems.

  • Aborted response
    An incomplete response with a Break status. This pertains to situations when server started the response but aborted it before completion with the TCP reset.

  • HTTP errors

  • The NAM Probe is able to deliver information on seven HTTP error groups (“categories”).
    You can decide whether each of these should be taken into account when calculating (failures transport). Note that HTTP client errors (4xx), HTTP server errors (5xx), HTTP unauthorized errors, HTTP Not Found errors, and HTTP server errors (category 1) have configurable contents. For more information, see Web - Errors.

    • HTTP client errors (4xx)
    • HTTP server errors (5xx)
    • HTTP unauthorized errors
    • HTTP Not Found errors
    • HTTP client errors (category 3)
    • HTTP server errors (category 1)
    • HTTP server errors (category 2)

Failures (application)

You can decide whether each of five operation attributes should be reported as failures (application).

Fault domain isolation

Thresholds

Use the following threshold settings to accurately identify the true source of the problem:

  • Server time threshold
    This relates to the server time portion of an overall operation time. Server times above the threshold limit are considered to be slow due to poor data center performance.
  • Idle time threshold
    Threshold for the time during the operation execution when there is no network or server activity related to the operation. It is assumed that Idle time is caused by the user's software not sending requests because user's PC is busy.
  • Network time threshold
    Threshold for the time the network (between the user and the server) takes to deliver requests to the server and to deliver page information back to the user. In other words, Network time is the portion of transaction time that is due to the delivery time on the network.
  • Retransmissions threshold
    Percentage of retransmissions regarding all observed transmissions.
  • Network time affected by high retransmission threshold
    Percentage of the network time affected by high retransmission threshold.
  • Request size threshold
    Threshold for the request where anything larger would be considered a big request.
  • Network time affected by the transfer of a big request threshold
    Threshold for the request where anything larger would be considered a big request.
  • Response size threshold
    Threshold for the response where anything larger would be considered a big response.
  • Network time affected by the transfer of a big response threshold
    Threshold for the network time that is affected by the transfer of a big response threshold.
  • Number of hits threshold
    Threshold for the number subcomponents of error-free operations or transactions.
  • Single hit duration threshold
    Threshold for a hit duration as a percentage of operation time.
  • Rtt threshold
    Threshold for the time it takes for a SYN packet to travel from the client to a monitored server and back again.