Page History
...
Table 9-16 summary section (inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
enabled | When set to false, summary processing is not performed by the web collector. This setting is meaningful only on the monitored server (and not on the FP machine where it is ignored). Setting this to false (along with client-server-correlation) sets the work mode to Basic Mode. Default: true |
Table 9-17 server-side section
| Registry |
|---|
...
| elements | Description |
|---|---|
Enabled | When set to false, server-side collection is disabled. Default: true |
| client-server- |
...
| correlation | When set to false, client/server correlation is disabled and in fact the instance will work in Basic Mode (this does not have meaning on the FP machine). Default: true |
| server-network- |
...
| correlation | When set to false, server/network correlation is disabled (this does not have meaning on the FP machine). Default: true |
| filter-do-collector- |
...
| settings | When set to false, collector settings activity (handling of URL parameters) |
...
is done in the web collector instead of in the web filter. Default: true (processing done on filter) |
| filter-do-data- |
...
| patterns | When set to false, data patterns processing is done in the web collector instead of in the web filter. Default: true (processing done on filter) |
| filter-do- |
...
| locations | When set to false, data locations processing is done in the web collector, instead of the web filter. Default: true (processing done on filter) |
Table 9-18 client-side section
| Registry |
|---|
...
| elements | Description |
|---|---|
| enabled | When set to false client-side collection is disabled Default: true |
Table 9-19 statistics section
| Registry |
|---|
...
| elements | Description |
|---|---|
| enabled | When set to false statistics collection is disabled Default: true |
| max-files (in output section) |
...
Maximum files allowed in the output directory. After exceeding this value, no more files will not be written. Default: 2000 |
Table 9-20 processing section (inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
| max-data-processor- |
...
| threads | Maximum number of threads that will be invoked by the web collector to handle data. Default: 50 |
| write-dp-period- |
...
| ms | The initial wait time of the serialization timer that serializes the current data to files. Units: milliseconds Default: 120000 |
| write-dp-delay- |
...
| ms | The cycle time of the serialization timer that serializes the current data to files. Units: milliseconds Default: 120000 |
Table 9-21 server-side section (inside processing, inside web-collector))
| Registry |
|---|
...
| elements | Description |
|---|---|
| input-queue-max- |
...
| size | Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption. Default: 15000 |
| aging- |
...
| period | Max time for server records to wait in memory for correlation (with both client & network records). Units: milliseconds Default: 90000 (1.5 minutes) |
| aging-period-when-using-client- |
...
| collector | Max time for server records to wait in memory for correlation (with both client & network records) when this instance uses the client collector. Units: milliseconds Default: 30000 (30 seconds) |
Table 9-22 client-side section (inside processing, inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
| input-queue-max- |
...
| size | Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption. Default: 10000 |
| aging- |
...
| period | Max time for client records to wait in memory for correlation (with server records). Units: milliseconds Default: 90000 (1.5 minutes) |
| aging-period-when-using-client- |
...
| collector | Max time for client records to wait in memory for correlation (with server records) when this instance uses the client collector. Units: milliseconds Default: 180000 (3 minutes) |
| max-text-period-before- |
...
| fix | Max time in milliseconds for client records first byte time. If the first byte time exceeds the maximum, it will be fixed by taking the server + network time. Default: 900000 milliseconds |
Table 9-23 network section (inside processing, inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
| input-queue-max- |
...
| size | Set the maximum number of records in the input queue. After the queue reaches this size, we start dropping records. May be used to temporarily ease memory consumption. Default: 15000 |
| aging- |
...
| period | Max time for network records to wait in memory for correlation (with server records). Units: milliseconds Default: 90000 (1.5 minutes) |
Table 9-24 server-side section (inside filtering, inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
| enabled | When set to false, server-side filtering is disabled Default: true |
| reset- |
...
| identifiers | A list of identifiers that will be reset in the filtering-summary process (when needed). The identifiers will be reset, one by one, in the order they appear here until the top N limit is reached. Valid values:
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
Default: httpMethod, userAgent, protocol |
Table 9-25 client-side section (inside filtering, inside web-collector)
| Registry |
|---|
...
| elements | Description |
|---|---|
| enabled | When set to false, client-side filtering is disabled Default: true |
| reset- |
...
| identifiers | A list of identifiers that will be reset in the filtering-summary process (when needed). The identifiers will be reset, one by one, in the order they appear here until the top N limit is reached. Valid values:
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
Default: userAgent, protocol |
FocalPoint registry
The following section describes the FocalPoint registry element.
user-agents
The user-agent element consists of a set of definitions of user agents. A user agent is a device that may access a Web server. A typical user agent is a browser like Microsoft Internet Explorer or Firefox. Other types of user agents are automatic HTTP traffic generators, like Precise Insight Inquire. The Precise for Web Collector agent, automatically collects the user agent of every request that it monitors. To extract a comprehensive user agent name and version from the user agent header of the request, the agent uses the definitions in the user-agents element. By default, the user-agent element contains a definition for most of the industry’s known Web servers, like Microsoft Internet Explorer, Firefox, Netscape, Mozilla as well as the integrative Precise Insight Inquire traffic generator. However, you can add any number of user agents to the list, or change the definition of an existing user agent to adjust it to customers private needs or conventions. For example, the definition for the Netscape browser is:
<user-agent id="Netscape" display-string="Netscape version">
<version-search-string>Netscape</version-search-string>
<search-string value="Netscape"/>
</user-agent>
The default user agents that the product supports out-of-the-box are:
...
The following table describes the registry elements for the user-agent in the FocalPoint registry.
Table 9-26 Registry elements
| Registry |
|---|
...
| elements | Description |
|---|---|
| user- |
...
| agent | A user agent definition that Precise for Web uses to find and describe user agents. |
| user-agent. |
...
| id | A string identifier for the user agent. This identifier is not the display name. |
| user-agent.display- |
...
| string | The display string that is shown in the user interface for this user agent. You can use the |
...
| version token which is replaced with the detected user agent version. |
| Anchor | ||||
|---|---|---|---|---|
|
If you use an Apache, iPlanet, Sun ONE, WebSphere, Tomcat, Oracle Application Server, SAP, J2EE, or BEA WebLogic server, you can specify some Web filter settings that the Web server loads on startup. These parameters are the same for all Web servers. To add them, follow the instructions for the specific Web server.
See “Addable parameters” on page 132.
NOTE Modification For more information, see Addable parameters.
| Info |
|---|
Modification of IIS Web filter parameters is not yet supported. |
To add parameters on an Apache server1. Open
- Open the httpd.conf file.
...
- After the LoadModule pssfilter_module line, add the parameter.
For example:
LoadModule pssfilter_module... PssFilterTrace 1
To add parameters on an iPlanet server1. Open
- Open the magnus.conf files.
...
- At the end of the Init fn=pss-init line, add the parameter.
For example:
Init fn=pss-init PssFilterTrace="1"
To add parameters on any J2EE server by editing the web.xml file1. Open
- Open the web.xml file.
...
- Add the parameters to the <filter> element in the following format:
<init-param>
<param-name>xxx</param-name>
<param-value>yyy</param-value>
</init-param>
For example:
<filter>
<filter-name>pssFilter</filter-name>
<description></description>
<filter-class>com.precise.ifweb.Collection.Filters.pssFilter
.WLFilter</filter-class>
<init-param>
<param-name>PssFilterTrace</param-name>
<param-value>1</param-value>
</init-param>
</filter>
| Anchor | ||||
|---|---|---|---|---|
|
The following table lists all parameters that you can add to the Web filters. This mechanism should only be used for the instance name and <i3_root>. Any other parameter should only be added after consultation with the Precise Enterprise Support Team.
Table 9-27 Addable Web filter parameters
Parameter Description
PssInstanceName Specifies
| Parameter | Description |
|---|---|
PssInstanceName | Specifies the name of the filter’s instance. |
...
| PssInstanceID | The instance ID as specified in the infrastructure database. |
| PssI3Root |
...
| Specifies the path to the Precise installation directory. |
| PssReadConfFile |
...
Specifies whether to read the configuration files on filter initialization. If this parameter is set to FALSE, parameters are taken from the Web server only. Default: TRUE |
| PssRestartFilesPath |
...
| Specifies an alternate location for the pss_restart file. By default this file is located under the directories of the Web server itself (the exact location is web server type dependent). Set this to a different path if the file cannot be created at the default location. |
| PssInitLog |
...
Specifies whether to write initialization log messages to standard output. In some cases the standard output is written to the Web server log. Applies only to J2EE-based application servers (Sun ONE, WebSphere, Tomcat, Oracle Application Server, SAP J2EE, or BEA WebLogic) |
The following table gives a comparison of the parameter and its equivalent registry element.
Table 9-28 Parameter and Registry elementParameter Registry element
PssFilterTrace filter
| Parameter | Registry element |
|---|---|
| PssFilterTrace | filter-trace |
...
| PssIgnoreFiles | filter-ignore-files |
| PssSessionCookieName |
...
| filter-session-cookie |
| PssMaxI4WCookieSize |
...
| max-i4w-cookie-size |
...
| PssCorrelationMode | web-disable-correlation
|
...
| |
| PssExtList |
...
| ext-list |
...
| PssExtListSeparator | ext-list-separator |
| pcs_shm_ |
...
| dir | general-pcs-shm-dir |
| PssURLEncodingName |
...
| filter-encoding-name |
...
| PssUseURLEncoding | filter-use-encoding |
| Anchor | ||||
|---|---|---|---|---|
|
The Activity tab of Precise for Web displays information on the URLs and pages visited. In some cases, the database tables that contain this information can easily swell and harm the performance of the user interface, for example when URLs are generated automatically.
To reduce the accumulation frequency of URLs, Precise for Web lets you group consecutive URLs by pattern by editing the data-patterns registry element. Each of the data-pattern elements (urls, pages, titles, domains, and user-defined-transaction-name) can be specified with methods. The available methods are prefix, suffix, prefix-by-key, and regex.
You can add as many methods and patterns to any of the sections (<urls>, <pages>, <titles>, <domains>, <user-defined-transaction-name>).
| Info |
|---|
...
The tags <methodN> and <patternN> should be numbered so that 'N' is replaced with a consecutive number. |
| Info |
|---|
...
In URLs and Pages, pattern definitions only work on the path part. For example, in the URL |
...
is |
The following table describes the available methods.
Table 9-29 methods
Method Description
prefix Take only the defined prefix.
For example: <pattern1>abraham</pattern1> - For URL 'abraham123.html' you will see
'abraham%'.
suffix Take only the defined suffix.
For example: <pattern1>html</pattern1> - For URL 'abraham123.html' you will see '%html'.
prefix-by-key Take text up to the defined key (not including that key).
For example: <pattern1>;jsessionid</pattern1> - For URL 'abraham123.html;jsessionid' you will see 'abraham123.html%' (if showReplaceChar="false", you will get 'abraham123.html').
regex Use the given regular expression to change the given URL.
For example: <pattern1 replace="$1">service(.*)</pattern1> - For URL 'service123' you will get '123' (for more on regular expressions, consult your support representative).
The following code is an example of the element’s content for an URL element when all the grouping methods are activated:
<data-patterns>
<urls>
<execute>true</execute>
<methods>
<method1>
<name>prefix</name>
<patterns>
<pattern1>/redirectlogon.html</pattern1>
</patterns>
</method1>
<method2>
<name>suffix</name>
<patterns>
<pattern2>ads.com</pattern2>
</patterns>
</method2>
<method3>
<name>prefix-by-key</name>
<patterns>
<pattern3>:jsessionid=</pattern3>
</patterns>
</method3>
<method4>
<name>regex</name>
<patterns>
<pattern4 replace="$1">\d+: (.*)</pattern4>
<patterns/>
</method4>
</methods>
</urls>
</data-patterns>
When URL pattern prefix grouping is activated, a percentage sign (%) is added at the end of a URL. For example, the URL /redirectlogon.html/121231245 is saved in the database as /redirectlogon.html%.
To group consecutive URLs by pattern
1. Open the relevant registry file (instance regisrty, server registry, or focal-point registry) and find the data-patterns element (If it does not exist, you can add it as appears in the server registry)
2. Edit the data-patterns element in the following way:
• Set the required <execute> elements to true.
• Choose the method (prefix, suffix, prefix-by-key, or regex) in the required element (urls, pages, titles, domains).
• Define the URL patterns in the <pattern> elements. You can include as many <pattern> elements as required.
• If you choose the regex method, use the replacement string. For example:
<pattern replace=“$1”>\d+: (.*)</pattern>
3. Save and close the file.
4. Restart the Precise for Web server-side and dynamic instrumentation agents monitoring the relevant environment.
...