| Oracle® Real User Experience Insight User's Guide Release 6.5.0 for Linux x86-64 Part Number E17378-03 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 6.5.0 for Linux x86-64 Part Number E17378-03 |
|
|
View PDF |
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 the status of the attached Collectors and the log file process, the current level of processing within the system, and the event log. You can also configure which users are notified (and how) about a system status error.
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.
Restart: restarts the selected Collector. You are prompted to confirm the restart.
Unregister: removes an attached Collector from the Reporter system. You are prompted to confirm the Collector's removal.
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-1.
Table 9-1 Collector Statistics Report Tabs
| Tab | Description |
|---|---|
|
Interfaces |
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 |
|
Ethernet |
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. |
|
TCP |
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. |
|
TCP diagnostics |
The use of this facility is described in Appendix K, "Verifying Monitored Network Traffic". |
|
HTTP |
Provides an analysis of the monitored HTTP stream. In particular, the type of requests (such as GET or POST) they contain. |
|
SSL connections |
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. |
|
SSL encryption |
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). |
|
Performance |
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). |
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.
URL Argument and Collector Encoding
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.
Figure 9-6 Edit Collector Encoding Dialog
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.
Important
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.
Important
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.
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-7 appears.
Figure 9-7 Database and Disk Space Thresholds
Select the required threshold. A dialog similar to the one shown in Figure 9-8 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.
Defining Threshold Values
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-9.
Figure 9-9 Data Retention Across Collector and Reporter Systems
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.
If full logging has been specified for data masking, all hit-based information is held in a series of short-term data files. These files are regularly filtered into long-term data files that contain only information about failed events (that is, failed pages, objects, and function calls). While this information is viewable within the Session diagnostics replay facility on the Reporter system, the data is stored 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.17, "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-10 appears.
Figure 9-10 Reporter Data Retention Policy Panel
As can be seen in Figure 9-10, 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.
Compress data: specifies whether data should be compressed for long-term storage. By default, compression is enabled. Be aware that disabling compression effectively doubles the amount of required database storage space. However, it would also significantly reduce the redo logging generated.
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.
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.2, "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.
XML enriched data exchange retention: specifies the maximum number of days for which XML enhanced data exchange is available. This facility is fully described in Section 9.17, "Exporting Enriched Data". The default is the last seven days, and the minimum is the last 24 hours. Be aware that, if set to one day, the previous day's data is deleted at around midnight, and only a limited amount of information is available for the current day. In order for you to be able to download the previous day's data after midnight, it is recommended that a maximum of at least two days is specified. The maximum depends on the available database and disk space. The location of the files is the directory /var/opt/ruei/processor/xml-events/wg/xml-sespage. Within this, data for each day has its own directory with the format name yyyymmdd.
A dialog similar to the one shown in Figure 9-11 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. Any changes you specify take effect immediately.
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.Calculating Required Days, Months, and Years
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), plus one. For example, 11 months would require one year, while 13 months would require two years.
For example: 900 days, 31 months, and 3 years.
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-12 appears.
Figure 9-12 Collector Data Retention Policy
Use the View menu to select the required Collector. The System (localhost) represents the Collector running on the Reporter system. The Oldest data entry 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.
Click either the Error page replay store size or Full session replay storage size option. A dialog similar to the one shown in Figure 9-13 appears.
Figure 9-13 Long-Term Replay Viewer Store Size
Note that the Error Page Replay (EPR) and Full Session Replay (FSR) settings refer to the maximum amount of disk space reserved on the selected Collector system for each application. Note that this must be multiplied by the number of applications with EPR/FSR data stored on the Collector to determine the total amount of required Collector disk space. To do so, click Calculate.
Important:
In previous versions, these settings specified the total amount of Collector disk space reserved for all monitored applications. During upgrade to version 6.5, the currently defined Collector settings are converted to settings for each monitored application. Depending on the number of monitored applications, and your previous settings, the amount of required disk space can significantly increase.Information on specifying reserved full session replay disk space on an application-specific basis is available within article 1068831.1 at https://support.oracle.com/CSP/ui/flash.html.
If content information is not available in the Replay Viewer, you may need to review this setting. You should also review the Failed event data retention setting.
If the Error page replay viewer 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 Error page replay viewer store 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 Full session replay storage setting is set to less than 15 minutes, the error replay facility may not function correctly. In addition, if set to zero, the Error page replay store size setting can no longer be modified. Note that in the case of a local Collector, the size of log files stored on Collector item will always be zero.
When ready, click Save. Any change you specify takes effect immediately.
Note:
When an application, suite, or service is deleted, the FSR and EPR data associated with it is not automatically removed from the Collector system. Instead, it is retained based on the currently defined Collector data retention policies. The procedure to manually remove the redundant replay is described in article 1071976.1 at
https://support.oracle.com/CSP/ui/flash.html.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-14.
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 transactions will also not be available because transaction 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-15 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-16 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-17 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-18 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-19 appears.
Figure 9-19 Select Text Message Provider Dialog
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-20 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-19. 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-18.
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".
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-21 appears.
Select the required option:
Restart system processing to reactivate system processing. This is the default.
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
admin user password using the set-admin-password.sh script) 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 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-22 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.
Reporter URL: specifies the exact URL required for E-mail recipients to connect to the Reporter system. Typically, this is the same URL used by RUEI users to access the Reporter system.
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.
To start working with user definitions, select System, and then User management. The screen shown in Figure 9-23 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-24.
User Authentication
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.16.5, "Configuring LDAP Server User Authentication". The procedure to configure the Oracle SSO server is described in Section 9.16.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-23). If an LDAP server connection has been configured (as described in Section 9.16.5, "Configuring LDAP Server User Authentication"), the dialog shown in Figure 9-25 appears. Otherwise, a dialog similar to the one shown in Figure 9-26 appears, and you should continue from step 3.
Use the radio buttons shown in Figure 9-25 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-26 appears. Otherwise, a dialog similar to the one shown in Figure 9-29 appears.
Use the dialog shown in Figure 9-26 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.16.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-25, 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-27 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-23.
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-23 appears. Right click the appropriate user. The context menu shown in Figure 9-28 appears.
The following options are available:
Edit: allows you to modify a user's definition. This is described in Section 9.16.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-23, and select Edit. If an LDAP server connection has been configured (as described in Section 9.16.5, "Configuring LDAP Server User Authentication"), a dialog similar to the one shown in Figure 9-25 appears. Otherwise, the dialog shown in Figure 9-29 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-26 appears. Otherwise, the dialog shown in Figure 9-29 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.16.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-30 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:
Language: this is the language in which system messages and prompts appear. Currently, only English is available.
Mailing type: specifies whether the reports the user receives are sent in multiple E-mails (one for each report) or bundled into a single E-mail. The default is multiple E-mails.
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").
When ready, click Next. A dialog similar to the one shown in Figure 9-27 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.
Resetting the Super Administrator Password
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.16.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.16, "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-31 appears.
Use the Minimum length field to specify the minimum number of characters that user passwords must contain. This must be 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 1 - 10 times. The default is 5 times.
When ready, click Save.
Password Enforcement
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.16.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.
Configuring the LDAP Server 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-32 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.
Testing the LDAP Server
As mentioned earlier, you can test the connection to the LDAP server. Do the following:
Within Figure 9-32, click Test. The dialog shown in Figure 9-33 appears.
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-32.
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.
Activating the 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-34 appears.
Figure 9-34 Oracle Single Sign-On (SSO) Settings Dialog
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.
Enabling Oracle SSO Authentication
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.16.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:
https://Reporter/ruei/admin.php
Installing and Configuring the Oracle SSO Server
The facility for user authentication via an Oracle SSO server is not available until the RUEI application has been registered with the Oracle SSO server. The procedure to install and configure the Oracle SSO server for RUEI user authentication is described in the Oracle Real User Experience Insight Installation Guide.
The Enriched data exchange facility enables the alternative analysis of the data collected by RUEI. In particular, it allows you to combine the data collected by RUEI with other data warehouse data. For example, a Customer Relationship Management (CRM) or Business Intelligence (BI) system. Using this facility, you can extract a rich set of collected data, such as product names, shopping basket values, and address information. The external tools should be aware the data is in Unicode (UTF-8) format.
While the facility described in Section 2.11, "Exporting Report Data" is limited to report data, the enriched data exchange facility allows the export of all page-based data. In addition, report data export is based on HTTPS transfer, and Enriched data exchange is based on SFTP file transfer. As described later, you can also customize the content of the exported data to include header information not normally collected by RUEI. Because the exported data is page-based, the available data is restricted to applications, and does not include service-related data.
Example BI Implementation Using Enriched Data Exchange
This section presents an outline of a BI solution utilizing data from the Enriched data exchange facility. It makes use of Oracle Business Intelligence foundation (part of the Oracle Fusion Middleware product family). Its schematic structure is shown in Figure 9-35.
Figure 9-35 Schematic Overview of Data Warehouse Staging Area
The framework is based on Oracle Warehouse Builder (OWB). The RUEI-captured data is uploaded to a load database. This, via a staging database, 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-36.
Enabling and Disabling Enriched Data Exchange
To enable Enriched data exchange, do the following:
Select Configuration, then Applications, and then Enriched data exchange. The screen shown in Figure 9-37 appears.
Use the Enabled check box to enable or disable the Enriched data exchange facility. By default, it is enabled.
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-38 appears.
Figure 9-38 Add Enriched Data Export Item Dialog
Use the Search 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. For example, if specify the name "product", any matched data will appear in the export file with the label <product>. Note this field is not available if you select a header-related option in the Source type menu.
When ready, click Save. The new data item, if found in the monitored traffic, will start to be reported in the export files within 5 to 10 minutes.
Existing data items can be modified by right-clicking them within Figure 9-37, and selecting Edit. You can also select Remove to delete it, or select Remove all to delete all currently defined items.
Note:
The amount of disk space available for export files can also be specified. This is explained in Section 9.6.1, "Defining Reporter Retention Policies".The exported data is based on page views, and is in XML format. This enables its immediate importation into a wide variety of systems. An XSD file defines the structure of the exported XML. The XML schema is shown in Figure 9-39:
For an explanation of the standard data items featured in the schema, see Appendix D, "Summary of Data Items".
File location and Naming Structure
When enabled, the Enriched data export facility creates an export file every five minutes. The files are Unicode (UTF-8) encoded. The files are located in the directory /var/opt/ruei/processor/xml-events/wg/xml-sespage. Each file within this directory has the following name structure:
yyyymmdd-hhmmss-nnnn[L|M].xml.gz
Where:
nnnn represents the file sequence. Because an export file is created every five minutes, 288 files can be created per day. This can range from 0001 to 0289.
L indicates that it is the last file for that day. This always has the file sequence 289, and is used to gather up any open sessions after the 24 hour period.
M indicates that more files are still to follow this file.
By default, exports are retained for a period of seven days before they are automatically deleted. However, this can be configured, as explained in Section 9.5, "Configuring Database and Disk Space Limits and Alerts". In order to access these files, you will need a working FTP file transfer connection to the Reporter system. Consult your System Administrator for further information on this facility.
If required, you can use a symbolic link definition to change the location to which files are exported. Consult your System Administrator for further information on the use of this facility.
Security Considerations
While access to the data generated by the Enriched data exchange facility can be controlled in several different ways at the operating system level, it is recommended that you use SCP/SFTP and create a separate OS user with minimal access rights to the directory containing the exported data. You can then use an scp command to copy the data to a local system. For example:
scp -r <OS user>@Reporter:/var/opt/ruei/processor/xml-events/wg/xml-sespage/ 20080903 .
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
