| Oracle® Real User Experience Insight User's Guide Release 5.1 for Linux x86-64 Part Number E14821-03 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 5.1 for Linux x86-64 Part Number E14821-03 |
|
|
View PDF |
This chapter describes how to manage the basic Web site configuration used for monitoring. This includes specifying the required Web sites, and the page content and site error checks to be implemented. Other processing settings include such things as the average session duration, the cookie settings to be used, and the scheme for identifying users.
In order to accurately monitor your Web environment, RUEI needs to know and understand the cookie technology your Web site is using. This will either be a standard technology (such as ASP or ColdFusion), or a custom implementation. In the case of the latter, you will need to provide the system with information about it. Note that you can define a maximum of five cookie technologies for use when monitoring.
Note that if you do not specify a cookie technology, the network IP address and browser combination are used to track the visitor session. In the case of multiple users behind the same proxy server visiting your Web site, they will all be recorded in one single session. Hence, the accurate specification of the cookie technologies used within your Web site is recommended.
To specify your cookie technology, do the following:
Select Configuration, then Applications, and then Session tracking. The currently defined cookie settings are displayed. This option is only available to the Administrator. Click Add new cookie or an existing cookie definition. The dialog shown in Figure 7-1 appears:
Select the cookie technology used in your Web environment from the list. If you are using a non-standard technology, select "custom".
If you selected "custom", you are required to specify the name of the cookie used by your organization. When ready, click Save.
Any changes made to this setting are applied after a short interval (typically, 5 - 10 minutes), and are then visible within the Reporter system shortly after this.
Optionally, you can use the Named servers facility to obtain more detailed insight into the visitors to your monitored Web sites. This facility allows you to assign ranges of server IP addresses (specified in the netmask) to a Web server group, and to individual Web servers. For example, a server group could be a department or data center, and the server name refers to specific Web servers within that group. In this way, you can easily identify the location of specific Web servers when problems (such as failed pages) occurred.
To use this facility, do the following:
Select Configuration, then Applications, and then Named servers. This option is only available to users with IT Analytical level access. The currently defined named servers are displayed. Click « Add new server ». The dialog shown in Figure 7-2 appears:
Use the fields within the dialog to specify a range of IP addresses or a specific IP address within a netmask, and the associated Web server and its group. When ready, click Save.
Uploading a List of Named Servers
Optionally, you can click « Upload list » to merge a list of named servers with those that are currently defined. The file must contain only one entry per line, and the information for each server (as shown in Figure 7-2) must be tab-separated. Note that any definition in the merged file for an already defined named server overwrites its existing definition.
Any changes made to the named server locations are applied after a short interval (typically, 5-10 minutes), and are then visible within the Reporter system shortly after this.
The Web server information collected during monitoring can be viewed in the Data browser via the all pages, key pages, all functions, failed functions groups, failed URLs, failed pages, and the slow URLs groups. The server IP identifies the specified IP addresses, and the server group refers to the group name. By zooming into a server group, you can view the individual Web server names that comprise the group. Zoom in again, and you can view the individual IP addresses assigned to that Web server.
Optional, in some instances, you want to be able to enhance the information associated with visitor IP addresses. This is especially useful when monitoring Intranet traffic and you want to be able to use your own client classification.
To use this facility, do the following:
Select Configuration, then Applications, and then Named clients. The currently defined named servers are listed. Click « Add new client ». This option is only available to IT users with Analytical level access. The dialog shown in Figure 7-3 appears.
Use the fields within the dialog to specify a range of IP addresses or a specific IP address within a netmask, the client, and their associated group (for example, company department). When ready, click Save.
Uploading a List of Named Clients
Optionally, you can click « Upload list » to merge a list of named clients with those that are currently defined. The file must contain only one entry per line, and the information for each client (shown in Figure 7-3) must be tab-separated. Note that any definition in the merged file for an already defined named client overwrites its existing definition.
Any changes made to your defined named clients are applied after a short interval (typically, 5-10 minutes), and are then visible within the Reporter system shortly after this.
The settings you specify for monitored traffic may need to be fine-tuned in order for you to receive what you regard as the most reliable data. In order to do this, it is recommended that you periodically review the relevant report for these settings. In addition, you can view configuration details by selecting Show statistics from the Configuration menu. An example is shown in Figure 7-4:
The following information is reported:
The Hits section indicates the objects associated with a defined application (Defined page), those not part of a defined application (Undefined page), and those not part of a page (Spurious).
The Pages section indicates the detected pages associated with a defined application (Defined), and those not associated with a defined application (Undefined). Note that undefined pages are not recorded, and further information is not available about them.
The Pageviews section indicates the pages viewed within cookie-tracked sessions (With session), and those for which no cookie information was available (Without session).
In addition, there are a number of advanced settings that are available to refine the accuracy of the report data. These are described in the following sections.
For information older than 15 minutes, reliable information about the number of concurrent sessions is available. However, for real-time monitoring of current visitors on the dashboard, the number of concurrent sessions needs to be estimated.
Therefore, the average duration time setting is used to calculate the number of concurrent sessions within a logged period of five minutes. It specifies how long the average unique visitor stays on the site. By default, this is configured to be 150 seconds.
To modify the average session duration setting, select Configuration, then Applications, then Advanced settings, and then Average session duration, and click the currently defined value. This option is only available to the Administrator.
Important:
Normally, it will not be necessary for you to change this setting. However, if you feel that the level of concurrent sessions reported on the dashboard is not reliable, you may wish to change this setting. If so, it is recommended that you review the average session duration information available in the All sessions group (see Section 1.3.2) of the Data browser, and use this as the basis for any new setting.Hit failures are recorded in the failed URL group. Because hit failures can occur for a wide variety of reasons, you can control what is recorded. For example, it is unlikely that you want incidents related to remote robot searches to be recorded. Do the following:
Select Configuration, then General, then Advanced settings, then Ignore failed URLs. This option is only available to the Administrator. The Ignore failed URLs dialog shown in Figure 7-5 appears.
Specify any file names that should be ignored within the failed URL view. That is, they should not be seen as errors. For example, robots.txt, or favicon.ico. Note the specified objects are removed from the listed object URLs. When ready, Click Next.
The new setting is applied after 10 minutes. A short period after this time, the changes you have specified are visible in the Reporter interface.
You can control whether you want all, some, or no URL arguments recorded within the lowest level page URL dimension. Do the following:
Select Configuration, then General, then Advanced settings, and then Page URL argument filtering. This option is only available to the Administrator. The Page URL argument filtering dialog shown in Figure 7-6 appears.
Figure 7-6 Page URL Argument Filtering Dialog
Use the list to select the appropriate filter. The default is "allow-all". That is, record all arguments. When ready, click Next.
If you selected the "allow-some" filter, the next dialog requires you specify which arguments should be recorded. Separate multiple arguments with an ampersand (&) symbol. When ready, click Next.
The new setting is applied after 10 minutes. Shortly after this time, the changes you have specified are visible in the Reporter interface.
Note:
It is recommended that you make use of this facility if session or other random arguments are included in your page URLs. Otherwise, the content of page-based views (such as all pages or failed URLs) can become very large.Within RUEI, session information is reported within the All sessions group. By default, a visitor session is considered terminated if the visitor has been inactive for longer than the defined session idle time (by default, 15 minutes). In addition, a visitor session is assumed to last no longer than the session flush time (by default, 60 minutes). After this time, its details are written to the All sessions group (see ). Hence, by default, information about the visitor's session is only available within the All sessions group after the visitor has been idle for more than 15 minutes, or their session has lasted longer than 60 minutes.
However, more immediate session-related information is available within the Session diagnostics facility (described in ). Here, information about a visitor session is available appropriately five minutes after the start of a session. See also Section 3.2.1, "Real-Time and Session-Based Data" for important information about how sessions are reported.
In order to optimize the reporting of sessions, two advanced settings are available:
Session idle time: specifies the period (in minutes) of inactivity after a visitor session is regarded as terminated. The default is 15 minutes.
Session flush time: specifies the period (in minutes) after which information about a session is written to the All sessions group. The default is 60 minutes. Be aware that increasing this period also increases the amount of memory required to store session information prior to it being written to the All sessions group.
Note:
Because of the impact these settings can have on the performance of your installation, as well as the accuracy of the reported data, it is strongly recommended that you only change them under guidance from Customer Support.Specifying Session Settings
In order to control session-related settings, do the following:
Select Configuration, then General, then Advanced settings, then Session processing, and then either Session idle time or Session flush time. A dialog similar to the one shown in Figure 7-7 appears.
Figure 7-7 Change Session Reporting Dialog
Specify, in minutes, either the length of inactivity required to elapse before a session is considered terminated (the session idle time), or the period after which session information is written to the All sessions group (the session flush time). The defaults are 15 and 60 minutes, respectively. When ready, click Save.
Any changes you specify to either of these settings take place within five minutes.
The emergence of Web services has become one of the most important advances in the technology industry. Organizations are increasingly integrating enterprise applications to exchange information such as purchase orders, inventory levels, shipment notices, and interbank transactions, to name but a few.
Understanding Web services
It is important to distinguish this new breed of Web services from traditional ones. Generally, a Web service was any service available over the Web (such as search engines, language translators, weather guides, maps, and so on). However, these types of Web services required some human intervention.
A Web service is defined by the W3CFoot 1 as "a software system designed to support interoperable machine-to-machine interaction over a network". It implements a clearly defined business function that operates independently of the state of any other service. It has a well-defined contract with the consumer of the service. Services are loosely coupled - a service does not need to know the technical details of another service in order to work with it - and all interaction takes place through the interfaces. Using this technology, the service provider simply exposes a service on the Web, publishes the interface and service naming specifications, and waits for a connection.
Services are made available through service descriptions. They describe how to call the service, and what information is required to request the service and get a response. The data exchange takes a request-response pattern. RUEI primarily supports the monitoring of XML-SOAP and similar messages.
Defining Web services
To define a Web service, do the following:
Select Configuration, and then Services. The currently defined Web services are listed. Click New services. The dialog shown in Figure 7-8 appears.
Specify a name for the service. This is the name that will be used for the defined service within reports and the Data browser. The name must be unique across services, SSO profiles, suites, and applications. Note that services cannot be renamed later.
Use the remaining fields to specify the scope of the service. This is defined in terms of partial service URLs. Note that as you enter this information, you can see the effect of your definition through the Filter preview column.
The highest level filter is the domain. You can specify a partial URL instead of, or to refine, a domain. It is not possible to specify a service name and leave all the other fields blank. While the use of a wildcard character (*) is supported, all other specified characters are interpreted as literals. Note it is not possible to specify the wildcard character and no other information for domain name and URL argument combinations.
Note:
It is recommended that filter definitions should be mutually exclusive across services, SSO profiles, applications, and suites. For example, do not define a service filtered on the domain "us.oracle.com" and then another service, suite, or application filtered on "us.oracle.com/application_servlet". The use of non-mutually exclusive filter definitions can lead to unpredictable results. See Section 7.6, "Controlling Rule Ordering Within RUEI" for information about how you can influence the order in which filters are applied.You can also specify an argument within the partial URL that must be matched. Note that if you use this facility, both the argument and argument name must be complete in order for them to be matched to page URLs. That is, partial matching is not supported. When ready, click Next. The dialog shown in Figure 7-9 appears.
Use this dialog to specify how the service should be identified and reported. It is important to understand that while applications (see Section 6.2, "Defining Applications") have the structure application » group » page, services have the structure service name » function group » function name. Note that functions that do not belong to a defined group are regarded as belonging to the default group "generic". Note that if you specify a group naming scheme, this must be found within the function call for it to be reported.
When ready, click Finish. The service definition you have specified is displayed. An example is shown in Figure 7-10.
Refining Your Service Definitions
Once you have defined your service, you can modify its associated function scheme. Within the Identification section, you can click « Add new filter » to specify additional filters for the functions that should be associated with the service. A function will be assigned to a service when one of the defined filters is matched. You can also modify an existing filter definition by clicking it. In each case, you can select from the same filters as shown in Figure 7-8. The service overview is updated to reflect your additions or modifications.
For reporting purposes, if the user/client ID is not found, client identification falls back to the SSL certificate (if there is one). The common name (CN) portion of it is used. If this is not found, the client ID is reported as Anonymous.
Specifying the IP Address Source
When reporting on user visits, the client IP address is, by default, fetched from the TCP packet. However, when the RUEI system is placed in front of a NAT device, it may be more useful for the client IP address to be obtained from a specific header. This is fully explained in Appendix B.
By default, function calls that have been identified as belonging to a service through its URL definition, but for which no classified name has been found, are discarded and not reported. However, if you want these unclassified calls to be reported, use the Report unclassified calls check box shown in Figure 7-10.
Because hits not identified as belonging to the service are identified as unclassified calls, incorrect or insufficiently defined function calls will be identified as unclassified. Note that unclassified calls are reported in the relevant Data browser group under the category "Other".
In order to assess a function's responsiveness, RUEI assigns a satisfaction level for each function. This specifies the end-to-end time (that is, the sum of all server and network times) for the selected function calls in the service. This represents the end-to-end time (in seconds) required to call the function. That is, the total server and network times. The default is four seconds, and can be specified to within three decimal places (for example, 2.567). This is equivalent to the page loading threshold described in Section 6.2.6, "Specifying Page Loading Satisfaction".
Sometimes you want to detect strings associated with functions and have them reported as errors. For example, if a function responds with the message "Requested item is out of stock". Note that:
All functions within the selected service are searched for the specified error string. It is not possible to limit the search to specific functions.
Functional errors can be specified in terms of a literal search string or an XPath expression, and whether the server response or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures".
Displayed page texts that match your specified error text strings are reported with the page content result "error string: error search string".
To define a functional error in a service function that you want monitored, do the following:
Select Configuration, then Services, and then select the required service. The service overview (similar to the one shown in Figure 7-10) appears. Click the Functional Errors overview tab. The currently defined functional errors are displayed. Click « Add new functional error » to define a new error, or click an existing one to modify it. The dialog shown in Figure 7-11 appears.
Specify whether the search should use a literal search string or an XPath expression, and whether the server response or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures". When ready, click Save.
Alternatively, you can click Upload list to upload a file of functional errors you want detected. This is the same procedure as for uploading a list of application errors described in Section 6.2.7, "Trapping Application Functional Errors". The file must contain only one error string per line. Be aware that these messages will be regarded as literal strings to be searched for in the response content.
In order to track the clients using functions, the client identification mechanism used within a service needs to be defined. It can be specified in terms of URLs, XPath expressions, cookies, and whether the server response or client request should be searched. To do so:
Select Configuration, then Services, and then select the required service. The service overview (similar to the one shown in Figure 7-10) appears. Click the Client ID tab. The currently defined client ID sources are displayed. Click « Add new source » to define a new source, or click an existing one to modify it. The dialog shown in Figure 7-12 appears:
Specify whether the search should use a literal search string or an XPath expression, and whether the page URL, cookie, server response, or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures". When ready, click Save.
By default, the order in which application, SSO profile, suite, and service filters are matched within RUEI is determined by the level of detail specified in the definition. That is, the definitions with the most information specified for them are applied first. However, sometimes you may want to modify the order in which filters are applied.
For example, you want to monitor network traffic for the domain "shop.oracle.com". You have defined two applications: one for the domain "shop*", and one for the domain "*oracle*. Because the string "*oracle*" is longer than the string "shop*", it is applied first. However, you want page identification for the "shop*" domain to take priority. You can use the rule ordering facility to override the default rule matching order, and specify the order in which pages for the required domains should be applied.
Note:
It is recommended you use the default rule ordering, and that you define your applications, SSO profiles, suites, and services with sufficient information for them to be mutually exclusive.To use the rule ordering facility, do the following:
Click the Configuration tab, select the Configuration menu option, and then the option Edit ruling orders. Note this option is only available to users with Full IT access permissions. A dialog similar to the one shown in Figure 7-13 appears.
Use the Automatic rule ordering check box to specify whether the rule ordering is automatically derived from the currently defined applications, SSO profiles, suites, and services. As explained earlier, by default, the definitions with the most information specified for them are applied first. This is check box is automatically unchecked if you use the Up and Down controls to specify the order in which the rules should be applied. If you re-check it, the filter ordering is automatically reset to the default.
Note any changes you make are immediately put into effect. When ready, click Close.
Important:
Be aware that if you modify the default rule ordering, and then define a new application, SSO profile, suite, or service, its associated filter is immediately placed at the bottom of the current rule ordering. Therefore, you should always review the rule ordering after the creation of new filters.Footnote Legend
Footnote 1: The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
