|Oracle® Real User Experience Insight User's Guide
Release 6.5.2 for Linux x86-64
Part Number E20330-01
|View PDF · Mobi|
This chapter explains the tasks performed by an Administrator. These include monitoring the status of the system, performing backups and upgrades, working with the event log, managing system users, and configuring data retention policies.
An Administrator can check the system's condition, and receive automatic status monitoring messages on the Status page. To reach this page, select System, and then Status. An example is shown in Figure 9-1:
Through the Status page, you can review the status of the attached Collectors and the log file process, the current level of processing within the system, whether there is sufficient space within the users' database table space, and the event log. You can also configure which users are notified (and how) about a system status error.
Each of the components shown in Figure 9-1 indicate their current status. During normal operation, this should be reported as "OK". However, if one or more component reports status "Error", use the information in Table 9-1 to identify and resolve the problem.
Log file processing
Database space available
Be aware that the system status indicator shown in Figure 9-1 is only updated when the browser screen is refreshed. If one or more of the system processes are found to be failing, a system alert can be generated (as described in Section 9.4, "Configuring System Failure Alerts"). Therefore, the situation can arise that a process is shown temporarily as failing (with a red cross), but no alert is generated. This is because the system status indicator has returned to normal by the time the system processes are checked.
Due to this design, when an alert is triggered, it is recommended that you regard it as a warning that the system is starting to fail. A failure can be the result of a system delay that is larger than the default boundaries. For example, the latency between a hit on the monitored line, and the moment the information based on that hit is available in the Reporter, may not be long enough. This latency may be out of boundary within a high-traffic environment. A failure may also be the result of a temporary peak in traffic. However, if this condition persists, it is recommended that you review the monitored traffic level.
You can view the status of each Collector attached to the system by selecting System, then Status, and then Collector status. It opens the Network data Collectors window. An example is shown in Figure 9-2.
The System (localhost) refers to the Collector instance on the Reporter system. Other Collectors within the network are represented by their IP address. For each Collector, the following menu options are available:
View statistics: displays a detailed report of the traffic monitored by the Collector. An example is shown in Figure 9-3. This is described in more detail in the following section.
Configure: opens a sub-menu through which you can configure security-related settings for the selected Collector. These are described in Chapter 8, "Managing Security-Related Information."
Edit description: allows you to modify the brief description specified when the Collector was registered (see Section 9.2.2, "Attaching New Collectors"). This can be useful for providing additional information about the Collector system. For example, where the Collector is patched in the organization's network, or the contact information for the system's administrator.
The information shown in this window (Figure 9-3) refers to the traffic monitored since midnight for the selected Collector, or the counters were reset. The Uptime field in the bottom left-hand corner of the window shows the time the Collector has been running. The uptime is reset when the Collector is restarted to update its configuration. You can reset all HTTP request counters shown in the window by selecting Reset counters from the View menu. Note that the counters will be reset the next time a network packet is detected. Hence, on an installation with no network traffic, the counters will never be reset. The display is automatically refreshed every two seconds.
The tabs available in the top-left part of the part of the window provide a detailed breakdown of the traffic monitored by the selected Collector. They are explained in Table 9-2.
Provides information on the available network interfaces for data collection. The number of interfaces and their status depends on the system configuration. Note that you will not see any "normally" configured interfaces. For each available interface, the name (in the form
Provides a breakdown of the raw packet data transmitted over the monitored ports in terms of its protocols (such as IPv4 and ARP), and the number of measured frames. The "Truncated" listing indicates corrupted or dropped frames.
Provides an analysis of the TCP stream. The following counters are reported:
The following network error meters are also shown:
In the event of any of the above meters indicating problems, it is recommended that you use the TCP diagnostics facility to isolate possible causes.
The use of this facility is described in Appendix P, "Verifying Monitored Network Traffic".
Provides an analysis of the monitored HTTP stream. In particular, the type of requests (such as GET or POST) they contain.
Reports the encryption method used for packets of encrypted data. In particular:
Errors related to SSL key management are reported. In particular:
Information about (currently) unsupported encryption:
The Decrypt errors gauge indicates the connections which could not be decrypted. This can be caused by several reasons, including the master key could not be decrypted, session keys were incorrectly computed, or a segment could not be decrypted.
Provides a breakdown of the monitored encrypted data in terms of the employed encryption algorithm. The Used column indicates the amount (percentage) of total monitored SSL encrypted traffic that used an encryption algorithm, and the Errors column indicates the percentage of measured SSL encryption which failed (that is, could not be read).
Reports on the impact to the Collector. Note that if the peak load nears 100%, immediate action should be taken to prevent data being dropped by the Collector. See Section 8.2.2, "Limiting Overall Traffic" about traffic sampling. If this does not provide a solution, it is also recommended that you contact Customer Support. The Collector's memory usage is also indicated. The maximum memory threshold is 30% for Reporter/Collector systems, and 70% for Collector only systems).
Be aware that SSL and Oracle Forms traffic are particularly sensitive to disruptions in the TCP packet stream. This is because they require state information to be maintained for the duration of the connection, and any lost packets can cause that information to be lost, preventing RUEI from accurately monitoring and reporting the connection.
Therefore, you should ensure that each Collector is connected to a reliable network device, such as a TAP. In addition, it is strongly recommended that you regular review the information available through the Collector Statistics window to verify the integrity of the TCP packet stream. Particular attention should be paid to the reported TCP and SSL connection errors.
To attach a new Collector to the system, select Register remote Collector from the Configuration menu. The Register Collector dialog shown in Figure 9-4 appears.
Specify the IP address of the new system and, optionally, a brief description. For example, the contact information for the system's administrator. When ready, click Register. See the Oracle User Experience Insight Installation Guide for more information about the configuration requirements for Collector systems.
Note:This facility is also available by selecting System, then Status, and then Collector status. Note that users who are not authorized as an Administrator will receive a read-only version of this interface.
In order for RUEI to correctly report on monitored network traffic, it must understand the encoding used within that traffic. RUEI can monitor network traffic containing data in a wide variety of character encoding standards. Table G-1 provides a complete list of the encoding standards supported by RUEI.
Generally speaking, RUEI first attempts to use the document encoding specified for the corresponding HTML document. That is, so-called auto-detection. If this fails to produce a satisfactory result, the Collector encoding (if specified) is used to decode URL and POSTed form arguments.
Be aware that the Collector encoding is not a manual override to the document encoding. Rather, it specifies the encoding that RUEI should attempt to use once the document encoding has failed to satisfactorily decode the URL arguments. If the Collector encoding also fails to produce a satisfactory result, the arguments are reported in their original (non-decoded) format.
To specify the URL argument and Collector encoding, do the following:
Select Configuration, then General, then Advanced, and then Collector encoding. A panel similar to the one shown in Figure 9-5 appears.
Click the currently defined Collector encoding for the required Collector. By default, no Collector encoding is defined. The dialog shown in Figure 9-6 appears.
Use the Collector encoding menu to specify the encoding to be used for URL arguments within application filters, and when auto-detection fails. The list of available encodings is equivalent to that shown in Table G-1.
When ready, click Save. Any change you make to this setting takes effect almost immediately.
When using this facility, you should pay particular attention to the following points:
This setting is only applicable to the decoding of URL arguments within application definitions (see Section 6.2, "Defining Applications"). Content-based reporting (for example, functional errors) is not affected by this setting. In addition, the selected Collector encoding applies across all applications, pages, and domains monitored by the selected Collector.
If you are using international characters sets within your Web sites, it is strongly recommended you carefully review your Web site content, and the encodings used for it. In addition, you should regularly review the reporting of full URL arguments to ensure that they are correct.
In addition to being notified about KPI and SLA violations, you can also configure alerts for system failures. It is strongly recommended that you do so. System alerts not only enable you to take prompt action in the case of system problems (such as a failing Collector), but can also help indicate serious external issues (such as a denial-of-service attack). To do so, select System, then Status, and then Status notification. The dialog that appears is similar to that described in Section 5.5.1, "Alert Profiles".
Basically, any event that makes one (or more) of the indicators shown in Figure 9-1 report the status warning or error will trigger a system alert. For example, a Collector status alert might indicate that a Collector is unavailable or failing.
It is recommended that you pay particular attention to the following points:
The configured recipients are also notified about database and disk space utilization warnings and errors (as described in Section 9.5, "Configuring Database and Disk Space Limits and Alerts").
The system status alerting does not consider any alerting schedules or escalation levels. When configuring alerts, ensure all recipient information (such as E-mail addresses and telephone numbers) is correctly specified. Note also that the system status check is run every 10 minutes. Therefore, if a system failure is indicated in Figure 9-1, you may not immediately receive an alert about it, but when the scheduled system check is run.
In the case of Event log alerts, it is recommended that you review the reported events, as described Section 9.9, "Working with the Event Log". Be aware that Event log warnings or errors must be marked as read in order for the Event log indicator to return to the status OK.
In the case of Collector status alerts, it is recommended that you use the Collector Statistics window (described in Section 9.2.1, "Working Within the Collector Statistics Window") to troubleshoot the issue.
In the event of other (or persistent) errors or warnings, please contact Customer Support.
As with KPI and SLA violations, you can configure system event notifications to be sent via SNMP traps. In this case, each event reported in the Event log (described in Section 9.9, "Working with the Event Log"), becomes a separate SNMP trap.
To configure SNMP traps for system events, do the following:
Select System, then Status, and then Status notification. A dialog similar to the one shown in Figure 5-9 appears.
Click the SNMP tab. The dialog shown in Figure 9-7 appears.
Ensure that the Enabled and Event log monitoring check boxes are checked. Note that if not, no event SNMP traps for system events are generated.
Use the Event log sending limit field to specify the maximum number of SNMP traps that will be send within a 1-minute period. This feature is useful to prevent flooding the recipient SNMP manager with excessive numbers of traps. For example, consider the case in which 500 events are reported within a 1-minute period. In principle, each of these would become separate SNMP traps. However, if the send limit is set to 100, only the most serious 100 events would result in SNMP traps being generated.
See Section 5.5.6, "Using SNMP Notifications" for information about using the other fields in the dialog.
Download the Management Information Base (MIB) definition and incorporate it into your address book of managed objects. It contains necessary information about how the received SNMP messages should be interpreted.
In order to ensure the uninterrupted operation of your system, limits are set to the maximum level of available database and disk space utilization. When the maximum database utilization level is reached, no further data is written to it until an administration mechanism has brought the database's size back to within its permitted boundary. Similarly, when the maximum disk space utilization is reached, no further data (in the form of log and enriched data exchange files) is written to the file system until an administrator process has deleted existing files. In addition, you can also configure alerts to be generated when either of these problems may be about to arise.
Important:It is strongly recommended you only modify the default settings if you have a sound knowledge of RUEI, and clearly understand the use and effect of these settings.
To define database or disk space thresholds, do the following:
Select Configuration, then General, then Advanced settings, and then Database/disk space usage. The thresholds selection panel shown in Figure 9-8 appears.
Select the required threshold. A dialog similar to the one shown in Figure 9-9 appears.
In the case of an alert threshold, use the dialog to specify the maximum database or disk space utilization before an alert is generated. The generated alert is sent to the same recipients, and uses the same notification mechanism, as that defined for system failure alerts (described in Section 9.4, "Configuring System Failure Alerts"). In the case of a stop threshold, specify the maximum database or disk space utilization before database processing or data collection is stopped. When ready, click Save. Any changes you specify take effect immediately.
When defining threshold values, be aware of the following:
The maximum permitted setting for stopping the database or disk space utilization is 95%. This is because if the available disk space becomes completely (100%) full, other components on the system may no longer work. In addition, remote logging onto the system may no longer be possible. Similarly, if the database is allowed to become completely full, the administrative mechanism used to reduce its size will no longer work.
The specified thresholds refer to all partitions used for RUEI. That is,
/var/opt/ruei, and any mounted partitions under it. The alert and stop mechanisms will be triggered if at least one partition reaches its specified threshold.
Checking of the defined thresholds is not performed continuously, but every 10 minutes. Hence, it is possible that by the time a check is performed, and an alert is issued, the database or disk space utilization is already higher than the specified threshold. For this reason, it is recommended that you set threshold values slightly lower than their intended target. For example, instead of setting the disk space stop threshold at 95%, set it to 93% or 94%.
An alert notification threshold cannot be higher than its associated stop threshold. For example, if the database stop threshold is 95%, the alert threshold cannot be higher than this.
By default, alert thresholds are 85%, and stop thresholds are 95%.
There is also a Linux operating system limit of 95% on disk space usage. If this limit is reached, only the
root user can write to disk. Because RUEI does not have this privilege, further utilization of disk space is prevented.
The availability of specific data within the Data Browser, as well as reports based on that data, depends on the amount of available disk space on the Collector and Reporter systems, as well as the amount of database space available on the Reporter system. This is illustrated in Figure 9-10.
Data gathered during monitoring is first written to log files, stored on the Collector system. These files are copied to, and processed by, the Reporter to populate the database that holds the multi-dimensional data structure viewable through the Data Browser and reports. These temporary log files are automatically removed from the Collector system after three days, and from the Reporter system (by default) after seven days. Note that data masking options (described in Section 8.4, "Masking User Information") can be specified to omit the logging of sensitive information.
The log files are used to created the Full session replay (FSR) data store. These files are regularly filtered to create the Error page replay (EPR) data store. The EPR files only contain information about failed events (that is, failed pages, objects, and function calls). Both the FSR and EPR data is held on the Collector system.
The size of the database user quota for the Reporter system is configurable during installation. By default, it is set to 200 GB. It is important to understand that data is consolidated when it is no longer required by the Reporter's defined retention policy. For example, by default, daily information about the last 32 days is retained. Daily information older than this is consolidated into the monthly information. Similarly, monthly information is consolidated into yearly information. Finally, if the enhanced data exchange facility has been enabled (see Section 9.20, "Exporting Enriched Data"), an export file is created every five minutes. The XML-based export files are, by default, retained for seven days.
By default, RUEI keeps information on a daily, monthly, and yearly levels for 32 days, 13 months, and five years, respectively. Hence, for example, the oldest daily information will be dropped after 32 days. In addition, temporary log files are kept on the file system for approximately seven days. Be aware that a new RUEI installation will grow quickest during the first 32 days. After that time, the growth rate will slow. Of course, the growth rate depends on monitored traffic levels.
By default, information about failed URLs, pages, and service calls is kept for 15 days. If available, it can be viewed via the Session diagnostics replay facility (described in Section 3.10, "Working With the Diagnostics Facility").
The settings described in the rest of this section allow you to optimize the disk and database utilization of your RUEI installation to meet your operational requirements.
To specify the data retention policies used by the Reporter system, do the following:
Select Configuration, then General, then Advanced settings, and then Reporter data retention policy. A screen similar to the one shown in Figure 9-11 appears.
As can be seen in Figure 9-11, every setting that has an impact on the database has a corresponding Database usage listing. This indicates the total database space (in gigabytes) currently used for the item, and the proportion this represents of the database's maximum permitted size. The projected database utilization (based on monitored traffic levels) is also indicated. Information about disk space utilization is available within the dialog boxes for individual settings.
Select the required setting. The following settings are available:
Maximum database size: specifies (in gigabytes) the maximum amount of data allowed to be stored in the database. Note that you will need to specify the database SYSTEM user password to change this setting.
Failed event data retention: specifies the period for which information about failed URLs, pages, and service calls is available. The default is for the last 15 days. If information is not available in the Session diagnostics replay, you may need to review this setting. Note this setting is linked to the Replay error page storage size setting (described in Section 9.6.4, "Defining Collector Data Retention Policies"). If you intend to increase the Failed event data retention setting, it is recommended you also increase the Error page replay storage size setting in order to facilitate this. Note also this setting has a high impact on disk space usage, and any change to it should be carefully considered in terms of anticipated network traffic.
Session diagnostics retention: specifies the maximum number of days for which session diagnostics information is available. This facility is fully described in Section 3.10, "Working With the Diagnostics Facility". The default is the last seven days, and the minimum is the last two days. This setting has an impact on database and disk space usage. The reported database usage is not included in the reported disk space usage.
Enriched data exchange retention: specifies the maximum number of days for which information is available via the Enhanced data exchange facility. This facility is fully described in Section 9.20, "Exporting Enriched Data". The default is seven days. That is, data is available for the last six days, plus the current day. The maximum retention period depends on the available database storage capacity.
Be aware that this setting is applied on the full-day boundary (at approximately midnight). Therefore, if you decrease the number of days (for example, from seven to five), the setting change will take effect within 15 minutes, and the data for days five and six will be purged from the database.
Note that if set to one day, the previous day's data is deleted at approximately midnight, and only a limited amount of information is available for the current day. Therefore, in order to have access to the previous day's data after midnight, a retention period of at least two days must be specified.
Daily data retention: specifies the period for which daily information is available. The default is the last 32 days. The maximum period for which daily data may be kept depends on the monthly setting.
Monthly data retention: specifies the period for which monthly information is available. The default is the last 13 months. The maximum period for which monthly data may be kept depends on the yearly setting.
Yearly data retention: specifies the period for which yearly information is available. The default is the last five years. The minimum setting depends on the daily setting, while the minimum number depends on the monthly setting.
Maximum data group size: specifies the maximum size to which data groups are permitted to grow. This setting is fully described in Section 9.6.2, "Setting the Maximum Data Group Size".
A dialog similar to the one shown in Figure 9-12 appears.
Use the dialog's control to specify the retention policy for the selected option.
For most settings, you can click Calculate to see the effect of your selection on database or disk space usage, as applicable.
When ready, click Save. Note that changes to disk space allocations take effect after approximately 10 minutes, while changes to database allocations only take effect after midnight.
Note:It is recommended that if you want to increase the amount of data kept, you start with the low-level data retention setting and work towards the high-level data retention setting. If you want to decrease the amount of data kept, start with the high-level data retention setting, and work towards the low-level data retention setting.
When specifying the high, medium, and low-level data retention settings, it is important to understand the dependency between stored days, months, and years. Use the following rules to calculate the required settings:
A month is assumed to have 30 days. The number of months that must be stored for a specified period of days is the number of days divided by 30 (rounded up to the next hole integer), plus one. For example, 33 days would require 33/30 (1.1 rounded up to 2), plus 1. Hence, three months.
The number of required years for a specified period of months is the number of months divided by 12 (rounded up to the next whole integer). For example, 11 months would require one year, while 13 months would require two years.
For example: 900 days, 31 months, and 3 years.
This section provides a detailed explanation of how the default maximum Data Browser group sizes can be increased to provide more accurate reporting of monitored traffic. It is strongly recommended that you carefully review the information presented before modifying the default settings.
In order to optimize performance, individual groups are not permitted to grow to unlimited sizes. Each main group table has a maximum permitted size. By default, this is 600 MB. The size of the Failed URLs, Failed services, Failed pages, and Slow URLs groups are controlled by a maximum number of rows that can be added to the group's main database table during a 5-minute period. By default, this is 5000 rows. This fully described in Section 9.6.3, "Setting the Maximum Size of the Failed Groups". There is no limit for session diagnostics information.
The maximum size of a group is managed by condensing. This is the process by which the number of rows within the group table are reduced by moving the least used data to a "other" group. For example, rows within the client-browser/version dimension might contain a small number of rows for rarely seen Mozilla Firefox versions. In this case, the number of rows within the table is reduced by replacing these with a single "other(firefox)" row.
You might consider increasing the maximum size of the groups if the information you require is regularly being condensed. For example, required individual page names or user IDs are only reported as "other". Broadly speaking, this approach is recommended in the case of high levels of network traffic.
If the maximum group size is set to more than 150% (that is, 900 MB), it is strongly recommended that the database is configured as a remote database. The maximum recommended group size is 300%Foot 1 (that is, 2.0 GB). Be aware that response times to Data Browser queries and dashboard updates may take longer to process if the maximum group size is increased.
It is important to note that custom dimensions have a significant impact on the condensing process. Incorrect configuration of custom dimensions can result in excessive condensing. For example, product names (or similar highly selective attributes) should not be configured as custom dimensions because that will skew the condensing process. Specifically, each page/product combination becomes a separate candidate for condensing, and only high frequency combinations will remain visible after condensing.
After increasing the maximum group size setting, it is strongly recommended that you carefully review the effect of the change on the performance of the Reporter system. You should wait at least a full day, and select System, then Status, and the Data processing. Review the system load and determine whether the Reporter system can handle the additional processing overhead that increasing the maximum group size setting represents.
Important:Increasing the data group sizes can have a significant impact on overall system performance. Therefore, any changes to data group sizes should be carefully planned, and performed in manageable steps.
As explained earlier, the Failed URLs, Failed services, and Failed pages groups do not use the maximum group size setting. Instead, their size is controlled through the
event_max_fail setting. This specifies the maximum number of rows that can added to the group's main database table during a 5-minute period. By default, this is 5000 rows. For the Slow URLs group, the
event_max_slow setting is used, and specifies the number of the slowest URLs that are recorded within each 5-minute period. By default, this is 5000 rows.
Note that if you change the
event_max_fail or the
event_max_slow setting, you should also review the
daily_max_fail setting. This specifies the maximum number of rows that the groups' tables can contain. This is derived from the formula 288 *
event_max_fail. The default, is 1.4 million rows.
To modify the above settings, issue the following commands:
$ sqlplus /@$RUEI_DB_TNSNAME SQL> update UXS_CONFIG set VALUE='10000' where NAME='event_max_fail'; SQL> update UXS_CONFIG set VALUE='4320000' where NAME='daily_max_fail';
Note that the
event_max_fail setting is limited to a maximum of 10,000 rows.
To specify the data retention policy used by a Collector system, do the following:
Select Configuration, then General, then Advanced settings, and then Collector data retention policy. The panel shown in Figure 9-13 appears.
Use the View menu to select the required Collector. The System (localhost) represents the Collector running on the Reporter system.
For each currently defined application, suite, or service, the Oldest data column indicates how far back in time (in seconds, hours, minutes, or days) data for the indicated storage item is available. Typically, if the oldest entry is reported as 10 minutes, this indicates a very busy system that cannot store more than 10 minutes of data. The Newest entry column indicates how far back in time data to the indicated storage item was written.
The Log files item indicates the amount of disk space used on the Collector for the storage of temporary log files. Note that in the case of a local Collector, this will always be zero.
For each application, suite, or service, use the check box in the Options column to specify whether the creation of replay data should be enabled. By default, replay data is enabled. You are prompted to confirm any change you make. In addition, you are prompted to restart the Collector.
Click either the Error page replay store or Full session replay storage option for the application you want to modify. A dialog similar to the one shown in Figure 9-14 appears.
Specify the maximum amount of disk space that should be reserved for FSR or EPR data on the selected Collector for the specified application, suite, or service.
Note that the storage items for the "Unclassified" application refer to the maximum amount of disk space that should be reserved for network traffic that could not be associated with a particular application, suite, or service.
When ready, click Save.
Optionally, click the View security URL masking policies item. The dialog shown in Figure 9-15 appears. It highlights the currently defined URL prefixes masking actions, as well as the default masking action.
Alternatively, Instead of specifying the FSR and EPR data store sizes for individual applications, suites, and services, you can click the Set Full session replay store size for all applications or Set Error page replay store size for all applications icon. A dialog similar to the one shown in Figure 9-16 appears.
Specify the maximum amount of disk space for FSR or EPR data reserved on the selected Collector system for each application, suite, or service. When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon shown in Figure 9-13.
Note that when an application, suite, or service is deleted, its associated FSR and EPR data is not automatically removed from the Collector system. Instead, it remains available for viewing. If you want to delete this data, you should click the Remove icon shown in the Status column. You are prompted to confirm the data's deletion.
Be aware of the following:
When you reduce the replay disk space available to an application to an amount lower than that currently being used, the oldest data in store is removed to resize the replay data store. For example, imagine that you specify that an application's FSR data store should be reduced from 20 GB to 10 GB, and 14 GB is currently being used. In this case, the oldest 4 GB of the current FSR data is removed to resize the store.
If the EPR data store holds more days of data than the Failed event data setting, then the extra amount of data is not accessible via the GUI. Conversely, if the EPR size setting is lower than the number of days of failed event data, then Replay Viewer data will not be available for the extra period. However, the other views on the data will be available as usual, through the other Data Browser groups.
Note that if the FSR data setting is set to less than 15 minutes, the error replay facility may not function correctly. In addition, if set to zero, the EPR size setting can no longer be modified.
You can open an overview of the monitored network traffic by selecting System, then Status, and then Data processing. This provides you with immediate information about hits, pages, and session processing, as well as the system load. An example is shown in Figure 9-17.
Note the Available resource usage (%) item on the Performance tab indicates the current processing level. If this approaches 100%, it means a lag in the processing of data is starting to occur, and it is no longer possible to process data in real time.
Be aware that because this facility is based on application logic, non-application traffic (such as suites, services, and SSOs), are not represented in the displayed reports.
Important:In order for RUEI to correctly report on monitored traffic, it is strongly recommended that you regularly review this traffic summary. If necessary, review the RUEI configuration accordingly. For example, add additional cookie technologies. In addition, if the system is unable to track sessions, proper tracking of user flows will also not be available because user flow reporting requires session tracking.
You can create backups of your system's current configuration, and restore it if necessary. It is recommended that you regularly make backups. Note that backups only contain the system settings. For security reasons, SSL keys and collected data are not included.
To create or restore a backup, do the following:
Select System, then Maintenance, and then Backup and restore. The dialog shown in Figure 9-18 appears.
Use the radio buttons to selected the required operation. When ready, click Next.
Depending on how your browser is configured, you are either prompted to specify the location to which the zip file should be saved, or it is immediately saved to the defined default location.
Important:The generated backup file contains large amounts of information intended for Customer Support use only. Do not try to modify the file's contents. When performing a restore, be aware that all current settings are overwritten by the restored ones.
In addition to the status information described in Section 9.1, "Monitoring the Status of the System", RUEI maintains an event log. This contains a record of all system events. It enables both you and Customer Support to quickly identify and resolve any issues that might arise within your RUEI installation.
It is recommended that you regularly review the contents of the event log. If the event log contains any unread error messages, this is indicated by the Event log item within the Status panel being shown with an error icon. Be aware that while most events are reported almost immediately, Collector-related events can take up to five minutes to be reported.
To review the event log, do the following:
Select System, then Status, and then Event log. A dialog similar to the one shown in Figure 9-19 appears listing the most recent events.
Use the controls within the toolbar to scroll through the list of events. Each displayed log page can contain up to 100 reported events. By default, all event types are listed. However, the Severity menu enables you to restrict the displayed list to a selected category. The potential impact of an event is indicated through the following severities:
Info: indicates a user-triggered action. For example, the restart of a Collector, the creation of a new user account, or a configuration backup or restoration.
Warning: indicates an event that might cause your RUEI installation to fail. For example, the Reporter system is close to running out of disk space or a backlog is developing in the processing of log files.
Error: indicates an event that results in your RUEI installation not being fully operational. For example, a remote Collector is no longer available.
You can also use the Status menu to view all reported events, or restrict the displayed list to new (unread) events.
Note:If the same event occurred multiple times within a 5-minute period, this is indicated by a repeat counter shown within the reported event.
Optionally, you can select the following options within the Event menu:
Mark all events as read: new (unread) events are highlighted in bold. After being read, the highlighting is removed. Use this option to clear all highlighting within the event list, and reset the status of the Event log item within the Status panel to OK.
Reload: refreshes the displayed event list with any event information that occurred since you opened the log. Note that you can also click the Reload icon within the toolbar to do this.
Close: closes the event log.
You can click a displayed event to view more information about it. A dialog similar to the one shown in Figure 9-20 appears.
This dialog provides you with the complete event text, as well as the associated event code. Note that both of these should be specified when contacting Customer Support. In the case of remote Collectors, the reported source is the Collector's IP address.
RUEI supports the use of text message notifications. In order to make use of this facility, all text message providers that you are planning to use must be configured and known to the system. To manage your provider information, select System, then Maintenance, and then Text message providers. The dialog shown in Figure 9-21 appears.
To configure a text message provider, do the following:
Click « Add new account » to define a new text message provider. The dialog shown in Figure 9-22 appears.
Select the required text message provider from the list. It contains a number of predefined supported services. Each of these require an account with the associated provider. When ready, click Next. A dialog similar to the one shown in Figure 9-23 appears.
Important:If you specify a local GSM modem, a GSM modem must be installed on the system. The installed local modem must be a USB or serial GSM ETSI 07.05-compliant modem.
The exact fields available within the dialog depend on the provider selected in Figure 9-22. For example, if you selected a local GSM modem, you are required to specify the local port and baud rate for the modem. If not known, automatic detection is available. Optionally, you can also specify a SIM PIN (if one is required).
If you selected the predefined Mollie or Clickatell services, you are required to specify the user name, password, originator, API ID, and protocol sending method used for the account. These should have been supplied to you by your account provider. When ready, click Save. You returned to the dialog box shown in Figure 9-21.
Right click the providers in the list and use the Move up and Move down options to control a provider's position in the list. Providers are tried in the order they appear in the list. Hence, the first account is tried and, on failure, the second one, and so on.
When ready, click Close to leave the dialog.
While Unicode is supported in text messages, there are a number of restrictions of which you should be aware. In the case of locally installed modems, messages are sent to the modem using the 7-bit GSM 3.38 alphabet. Any unsupported characters in the original message are replaced by a question mark (?) character. In the case of an external service provider, it is recommended that you consult your service provider for information about multi-byte character set support. In the case of both locally installed modems and external service providers, text messages are limited to 160 characters.
If you experience problems with the use or operation of RUEI, you can contact Customer Support. However, before doing so, it is strongly recommended that you create a Helpdesk report file of your system. To do so, select System, then Configuration, and then Helpdesk report. You are then prompted to specify a location to which the file should be downloaded.
This file contains extended system information that is extremely useful to Customer Support when handling any issues that you report.
Please note that this file contains software proprietary information. Do not try to modify its content.
To view the status of network data collectors, or to add new ones, select System, then Maintenance, and then Network Data Collectors. The use of this facility is the same as that described in Section 9.2, "Viewing the Status of the Collectors".
As explained in Section 2.2, "Using the Mailing Facility", RUEI can send automatic E-mails of requested reports. This facility uses the information specified during the initial configuration phase (described in the Oracle Real User Experience Insight Installation Guide). However, this configuration can be changed by selecting System, then Maintenance, and then Mail setup. The dialog shown in Figure 9-24 appears.
Use this dialog to specify the following information:
Return address: specifies the E-mail address to which failed or problem E-mails are reported. It is strongly recommended that this an address that is regularly checked.
From address: specifies the address the recipient sees in their mail client.
Reply-to address: specifies the address that users can click within an E-mail to reply to an E-mail. If this is not specified, the From address setting is used.
Mail size limit: specifies the maximum message size (in kilobytes) allowed for E-mails. Note that if an E-mail contains reports that exceed this limit, the system will try to split up the reports into individuals E-mails to overcome this limitation. Reports that are too large to be sent individually are not sent, and the user is informed of the problem. The default mail size limit is 5000 Kb.
If you experience unexplained problems, you can restart processing to ensure that it is operating properly and synchronized. Note that selection of this option will result in a temporary delay in data availability and monitoring.
In the last resort, you can remove all collected data from the system. Alternatively, you can reset all parameters (such as created users and environment parameters) to their out-of-the-box default values.
To reset the system, do the following:
Select System, then Maintenance, and then System reset. The dialog shown in Figure 9-25 appears.
Select the required option:
Reapply latest configuration to ensure that any configuration changes (such as modifications to the
ruei.conf configuration file) take immediate effect. This is the default.
Restart system processing to reactivate system processing.
Purge collected data to remove all collected data from the system.
Reset to factory defaults to remove all collected data and SSL keys, and reset all system parameters to their default values.
When ready, click Next.
Caution:The Purge collected data and Reset to factory defaults options are irreversible. All collected data will be erased. In the case of Reset to factory defaults, all system settings will also be returned to their original state. Therefore, a complete initial configuration (and the definition of the
adminuser password using the
set-admin-password.shscript) will be required before you have access to the Reporter interface. If you have previously created a backup (described in Section 9.8, "Creating and Restoring Configuration Backups"), you can restore this backup after initial configuration. This initial configuration procedure is described in the Oracle Real User Experience Insight Installation Guide.
As explained in Section 1.6, "Customizing Your Environment", users can customize the formatting settings used in their sessions. They can specify the characters used for the decimal point indicator and the thousand separator, and the date format that should be used. Administrators can also specify defaults for these settings on a system-wide basis by selecting System, then Maintenance, and then Formatting preferences.
Events can occur that mean that complete data for a specific period is not available. An example of such an event is a Collector restart resulting in a brief period of time when no network data is being recorded. RUEI can be configured to provide an information message, together with an indication of the affected period(s). An example is shown in Figure 9-26.
Be aware that the highlighting is only intended to provide information about when such an event occurred, and not an exhaustive analysis of the affected data areas. Therefore, it is only available for time-based information. In addition, the informational message shown at the top of the screen, together with the indicators shown within specific periods, appear in Data Browser, export and report screens, but not in exported data.
You can control the occurrence of this highlighting by specifying the required threshold. That is, how much data for the currently selected period needs to be affected before it is highlighted. It is recommended that you carefully review the specified threshold to reflect your organization reporting requirements. For example, consider the case in which you set the threshold at 5%. A missing 1-hour period within a 3-hour period represents 33%. However, that same 1-hour period within a 1-day period selection represents approximately 4%. By default, the threshold is 2%.
To specify the highlighting threshold, do the following:
Select Configuration, then General, then Advanced settings, then Data visualization, and then Data reliability threshold. The dialog shown in Figure 9-27 appears.
Check the Enabled check box to enable the appearance of data reliability warnings.
Specify the threshold that should be used when highlighting that complete data for the currently selected period is not available. The default is 2%.
When ready, click Save. Any change you make to this setting takes effect immediately.
By default, information about the current (incomplete) period is always shown within selected periods that extend to the present time. In graphical visualizations, this is indicated with a dotted line. An example is shown in Figure 9-28.
To specify when incomplete periods should be reported, do the following:
Select Configuration, then General, then Advanced settings, then Data visualization, and then Current period reporting. The dialog shown in Figure 9-29 appears.
Select the visualization scheme to be used when reporting the current period. The following options are available:
Enabled: specifies that all incomplete periods should be reported within all graphical visualizations, as well as value lists, reports, and exports. This is the default.
Disabled: specifies that no incomplete period should ever be reported.
Specified: specifies that incomplete periods should only be reported within the specific visualizations. Note that the "Value list" option covers not only value lists within the Data Browser, but also reports and exports.
When ready, click Save. Any change you make to this setting takes effect immediately.
KPI and SLA values are reported to a certain level of precision. By default, this is two decimal places. However, you are free to modify this to reflect your reporting requirements. Do the following:
Select Configuration, then General, then Advanced settings, and then KPI and SLA precision reporting. Select the item whose reporting you want to modify. For example, SLA success. A dialog similar to the one shown in Figure 9-30 appears.
Specify the number of decimal places to which the selected item should be reported. When ready, click Save. Any change to these settings takes effect immediately.
To start working with user definitions, select System, and then User management. The screen shown in Figure 9-31 appears.
This screen lists the currently defined system users. For each user, their account name, full name, E-mail address, and authentication mechanism are listed. A user's role and status is indicated through the color-coded scheme explained in Figure 9-32.
The authentication of system users can either be performed by RUEI itself, based upon the user information stored within its database, or by an external authentication server. Currently, RUEI supports two external authentication mechanisms: via an LDAP server, or via an Oracle Single Sign-On (SSO) server. In both cases, the server must be configured to work with RUEI. The procedure to configure the LDAP server is described in Section 9.19.5, "Configuring LDAP Server User Authentication". The procedure to configure the Oracle SSO server is described in Section 9.19.6, "Configuring Oracle Single Sign-On (SSO) User Authentication".
To create a new user, do the following:
Select System, then User management, and click the Add new user command button in the taskbar (see Figure 9-31). If an LDAP server connection has been configured (as described in Section 9.19.5, "Configuring LDAP Server User Authentication"), the dialog shown in Figure 9-33 appears. Otherwise, a dialog similar to the one shown in Figure 9-34 appears, and you should continue from step 3.
Use the radio buttons shown in Figure 9-33 to specify whether the creation of the new user account, and its associated user settings, should be authenticated against the settings held in the RUEI installation (this is the default), or against a configured LDAP server. When ready, click Next. If an LDAP server is configured, the dialog shown in Figure 9-34 appears. Otherwise, a dialog similar to the one shown in Figure 9-37 appears.
Use the dialog shown in Figure 9-34 to specify the following information for the new user:
The user name by which the user will be known within your RUEI installation. This must be a unique name. Users names are case sensitive. Note that if Oracle SSO server user authentication is enabled, the user is automatically created as an Oracle SSO user. In this case, specified user name must be the same as that defined within the Oracle SSO server.
The user's full name.
The user's E-mail address. This is the address to which reports and E-mail alerts will be sent. Ensure it is correct.
If the user will be authenticated against the settings held locally in the RUEI installation, you are required to specify and confirm a password for the new user. See Section 9.19.4, "Enforcing Password Security Policies" for information about password requirements. Note that the new password must be changed by the user within seven days or they are locked out.
Optionally, use the Disabled check box to disable the user at this time. You are free to enable them later.
If you selected user authentication against a configured LDAP server in Figure 9-33, you can click the Get user data from LDAP button to retrieve the user's settings from the configured LDAP server.
When ready, click Next to continue. The dialog shown in Figure 9-35 appears.
Use the check boxes and menus to specify the role and permissions to be assigned to the new user. These are fully described in Section 1.4, "Understanding User Roles and Permissions". If the new user is assigned less than Full access level permission, you must use the Authorize for menu to specify the specific applications, suites, and services about which the user is authorized to view information. Click Finish to create the user definition. You are returned to the user list shown in Figure 9-31.
Note:In addition to the settings described above, there are a number of additional settings (such as language, mailing type, and so on) that are set to their default values when a user is created. These additional settings can also be modified using the procedure described in Section 1.6, "Customizing Your Environment".
To modify a user definition, select System, and then User management. The User management panel shown in Figure 9-31 appears. Right click the appropriate user. The context menu shown in Figure 9-36 appears.
The following options are available:
Edit: allows you to modify a user's definition. This is described in Section 9.19.3, "Modifying a User's Settings".
Enable/Disable account: allows you to enable or disable the user account at this time. Note that all currently defined users are disabled when SSO authentication is enabled, and all SSO user accounts are disabled when SSO authentication is disabled.
Switch to: allows you to temporarily change to the selected user. This is useful if you want to view the modules and reports that they are authorized to see. Select Switch back from the View menu to return to your own role. Note this option is not available when the selected user account is disabled.
Remove: deletes the selected user from the system's user administration. Note that any private reports that the user created are also deleted. However, public reports created by the user remain available to other users.
To change the settings for an existing user, do the following:
Select the required user within the user list shown in Figure 9-31, and select Edit. If an LDAP server connection has been configured (as described in Section 9.19.5, "Configuring LDAP Server User Authentication"), a dialog similar to the one shown in Figure 9-33 appears. Otherwise, the dialog shown in Figure 9-37 appears, and you should continue from step 3.
Use the radio buttons to specify whether the user's settings should be authenticated against the settings held in the RUEI installation (this is the default), or against a configured LDAP server. When ready, click Next. If an LDAP server is configured, the dialog shown in Figure 9-34 appears. Otherwise, the dialog shown in Figure 9-37 appears.
Optionally, modify any of the displayed information. Note that the fields shown with a red asterisk indicate they are mandatory. That is, they can not be left blank.
Note that when modifying an SSO user's account, and SSO authentication is disabled, the account is automatically converted to a locally authenticated account. Therefore, it becomes mandatory to specify and confirm a password for the user.
You can use the Disabled check box to prevent the user from using this account. You are free to enable them later. This facility is also useful because, as mentioned earlier, all currently defined user accounts are disabled when SSO authentication is enabled, and all SSO accounts are disabled when SSO authentication is disabled.
Because user accounts are automatically locked after a user has failed to correctly enter their password on five successive attempts, you can use the Locked check box to reset it. Password security is described in Section 9.19.4, "Enforcing Password Security Policies". You can use this check box to unlock the user's account. When ready, click Next. The dialog shown in Figure 9-38 appears.
Note:If a user's password is changed via this interface, the user must change the password themselves (using the procedure described in Section 1.6, "Customizing Your Environment") within seven days or the account will be locked.
Optionally, you can modify the following:
Startup module: specifies the module in which the user starts their session. (For example, Reports, System, or User management). The default is the dashboard (described in Section 1.7, "Working with Dashboards").
Initial browse period: specifies the initial period selection when entering the Data Browser or reports facility. The default is the last 6-hour period.
When ready, click Next. A dialog similar to the one shown in Figure 9-35 appears.
Optionally, use the check boxes and menus to specify the roles and permissions to be assigned to the user. These are explained in Section 1.4, "Understanding User Roles and Permissions". If the new user is not assigned Full access level permission, you should use the Authorize for menu to specify the specific applications, suites, and services they are authorized to view. When ready, click Finish for the changes you have made to take effect.
In the event that you need to reset the
admin user password, you can do so using the use of the
set-admin-password.sh script. This is described in the Oracle Real User Experience Insight Installation Guide. Note the new password must be changed (via the procedure described in Section 9.19.3, "Modifying a User's Settings") within seven days.
Each user must be defined and authorized to work with RUEI. The procedure to do this is explained in Section 9.19, "Managing Users and Permissions". In order to optimize the security of your installation, you can use the password settings facility to enforce your organization's security policies. Specifically, you can control the maximum length of user passwords, how often users are required to change their passwords, the number of days after the creation of a new user account within which the initial password must be changed, and the number of failed logon attempts after which a user account is locked.
To control your installation's password enforcement, do the following:
Select System, then User management, and click Password settings. The dialog shown in Figure 9-39 appears.
Use the Minimum length field to specify the minimum number of characters that user passwords must contain. This must be between 8 -255 characters, and the default is 8 characters.
Use the Expiration age field to specify how often users are required to change their passwords. The default is 60 days. If set to 0, passwords will never expire. The maximum expiration period is 999 days.
Use the Initial expiration age field to specify the number of days after the creation of a new user account within which the initial password must be changed. This must be 1 - 30 days. It also specifies within how many days a user must change their password after it has been reset by an Administrator. The default is 7 days.
Use the Allowed login attempts field to specify the number of failed logon attempts after which a user account is locked. This must be between 1 - 10 times. The default is 5 times.
When ready, click Save.
When creating and authorizing users, the following rules are automatically enforced:
User accounts are locked after a specified number of failed attempts. The account must be unlocked before the user can logon again (described in Section 9.19.3, "Modifying a User's Settings"). However, locked users will continue to receive mailed reports and alerts.
If a password's expiration period is set to 0, and later re-set to a non-zero value (or vice versa), all existing user accounts will adapt to the newly specified password expiration period.
A user password must have a minimum of eight characters. It must contain at least one non-alphanumeric character (such as $, @, &, and !).
A password cannot include the defined user name, or their first or last name. In addition, the user's last three passwords are also remembered, and cannot be re-used.
Passwords are case sensitive.
In order to provide enhanced security, RUEI can be configured to enable user authentication via an LDAP server, rather than through the settings held locally on your RUEI installation. If an LDAP server connection has been configured, you can specify the authentication method to be used for each defined user. Note because the
admin user is predefined, and their password is set during initial configuration (see the Oracle Real User Experience Insight Installation Guide), only local authentication is available for this user.
If you plan to use LDAP authentication, it is recommended that you define your LDAP connection before the creation of user accounts. This is in order to prevent having to modify previously specified user settings.
Note that the LDAP secure server certificate should to in PEM format, and be specified via the TLS_CACERT directive in the
/etc/openldap/ldap.conf file. The certificate file must be owned by the root user, and be readable by the RUEI and Apache user groups. Note that the CN of the LDAP server certificate must match the fully qualified domain name of the LDAP server.
If the LDAP secure server certificate configuration procedure described above does not provide a working connection, you can use the OpenLDAP utility (available on the Oracle Linux or RedHat Enterprise Linux distribution set) to validate the configuration of your LDAP server. The utility can be installed and run using the following commands:
sudo yum install openldap-clients ldapsearch -x -P 2 -H "LDAP_server_URL" -D cn=jsmith, dc=oracle, cn-com
LDAP_server_URL specifies the full URL for your LDAP server, and the pair combinations depends on your LDAP server configuration. If specified correctly, information about that user is returned from the LDAP server. Otherwise, the problem encountered (such as the specified host name does not match the LDAP server or LDAP certificate was not installed correctly) is reported.
Note that if the certificate does not work, you can set the TLS_REQCERT directive to 'never' in the
/etc/openldap/ldap.conf file to prevent validation of the certificate and continuation with the secure connection.
To enable LDAP server authentication, do the following:
Select System, then User management, and then click Configure LDAP connection. Note that if an LDAP server connection has already been configured, the option is indicated as Modify LDAP connection. The dialog shown in Figure 9-40 appears.
Use the Allow LDAP authentication check box to specify whether an LDAP server is available for user authentication. The default is unchecked (disabled).
Use the Server name field to specify the host name or IP address of the LDAP server to be used. Note that protocol information (such as
LDAP://) should be omitted from the server name.
Use the Connection type menu to specify the LDAP version and connection method. The default is V2 (non-secure).
Use the Port number field to specify the port to which the LDAP server is listening. If necessary, discuss this with your System Administrator. The default port is 389 or 636 (for SSL encryption).
Use the Search base field to specify the location in the directory structure within which the user ID needs to be unique. This must be a valid DN. For performance reasons, this should be as specific as possible. The default is the root of the directory tree.
Use the Anonymous check box to specify if the LDAP server lookup should be performed using an anonymous user. If unchecked, then a valid Distinguished Name (DN) must be specified, and the password for that user is requested when a new user is created. The default is to use an anonymous lookup.
Use the User ID, Email address, and Full name fields to specify the attributes that should be used to extract user settings from the LDAP server. The defaults are based on standard LDAP functionality. If necessary, you should discuss these attributes with your LDAP administrator.
Optionally, you can click Test to verify whether a working connection to the LDAP server can be made. This is discussed in the following section.
When ready, click Save.
Any changes you specify to the LDAP configuration settings take effect immediately.
As mentioned earlier, you can test the connection to the LDAP server. Do the following:
Use the User ID to look up field to specify the user ID for which the LDAP server should search. This should be a valid user ID. When ready, click Test. Upon successfully finding the specified user's entry in the directory, their retrieved details are displayed. When ready, click Cancel. You are returned to the dialog shown in Figure 9-40.
In order to provide enhanced security, RUEI can be configured to enable user authentication via an Oracle Single Sign-On (SSO) server, rather than through the use of an LDAP server or the settings held locally on your RUEI installation.
When enabled, RUEI users (other than the
admin user) are automatically re-directed to the Oracle SSO logon page. They then logon to RUEI through this page, rather than the RUEI login dialog (shown in Figure 1-1). Note because the
admin user is predefined, and their password is set during initial configuration (see the Oracle Real User Experience Insight Installation Guide), only local authentication is available for this user. Note that other users with Administrator privileges still need to logon via the Oracle SSO server.
To activate the SSO server, do the following:
Select System, then User management, and then click Configure SSO connection. Note that if an Oracle SSO server connection has already been activated, the option is indicated as Modify SSO connection. A dialog similar to the one shown in Figure 9-42 appears.
Use the Enable/Disable Oracle SSO check box to specify whether an SSO server is available for user authentication. The default is unchecked (disabled). When ready, click Save.
After enabling or disabling the Oracle SSO server, it is recommended that you logout and logon again to RUEI. This is to ensure that your RUEI installation reflects the change you have made.
When using an Oracle SSO server for user authentication, it is important to be aware of the following points:
When users are logged onto multiple SSO-registered applications, and they logout of an application, they are logged out of all other SSO-registered applications, including RUEI. Similarly, when users logout of RUEI, they are logged out of their SSO session.
When SSO authentication is enabled:
LDAP authentication is automatically disabled.
It is not possible to change a user's password through the Reporter interface. However, the
admin user's password can still be changed because, as explained earlier, this is authenticated locally.
All currently defined RUEI users are disabled. This includes users (other than the
admin user) with Administrator privileges.
When modifying an existing non- Oracle SSO user account, the user account name is converted to lowercase.
The currently defined password policy settings (see Section 9.19.4, "Enforcing Password Security Policies") only apply to the
admin user. The Oracle SSO server enforces its own defined password policies.
If the SSO server is not running, or is experiencing problems, users are unable to logon.
The user name in the Oracle SSO directory must be the same as the user name specified in RUEI. Note also that user names are stored in lower case in RUEI, and any upper case characters in the Oracle SSO user names are automatically converted to lowercase in RUEI.
As mentioned earlier, the
admin user remains locally authenticated. In order to logon, they must use the following URL:
When registering the RUEI application with an SSO server, the logout URL should be specified in the following format:
hostname specifies the appropriate host name.
Note that the Oracle HTTP server must be installed and configured before user authentication via an Oracle SSO server is available. The procedure to do this is fully explained in Chapter 7 of the Oracle Real User Experience Insight Installation Guide.
The Enriched data exchange facility enables you to combine the data gathered by RUEI with other data sources. These could include, for instance, Customer Relationship Management (CRM) or Business Intelligence (BI) systems. Using this functionality, you can produce customized analysis of your Web environment using your own BI tooling, as well as integrate RUEI's rich set of collected data with offline data to obtain greater insight into what drives your sales and revenue.
The facility works by exporting the data collected by every 5-minute period to a database. By default, the data is exported to the same database instance as used by the Reporter. However, it is strongly recommended that you configure an alternative database instance for enriched data export. Access to data in the export database is available via SQL. The procedure to do this is fully described in the Oracle Real User Experience Insight Installation Guide.
As described later in this section, you can customize the content of the exported data to include information not normally collected by RUEI. For example, the contents or value of visitors' shopping baskets. Because the exported data is page-based, the available data is restricted to applications and suites, and does not include service-related data.
The amount of data available in the export database is controlled via the Enriched data exchange retention setting in the defined Reporter data retention policies. These are fully explained in Section 9.6.1, "Defining Reporter Retention Policies". The structure of the database tables used within the export database are described in Appendix R, "Enriched Data Export Facility".
This section presents an outline of a BI solution utilizing data from the Enriched data exchange facility. In this case, it makes use of Oracle Business Intelligence foundation (part of the Oracle Fusion Middleware product family). Its schematic structure is shown in Figure 9-43.
The framework is based on Oracle Warehouse Builder (OWB). The RUEI-captured data is exported to a database. From the export database, it is uploaded via SQL scripts to a staging database. This then populates the production database. Once in the production DWH, the RUEI data is available through a wide variety of reports and dashboards. An example of these reports is shown in Figure 9-44.
To enable the Enriched data exchange facility, do the following:
Select Configuration, then Applications, and then Enriched data exchange. The screen shown in Figure 9-45 appears.
Use the Enabled check box to enable or disable the Enriched data exchange facility. By default, it is disabled. If enabled, it is recommended that you configure an alternative database for export data. The procedure to configure an alternative database is fully described in Chapter 9 of the Oracle Real User Experience Insight Installation Guide.
Optionally, you can define additional data items to be included in the exported data. Typically, these are elements in the client request or server response headers that are not normally collected by RUEI, but which you want included in the exported data. To do so, click «Add new item». The dialog shown in Figure 9-46 appears.
Use the Source type menu to define how the required item should be identified within the data collected by RUEI, and the scope of the search. You can specify to search within the client request header or server response header, using either a literal search or an XPath expression, or to search within a custom page-tagging implementation for a specific tag. Further information about support for custom page-tagging schemes is available in Appendix A, "Tagging Conventions".
Use the Source value field to specify the specific argument or element from which the data item's value should be taken.
Use the Export name field to specify the name to be assigned to the data item. This becomes the item's element name. In the case of a custom tag, this will appear in the CONTENT column in the BI__BIDATA_MASTER (see Table R-2) in the format
=. Similarly, XPath expression items would be reported in the REQUEST_HEADERS or REPLY_HEADERS columns. Note that the Export name field is not available if you select a header-related option in the Source type menu. In this case, the name of the header is used in the appropriate column. When ready, click Save. The new item, if found in the monitored traffic, will start to appear in the reported data within 5-10 minutes.
Existing data items can be modified by right-clicking them within Figure 9-45, and selecting Edit. You can also select Remove to delete it, or select Remove all to delete all currently defined items.
Be aware that the SQL queries used to access exported data can place a significant performance overhead on the export database. For this reason, it is recommended that you pay particular attention to the following points:
Try to limit the number of SQL queries run during a 5-minute period to a minimum. In particular, try to avoid querying the same data more than once.
Use simple SQL queries to access the required data. If particular table columns are not required, they should be dropped from the returned query.
If large volumes of data are required to be handled, you should consider the use of a separate export database. The procedure to configure an alternative database is fully described in Appendix B of the Oracle Real User Experience Insight Installation Guide.
Footnote LegendFootnote 1: Be aware that increasing the maximum group size will impact reporting performance. It is recommended that you incrementally increase the setting and verify that performance is acceptable.