RealServer can create reports of historical data that let you see trends and gather information. Track who visited your site and for how long; what clips they watched and whether they watched them all the way through to completion. This information is stored in the access log. Any error messages are recorded in the error log. Requests for streams which will be cached are stored in the cached requests log.
The RealServer access log records the IP addresses of the clients that have connected, the clips they listened to, the times of day they connected, and much more. This information can give you an idea of who your audience is and which clips are most popular. New information is always appended to the end of the access log.
This section describes the ways in which other features show up in the access log file.
The GET statement in the access log (described on "Access Log Format") shows the names of the on-demand and live clips served by RealServer. Most clips generate one access log record apiece.
Clips delivered via scalable multicasting generate two records for each client that connects-one for the .sdp file and one for the actual live broadcast clip. (However, if the user saves the .sdp file and connects via that file, rather than by clicking a link on a Web page, only the live broadcast clip will generate a record.)
A record is generated for a SMIL file and for every file referenced in it. You can identify which files are associated because they will all have the same identifier at the end of the access log. (This identifier will only appear when Logging Style is 5.)
On-demand clips appear in the access log with all the expected information-clip path and name, and statistics, if specified by the Stats Mask and Logging Style options.
Client data for live events is transmitted at the conclusion of the broadcast. Entries will not appear in the access log until the client stops playing the event-which could be when the live event is over or if the user clicks the Stop button.
The GET statement shows unicasted events starting with the live mount point (usually /encoder/).
Statistics Type 3, which show the user's actions during play (such as fast forward and pause), are not available for live events.
Client data for live events is transmitted at the conclusion of the broadcast. Entries will not appear in the access log until the client stops playing the event-which could be when the live event is over or if the user clicks the Stop button.
If you set up G2SLTA to do an infinite loop, and the client remains connected, no record will be created until the broadcast stops or the client halts.
The GET statement shows unicasted events starting with the live mount point (usually /encoder/).
Statistics Type 3, which show the user's actions during play (such as fast forward and pause), are not available for live events.
On transmitters, the access log does not show any records pertaining to the receiver connections. However, if the same event is encoded to multiple RealServers, (described in "Using Backup Transmitters"), records will be created in the transmitter's access log.
On receivers, the access log contains records for each clip delivered, and shows the splitting mount point.
Client data for live events is transmitted at the conclusion of the broadcast. Entries will not appear in the access log until the client stops playing the event-which could be when the live event is over or if the user clicks the Stop button.
If backup transmitters are in use for push splitting (the link contains an asterisk), the access log on the transmitter will show the IP address of the transmitter where the broadcast came from, rather than an asterisk.
Clips which were broadcast using back-channel multicasts can be identified with the protocol statement, which will be either PNAM or RTSPM. The same clip, delivered via unicast, will show PNAT or RTSPT if the TCP transport was used, or PNA or RTSP if UDP was used.
Client data for live events is transmitted at the conclusion of the broadcast. Entries will not appear in the access log until the client stops playing the event-which could be when the live event is over or if the user clicks the Stop button. In scalable multicasts, which can reach tens of thousands of clients, this volume of client data can overwhelm RealServer. The optional Send Client Statistics feature instructs clients to send their data to a Web server, which may be better equipped to handle the large quantities of HTTP posts. See "Controlling Client Statistics" for instructions on configuring this feature.
A scalable multicast broadcast will create either one record or two for each client that connects. The number of records generated depends on whether Send Client Statistics is in use.
If Send Client Statistics is set to True, two records are created for each client that connects to a scalable multicast. The first record created when the user clicks the link to the .sdp file. The .sdp file generates a request for the actual live file, which appears in the second record. This second record is created at the end of the multicast, or when the user clicks the Stop button.
If Send Client Statistics is set to False, only one record appears in the access log. The .sdp file, which handled the initial request, will appear in the log. No record is created for the live file.
The access log does not show whether access control rules are in use. Only clients whose IP addresses were approved by the access control rules, and who supplied the proper name and password (if required) are allowed to receive content.
Authenticated content is identified by the /secure/ mount point in the path shown in the GET statement.
You can identify which on-demand files were served by the ISP hosting feature by comparing the filename in the GET statement to the /path/ value in the user list file.
The Java Monitor shows files that are being viewed presently; the access log provides a historical report of all the files that have been served. All the files that Java Monitor shows will appear in the access log when they finish playing.
The access log file shows all files served by RealServer, including all RealSystem Administrator Web pages. These appear in the GET statement; you can easily identify them because they all begin with admin. For example, "GET admin/index.html HTTP 1.0" shows the opening RealSystem Administrator page. If you make changes using RealSystem Administrator, the confirmation page that appears in RealSystem Administrator is also recorded in the access log.
When Logging Style is 5, a number at the end of each record gives presentation _id. For RealSystem Administrator pages, this number associates the elements on a particular page. All the images that go with each page also appear in the access log. All files served that are related to a particular page are numbered sequentially.
When Logging Style is 5, the presentation_id field assigns the same number to all files that were delivered as part of the same presentation-whether via SMIL file or Ram file. The numbers are generated by RealServer in sequence, restarting at 0 when RealServer restarts.
Each file referenced by a SMIL presentation, including the SMIL file itself, generates a record in the access log. When Logging Style is 5, all files referenced by the SMIL file, as well as the SMIL file itself, will have the same number. For example, the sample files presentation.smi, presentation.rt, presentation.rp, and presentation.rm all have the same number in the presentation_id field, such as 432.
 |
Note |
|---|
If the SMIL file was requested via a link that used
Ramgen in the URL, an additional record is created for
the Ramgen statement, and shows a different value for
the presentation_id field.
|
All the files referenced by the Ram file will each generate a record in the access log. Because Ram files are served by a Web server, and not RealServer, there is no record created in the access log for the Ram file itself.
When Logging Style is 5, all the files referenced by a Ram file will have the same presentation_id number.
To read the contents of the access log, you must first look up the values of Logging Style and Stats Mask, as these determine how much information is present in the access log. Use RealSystem Administrator to find out the values for these variables by clicking General Setup>Logging. At installation, Logging Style is set to 5 and Stats Mask is 3.
Logging Style provides information about RealServer clip-serving activity. Client information is provided by Stats Mask. However, clients have the ability to prevent some statistics (Stat1, Stat2, and Stat3) from appearing in the access log. If this option is selected in the client, UNKNOWN appears in place of that statistics field.
Once you know the values of these two variables, view the access log by opening rmaccess.log (Windows) or rmaccess (UNIX) file in a word processor or text editor.
|
|
Note |
|---|
| Information on which authenticated files have been accessed is stored in reglog.txt and accesslog.txt. See "Logs Directory". |
RealServer stores information about each clip it serves in a separate record. Each record is delimited by a new line. Fields within each record are separated by spaces.
One record is created for every clip served; if the client requests a presentation that includes several clips, one record is created for each clip in the presentation.
The fields that appear within each record depend on the settings for Logging Style and Stats Mask (these are noted in the "Access Log Format" table below). The complete syntax of each record, assuming Logging Style and Stats Mask are gathering all possible information (Logging Style is 5 and Stats Mask is 7) is shown:
client_IP_address - - [timestamp] "GET filename protocol/version" HTTP_error_code bytes_sent [client_info] [client_GUID] [Stat1:][Stat2:][Stat3:]file_size file_time sent_time resends failed_resends[stream_components]start_time server_address average_bitrate packets_sent presentation_id
The optional [Stat1:], [Stat2:], and [Stat3:] fields, which are the result of the StatsMask variable, are described in greater detail in separate tables.
|
|
Note |
|---|
| Although in the rest of this manual, square brackets indicate optional material, the square brackets shown in the access log actually appear within access log records. |
The following table lists the format for each access log record:
| Access Log Field | Description | |
|---|---|---|
client_IP_address |
IP address of client, such as 123.45.123.45 |
|
- - |
Two hyphens for compatibility with standard Web server log formats. | |
timestamp |
Time that client accessed the file in the format:dd/Mmm/yyyy:hh:mm:ss TZwhere TZ is the time zone expressed as the number of hours relative to the Coordinated Universal Time (Greenwich, England) and is relative to the Server. For example:[31/Oct/1996:13:44:32 -0800] |
|
"GET filename |
File name (and path) requested by the client. Path is everything in the URL after the port number. If the client requests a file that doesn't exist, UNKNOWN appears in place of filename. |
|
protocol/version" |
Application-layer protocol used to send the clip to the client. Possible values are:RTSPIn addition, a letter at the end of the string indicates which transport type was used: |
|
(blank) |
UDP connection | |
| T | TCP connection | |
H |
HTTP connection | |
M |
Multicast | |
For example, PNAT means that the clip was sent using the PNA protocol over a TCP connection. The version number indicates the edition of the protocol. |
||
HTTP_status_code |
Return code using HTTP standard error codes. Usually returns 200. |
|
bytes_sent |
Number of bytes transferred to the client. | |
[client_info] |
Describes the version and type of client being used. Client information appears in the following format, [platform_version_client_type_distribution_language_CPU]For example, Win95_4.0_3.0.0.19_play32_PN01_EN_586If client information can't be gathered (the request came from a client that chose not to send statistics, or from a browser connecting to RealSystem Administrator pages), UNKNOWN appears within the brackets. |
|
| Field | Description | |
platform |
Operating system RealPlayer runs on-Win16, WinNT, Mac, and so on. | |
version |
Operating system version number. | |
client |
Version number of RealPlayer. | |
type |
Type of RealPlayer. | |
distribu-tion |
Distribution code of RealPlayer. | |
language |
Language setting in RealPlayer. | |
CPU |
Type of processor on which the client is running. If the processor does not have a hardware Floating Point Unit, the string "no-FPU" is appended to the end of the CPU field with no delimiter. | |
RealAudio Player 1 shows only two fields for [client_info]. They are platform and client. |
||
[client_GUID] |
Unique ID generated during RealPlayer installation that enables you to track details for individual clients. If client information can't be gathered (the request came from a client that chose not to send statistics, or from a browser connecting to RealSystem Administrator pages), UNKNOWN appears within the brackets. If the user elects to suppress this information, this field will show a series of zeroes: 00000000-0000-0000-0000-000000000000instead of a unique identifier. Refer to "Omitting Client Identifiers". Included when Logging Style is set to 2 or higher. |
|
[Stat1] (see the "Statistics Type 1 Information" table) |
Connection statistics sent by the client when it completes playing a clip (see the "Statistics Type 1 Information" table). When the client blocks connection statistics, the field is replaced by [UNKNOWN]. Note that there is no space between the closing square bracket of this statistics type and the opening square bracket of the next statistics type. Included when Stats Mask is 1, 3, 5, or 7. |
|
[Stat2] (see the "Statistics Type 2 Information" table) |
Extended connection statistics sent by the client when it completes playing a clip (see the "Statistics Type 2 Information" table) . When the client blocks connection statistics, the field is replaced by [UNKNOWN]. Note that there is no space between the closing square bracket of this statistics type and the opening square bracket of the next statistics type.Included when Stats Mask is 2, 3, 6, or 7. |
|
[Stat3] (see the "Statistics Type 3 Information" table) |
Actions taken by the visitor while playing the clip (see the "Statistics Type 3 Information" table). When the client preferences are set to block statistics, this field is replaced by [UNKNOWN]. Note that there is no space between the closing square bracket of the previous statistics type and the opening square bracket of this statistics type.Included when Stats Mask is 4, 5, 6, or 7. |
|
file_size |
Total amount in bytes of media data in the media file. This number is less than the size of the media file because it does not include the file header and other non-media information stored in the file. For live broadcasts, file_size is always 0. Included when Logging Style is set to 1 or higher. |
|
file_time |
Total length, in seconds, of media stored in the media file. For live broadcasts, file_time is always 0.For .smi files, this is always 20. Included when Logging Style is set to 1 or higher. |
|
sent_time |
Total length, in seconds, of the media sent to the client. Included when Logging Style is set to 1 or higher. |
|
resends |
Number of packets successfully re-sent because of transmission errors. Included when Logging Style is set to 1 or higher. |
|
failed_resends |
Number of packets not successfully re-sent in time to correct transmission errors. Included when Logging Style is set to 1 or higher. |
|
[stream_] |
Type of material sent, indicated in the following pattern:RealAudio RealVideo Event Image_maps shows that the stream includes this type, 0 indicates that it does not. Thus, a stream that included RealVideo and RealAudio but no events or image maps would appear in the access log as 1 1 0 0. Included when Logging Style is set to 3 or 4. |
|
start_time |
Timestamp of start time.Included when Logging Style is set to 3 or 4. |
|
server_address |
IP address of RealServer supplying the clip. Included when Logging Style is set to 3 or 4. |
|
average_bitrate |
Average bitrate of clip. Included when Logging Style is set to 4. |
|
packets_sent |
Number of packets sent. Included when Logging Style is set to 4. |
|
presentation_id |
Number used by all clips in the same SMIL or Ram presentation. SMIL files are also included in the log, and use the same number as the clips they reference. The number is assigned by RealServer at the time of transmission. Included when Logging Style is 5. |
|
The format of the access log under each of the different Logging Style values is shown in the table below:
The information gathered by each of the three Statistics Types are listed in this section. Stat1 and Stat2 report information about the RealAudio portion of a clip. Even if a clip includes both RealAudio and RealVideo, these statistics report solely RealAudio information. Stat3 reports information about visitor and client behavior while playing all types of clips or presentations.
When Stats Mask is 0, two square brackets ([]) appear instead of the Stat1, Stat2, and Stat3 sections.
Statistics Type 1 gathers basic information about how successfully audio clips were received by the client. It also tells what the client used to decode the audio portion of the clip.
Syntax of this portion of the access log record:
[Stat1: packets_received out_of_order missing early late audio_format]
The table below gives the information collected by this statistic type:
Statistics Type 2 provides details about the success of clip delivery, giving information about bandwidth requests. Re-sent packets are described in detail here. It identifies which transport type was used to make the connection and which video decoder played the clip. This set of statistics uses the following format:
[Stat2: bandwidth available highest lowest average requested received late rebuffering transport startup format]
The table below explains what information is collected by this statistic type:
Statistics Type 3 provides detailed information about viewer action while listening or viewing clips. It addresses advanced features of the implementation, notably ads and image maps. You can find out at what point in the clip a viewer clicked on an image map or stopped watching the clip.
If Stats Mask is configured to gather statistics type 3 (Stat3), note that the access log file size will grow rapidly. If you configure Stats Mask to collect this information, be sure to review the log file frequently. This statistics type uses the following format:
[Stat3:timestamp|elapsed_time|action|;]
Records of activity are separated by a semicolon (;) and are in the following form:
timestamp|elapsed_time|action|;
Thus, the Stat3 record of a visitor pausing, resuming play, and watching to the clip's end would look like the following:
[Stat3:4360|2107|PAUSE|;8401|2107|RESUME|;12608|6321|STOP|;]
The table below gives the format of the Stat3 records:
RealServer uses the following settings for the access log (you can view these in RealSystem Administrator by clicking General Setup>Logging):
5.
3.
Logs subdirectory of the main RealServer directory. The default file name of the access log file is rmaccess.log (Windows) or rmaccess (UNIX). The directory (if any) typed here can be absolute or relative to the base path of the main mount point.
If Access Log File is blank, RealServer records access information in the rmaccess.log or rmaccess file located in the same directory as the RealServer executable file.
The name of the access file will be different if Log File Rolling is enabled; see "Log File Rolling".
To customize the information gathered in the access log, you must first decide what types of information you want to gather. Then make the appropriate changes to Logging Style, which collects information about RealServer activity, and to Stats Mask, which gathers statistics about what arrived at the client and viewer behavior while playing the clips.
Logging Style has six options, styles 0 through 5. Styles 0 through 4 each includes information of the logging styles with lower numbers. Thus, Logging Style 3 collects the information that's collected by styles 0, 1, and 2, as well as the material gathered by style 3. Logging Style 5 consists of the fields in Logging Style 2, plus the presentation_id field.
If you omit this variable, RealServer uses the default style of 5.
A list of information gathered by each value is given below.
Logging Styles 0, 1, and 3 contain some additional information, as described in "Access Log Format"
Stats Mask supplies more detailed information to the access log. This variable is optional. For a complete description of information collected by each statistics type, and the syntax of the types as they appear in the access log, see the "Statistics Type 1 Information" table, the "Statistics Type 2 Information" table, and the "Statistics Type 3 Information" table.
If you omit a value for Stats Mask, RealServer uses the default value of 3 (gather statistics types 1 and 2).
Not all versions of RealPlayer supply the information requested by Stats Mask; Statistics type 2 is supplied by RealAudio Player versions 3 and later, and Statistics type 3 is supplied by RealPlayer 5 and later.
Normally, every access log record displays a unique client identification number for each user. However, both users and administrators have the option to omit this information from access log records.
If a user elects to withhold his software's unique client number, a string of zeroes appears instead: [00000000-0000-0000-0000-000000000000].
RealServer's default behavior is to use client identifiers, when available. It will show zeroes for those users who have opted to suppress their client software identifiers.
Regardless of the user's setting, you can instruct RealServer to always show the string of zeroes instead of the actual client identifier. If you choose this option, all access log records show zeroes, rather than the actual client identifiers. (This applies only to the logging styles that collect data for the [client_GUID] field-logging styles 2 and higher.)
There is no way to override the client's setting, should the user choose to send only zeroes.
No.
The GET statement within each access log record shows the path and file name of each file that RealServer served, as well as the protocol and protocol version used to stream or broadcast the file. (To see the GET statement in context, refer to the "Access Log Format" table.)
The table below summarizes the format in which each type of content is shown in the access log.
For live streams that use encoders developed for use with version 6 and later software, the file name will begin with encoder. For earlier encoders, the file name begins with live.
The error log contains both information and error messages about Server operation. By looking for patterns of errors, you can troubleshoot and correct possible problems on your site.
View the text of the error log using a word processor or text editor.
The error log is an excellent tool for troubleshooting any problems that may arise with your RealServer. An entry is made to the error log only when an error occurs. If no errors occur, this file will not exist.
If you have an error message that refers to a fatal error, contact the RealNetworks Technical Support Department for assistance.
RealServer uses the following settings to record information in the error log (you can view them from RealSystem Administrator by clicking General Setup>Logging):
Logs subdirectory of the main RealServer directory. The default name of the error log file is rmerror.log.
The error log records client connections and RealServer errors. Each time an error is generated by RealServer, a record is created in the error log. The error log path is stored in the same directory as the access log, indicated by the LogPath variable.
Syntax of the file is as follows:
***date time servername(process_ID):error_message
where entries are defined below:
Log files can grow indefinitely as they accumulate data. To keep log files to a manageable size, you can limit the access log to a week's worth of information or a certain file size, and RealServer will begin a new log file when the limit is reached.
If you supply values for all four boxes, RealServer will use the size or time period that is reached first.
Rolled log files are named with the following format:
name.log.datestamp
If you turn off log file rolling, RealServer will create a single large log file.
0 from the Log Rolling Frequency list in the Access Log section or in the Error Log section.
Whenever RealServer sends a stream, it records that information in the access log. In addition, if RealServer sends a stream to RealProxy, it creates an entry in the cache.log file. Requests that will be stored in caches are identified by the port number to which they send the request.
RealServer uses the following settings to create cache request log files (you can view the settings from RealSystem Administrator by clicking Cache>Cache):
cache.log.
The entries in the cache.log file use one of two formats: a general information format, and a clips served format.
|
|
Note |
|---|
| As with other log files, the brackets within the cache.log file always appear and do not indicate optional material. |
[Day Mmm DD hours:minutes:seconds YYYY]message
[Day Mmm DD hours:minutes:seconds YYYY]IP_address path_filename
where IP_address and path_filename refer to the stored location of the content.
To disable the log file of cache requests, change Cache Requests to Disabled.