戻る 次へ

第 16 章 アクセス ログとエラー ログ

この章では、Helix Universal Server が、クライアントの接続やそのほかのイベントの情報を記録する方法について説明します。ログ ファイルを使うと、システム アクティビティについてのレポートをまとめることができ、必要な統計情報を収集できます。

ヒント : カスタム レポートを設計して、Helix Universal Server 上の特定のアクティビティを追跡したい場合は、第 17 章を参照してください。

ログ ファイルについて

Helix Universal Server では、クライアント接続に関する統計を含むアクセス ログを保持します。また、Helix Universal Server 操作についてのエラーや情報のメッセージについてのログを保持します。これらのログ ファイルはテキスト エディタで開くことができるテキスト ファイルであり、スクリプトやアプリケーションで構文解析できます。アクセスやエラーが発生すると、Helix Universal Server は適切なログ ファイルの終わりに情報を追加します。以下のセクションでは、ログ ファイルとその特徴について説明します。

アクセス ログ

アクセス ログでは、RealNetworks のメディア プレーヤー、Windows Media Player、および QuickTime Player からの要求や Helix Administrator ページに対するブラウザ要求に関する情報を記録します。これらのログを使うと、再生されたクリップや、メディア プレーヤーの接続回数などがわかります。この情報は、たとえば一番人気のあるクリップを判断するのに役立ちます。

デフォルトのアクセス ログは、rmaccess.log です。このファイルは、Helix Universal Server がインストールされているメイン ディレクトリの Logs サブディレクトリにあります。ただし、認証済みファイルへのアクセスに関する情報は、reglog.txt と accesslog.txt に保存されています。これらについては、「Logs ディレクトリ」で説明しています。キャッシュされるストリームに対する要求は、キャッシュ要求ログに保存されます。

ログに記録される情報

Helix Universal Server では、それぞれのアクセス試行で収集する情報量を決定する、6 種類のロギング スタイルがあります。一般に、それぞれのスタイルは、別のスタイルを基にして情報を追加しています。たとえば、ロギング スタイル 0 で収集する情報量は、最も少ないことになります。ロギング スタイル 1 にはスタイル 0 での情報が含まれるだけでなく、ほかの情報も収集します。ほかのスタイルでも同様です。ログ全体に対して選択できるロギング スタイルは 1 つだけです。

詳細情報 : 「アクセス ログ ファイルの形式」では、ロギング スタイルと情報フィールドについて説明しています。

メディア プレーヤーの統計

すべてのロギング スタイルでは、メディア プレーヤーの再生状態に関する統計を記録できます。これらの統計によって、たとえば損失したメディア パケット量や、ユーザーがクリップを停止したかどうかがわかります。クライアント統計には、4 タイプあります。これらの統計 typeは、最高 4 つまで自由に組み合わせて使用できます。また、クライアント統計をまったく収集しないようにすることもできます。同様に、統計をレポートしないように選択することもできます。

詳細情報 : 「クライアント統計」を参照してください。

エラー ログ

エラー ログには、Helix Universal Server の動作に関して、情報とエラー メッセージが含まれます。エラーのパターンを探すことによって、トラブルシューティングを行うことや、サイトで発生する可能性のある問題への対処ができます。デフォルトのファイル名は rmerror.log です。Helix Universal Server のメイン ディレクトリの Logs サブディレクトリに生成されます。Helix Universal Server では、エラーが発生したときにだけ、このログに記録します。エラーが発生するまでは、このファイルは存在しません。エラー ログの構文は、以下のとおりです。 

***date time servername(process_ID):error_message

エラー ログ ファイルでのこれらのフィールドについて、以下の表で説明します。

エラー ログのフィールド
エントリ 意味
*** 3 個のアスタリスクはエラーを表します。情報メッセージの先頭には、アスタリスクは付きません。
date エラーが発生した日。形式は dd-Mmm-YY です。26-Apr-02 のようになります。
time エラーが発生した時刻。Helix Universal Server の時刻を使用します。形式は HH:MM:SS.xyz です。21:05:10.614 のようになります。
servername(process_ID) Helix Universal Server の名前と、プロセス ID。( かっこ内 )
error_message メッセージのテキスト。

注意 :重大なエラーに関するメッセージを受信した場合は、RealNetworks のテクニカル サポートまでお問い合わせください。

ログ ファイルのローリング

アクセス ログとエラー ログのファイル サイズは、データが蓄積するにつれて無限に大きくなります。管理できるサイズにログ ファイルを保つには、ログ ファイルを特定のサイズに制限します。また、アクセス ログの場合は、ログに記録したいデータ量に応じて、6 時間や 2 週間などのプリセットの間隔で新しいログを作成することもできます。Helix Universal Server は、制限値に達すると新しいログ ファイルを作成、つまりローリングします。ローリング設定したログ ファイルは、次の形式で名前付けされます。 

file_name.log.timestamp

「アクセス ログとエラー ログのカスタマイズ」で説明するように、名前と拡張子は、Helix Administrator で設定します。タイムスタンプは 24 時間表記で、以下の形式になります。 

YYYYMMDDHHMMSS

たとえば、以下のファイルは、2002 年 6 月 22 日の午後 1:49.53 に作成されています。 

rmaccess.log.20020622134953

ほかの機能でのアクセス ログの使用

以下のセクションでは、さまざまな機能に関する情報が、アクセス ログ ファイルにどのようにして記録されるのかについて説明します。

Helix Universal Proxy

クリップがプロキシされると、アクセス ログでは接続に関する追加情報を提供します。詳細については、「プロキシされたクリップ情報」を参照してください。

ライブ ユニキャスト

ブロードキャストの終了時にライブ イベントのデータがクライアントから転送されます。エントリは、ライブ イベントが終了するか、[Stop (停止)] がクリックされるまでアクセス ログに記録されません。「GET ステートメント」で説明するように、GET ステートメントに、ユニキャスト イベントとライブ マウント ポイント (通常は /broadcast/ または /encoder/) が記録されます。ライブ イベントには、早送りや一時停止などのユーザー アクションを記録する統計 type 3 は使用できません。

SLTA

SLTA を使用した無限ループで事前に記録したクリップをブロードキャストする場合、ブロードキャストが停止するかクライアントが中断するまで、アクセス レコードは作成されません。

スプリッティング

トランスミッタの場合、アクセス ログにはレシーバ接続に関するレコードは作成されません。ただし、同一のイベントが複数の Helix Universal Servers に転送されている場合は、トランスミッタのアクセス ログにレコードが作成されます。レシーバの場合、アクセス ログには配信されたクリップごとにレコードが作成され、スプリット マウント ポイントについて記録されます。

バックチャネル マルチキャスト

バックチャネル マルチキャストを使用したブロードキャスト クリップは、protocol ステートメントが PNAM または RTSPM であるため識別できます。ユニキャストによって配信された同じクリップは、TCP 転送が使用された場合は PNAT または RTSPT となり、UDP が使用された場合は PNA または RTSP となります。詳細については、「ファイル名とプロトコル」を参照してください。

スケーラブル マルチキャスト

統計の送信時に巨大なスケーラブル マルチキャストが Helix Universal Server に多大な負荷をかけないようにするには、大量の HTTP ポストを処理するよう設計されている Web サーバーによって統計を収集します。この機能の設定方法については、「クライアント統計情報の収集」を参照してください。

アクセス コントロールと認証

アクセス ログを参照しても、アクセス コントロール ルールを使用しているかどうかがわかりません。アクセス コントロール ルールで承認された IP アドレスを持ち、要求があった場合に正しい名前とパスワードを送信したクライアントだけが、コンテンツの受信を許可されます。認証済みコンテンツは、GET ステートメントに示されるパス内の /secure/ マウント ポイントで識別されます。詳細については、「GET ステートメント」を参照してください。

ISP ホスティング

GET ステートメントのファイル名と、ユーザー リスト ファイルの /path/ 値を比較すると、ISP ホスティング機能によって配信されたオンデマンド ファイルを識別できます。

モニタ

Server Monitor を使用すると、現在参照中のファイルを確認できます。アクセス ログでは、過去に配信されたファイルの履歴レポートを確認できます。Server Monitor に表示されたすべてのファイルが、再生の終了後にアクセス ログに記録されます。

Helix Administrator

アクセス ログ ファイルには、Helix Universal Server が配信したすべてのファイルが記録されます。これには、Helix Administrator ページも含まれます。これらは、GET ステートメント内に記述され、先頭は admin です。詳細については、「GET ステートメント」を参照してください。

ロギング スタイル 5 の場合、各レコード末尾の値がプレゼンテーション ID になります。Helix Administrator ページの場合、この値は特定ページの要素に関連付けられます。各ページで表示される画像もすべてアクセス ログに記録されます。同じページに関連付けられたファイルが配信された場合、これらのファイルには連続番号が付けられます。

SMIL ファイル

SMIL プレゼンテーション内のファイルは、SMIL ファイル自身も含め、アクセス ログに 1 つずつレコードを生成します。ロギング スタイル 5 の場合、すべてのファイルには同じ ID 番号が付けられます。たとえば、ファイル presentation.smil、presentation.rt、presentation.rp、および presentation.rm の presentation_ID フィールドは、すべて 432 のような同じ番号になります。Ramgen を使用した URL で SMIL ファイルが要求されると、Ramgen ステートメントに関して追加のレコードが作成されます。このレコードの presentation_ID フィールドは異なる値になります。

Ram ファイル

Ram ファイルにリストされるすべてのファイルは、アクセス ログにそれぞれ 1 つのレコードを生成します。Ram ファイルは Web サーバーが配信するため、 アクセス ログには Ram ファイルに関するレコードは作成されません。ロギング スタイル 5 の場合、Ram ファイルにリストされるすべてのファイルは同一の presentation_ID 番号を持ちます。

アクセス ログ ファイルの形式

Helix Universal Server では、各アクセス要求を、アクセス ログの新しい行に記述した別々のレコードとして記録します。レコード内のフィールドは、スペースまたはパイプ (|) で区切られています。配信されたクリップごとに少なくとも 1 つのレコードが作成されます。つまり、クライアントが複数のクリップを含むプレゼンテーションを要求すると、プレゼンテーション内の各クリップに対して 1 つのレコードが作成されます。プロキシのプルスプリットまたはキャッシュで配信されたクリップのコピーごとに、2 つのレコードが作成されます。

Logging Style (ロギング スタイル)

Helix Universal Server では、0 〜 5 までの番号が割り振られた、6 つのロギング スタイルがあります。スタイル 1 〜 4 には、それぞれそれよりも小さい番号のスタイルの情報が追加されます。たとえば、スタイル 3 では、スタイル 0、１、および 2 と同じ情報が収集されるほかに、いくつか情報が追加されます。デフォルトではスタイル 5 です。これは、スタイル 2 での情報に presentation_ID フィールドを追加しています。以下のセクションでは、各ロギング スタイルで収集するフィールドについて説明します。「アクセス ログ ファイルのフィールド」では、ログに記録される各フィールドの情報について説明します。

ヒント : 角かっこはオプション値とユーザー インターフェイス項目を示しますが、以下のアクセス ログ構文内に出現する角かっこは実際にアクセス ログのレコードに記録されています。

注意 : 以下の例では、クライアント統計のログは記録されていません。そのため、各エントリでは統計のフィールドに相当する部分で [UNKNOWN] と示されています。そのためクライアント統計を収集すると、それぞれのログ エントリには情報が追加されます。詳細については、「クライアント統計」を参照してください。

ロギング スタイル 0

ロギング スタイル 0 は、以下の形式になります。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_stats_results]

これは、実際のログ レコードの例で、要求された 858,636 バイトのクリップが RTSP で送信されたことを表します。 

207.188.7.125 - - [26/Jun/2002:10:31:44 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686] [UNKNOWN]

ロギング スタイル 1

ロギング スタイル 1 は、以下の形式になります。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_stats_results] file_size file_time sent_time resends
failed_resends

以下のサンプル ログ レコードは、ロギング スタイル 0 と同じ情報をあらわしますが、ファイル サイズ、クリップのタイムライン長、ストリームされた実時間、および再送信されたパッケージ数が追加されています。 

207.188.7.125 - - [26/Jun/2002:10:06:33 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686] [UNKNOWN]
926322 217205 1 0

ロギング スタイル 2

これはロギング スタイル 2 の形式です。スタイル 1 と同じですが、クライアント ID を記録する点が異なります。クライアント ID はグローバル ID または Cookie で設定される ID です。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends

たとえば、次のようになります。 

207.188.7.125 - - [26/Jun/2002:10:07:42 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0

ロギング スタイル 3

ロギング スタイル 3 は、以下の形式になります。スタイル 2 に、ストリームと、クリップを配信する Helix Universal Server の情報が追加されます。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends [stream_components] [start_time] server_address

この例では、レコードの末尾にサーバーとストリームの情報が追加されています。 

207.188.7.125 - - [26/Jun/2002:10:09:09 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0
[1 1 0 0] [26/Jun/2002:10:05:14] 208.147.89.157

ロギング スタイル 4

ロギング スタイル 4 では、クリップの平均ビット レートと送信されたパケット数が追加されます。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends [stream_components] [start_time] server_address
average_bitrate packets_sent

たとえば、次のようになります。 

207.188.7.125 - - [26/Jun/2002:10:10:04 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0
[1 1 0 0] [26/Jun/2002:10:05:14] 208.147.89.157 34816 488

ロギング スタイル 5

ロギング スタイル 5 は、デフォルトのスタイルです。このスタイルはこれまでのスタイルが基にはなっていません。その代わり、スタイル 2 にプレゼンテーション ID を追加したものになります。プレゼンテーション ID は、複数クリップを含むプレゼンテーションを追跡するのに役立ちます。 

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends presentation_ID

以下は、ロギング スタイル 5 のエントリの例です。 

207.188.7.125 - - [26/Jun/2002:10:11:03 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0 124

アクセス ログのフィールド

アクセス レコードにでてくるさまざまなログ フィールドについて以下の表にまとめ、あわせて、そのフィールドが含まれるロギング スタイルについて示します。以下のセクションでは、アクセス ログのフィールドについて、詳しく説明します。

アクセス ログのフィールド
ログのフィールド ロギング スタイル 参照
IP_address 0, 1, 2, 3, 4, 5 ここをクリックしてください。
[timestamp] 0, 1, 2, 3, 4, 5 ここをクリックしてください。
"GET filename protocol/version" 0, 1, 2, 3, 4, 5 ここをクリックしてください。
HTTP_status_code 0, 1, 2, 3, 4, 5 ここをクリックしてください。
bytes_sent 0, 1, 2, 3, 4, 5 ここをクリックしてください。
[client_info] 0, 1, 2, 3, 4, 5 ここをクリックしてください。
[client_ID] 2, 3, 4, 5 ここをクリックしてください。
[client_stats_results] 1, 2, 3, 4, 5 ここをクリックしてください。
file_size 1, 2, 3, 4, 5 ここをクリックしてください。
file_time 1, 2, 3, 4, 5 ここをクリックしてください。
sent_time 1, 2, 3, 4, 5 ここをクリックしてください。
resends 1, 2, 3, 4, 5 ここをクリックしてください。
failed_resends 1, 2, 3, 4, 5 ここをクリックしてください。
[stream_components] 3, 4 ここをクリックしてください。
[start_time] 3, 4 ここをクリックしてください。
server_address 3, 4 ここをクリックしてください。
average_bitrate 4 ここをクリックしてください。
packets_sent 4 ここをクリックしてください。
presentation_ID 5 ここをクリックしてください。

IP アドレス

IP_address フィールドには、クライアントの IP アドレスを指定します。123.45.123.45 など。メディアがクライアントに対してプロキシされている場合は、プロキシの IP アドレスがログに表示されます。詳細については、「プロキシされたクリップ情報」を参照してください。IP アドレスのあとには、標準の Web サーバー のログ形式と互換性を持つための 2 個のハイフンが続きます。

タイムスタンプ

[timestamp] フィールドは、クライアントがファイルにアクセスした時刻を、Helix Universal Server の時刻で示します。以下の形式を使用します。 

[dd/Mmm/yyyy:hh:mm:ss TZ]

ここで、TZ はタイム ゾーンであり、協定世界時 (英国グリニッチ) に対する相対時間で表されます。例を示します。 

[26/Jun/2002:10:10:04 -0700]

ファイル名とプロトコル

"GET filename protocol/version" フィールドには、クライアントが要求したファイル名とパスがリストされます。パスは、ポート番号以降のすべてです。クライアントが要求したファイルが存在しなかった場合は、ファイル名が UNKNOWN になります。クライアントにクリップを送信するためのアプリケーション レイヤ プロトコルで可能な値は、RTSP、PNA、MMS、およびHTTP です。また、末尾の文字は以下のような転送タイプを示します。

(なし) UDP 接続
T TCP 接続
H HTTP 接続
M マルチキャスト

たとえば、RTSPT は TCP 接続で RTSP プロトコルを使用してクリップがストリームされたことを示します。バージョン番号は、プロトコルのエディションを示します。

詳細情報 : 「GET ステートメント」を参照してください。

HTTP ステータス コード

HTTP_status_code フィールドは、HTTP 標準エラー コードによるリターン コードになります。通常、200 を返します。

送信バイト数

bytes_sent フィールドでは、クライアントへの転送バイト数を記録します。プロキシ キャッシュやプル スプリッティングによって、メディアがクライアントに対してプロキシされている場合、「プロキシされたクリップ情報」で説明するように、クライアント接続ごとに 2 レコードが記録されます。

クライアント情報

[client_info] フィールドでは、クライアントのバージョンとタイプを説明します。

RealNetworks クライアント

RealNetwork クライアントでは、[client_info] で以下の形式を使用します。 

[platform_version_client_type_distribution_language_CPU]

以下の情報が記録されます。

platform クライアント ソフトウェアが動作しているオペレーティング システム。WinNT、Mac など。
version オペレーティング システムのバージョン番号。
client クライアント ソフトウェアのバージョン番号。
type クライアント ソフトウェアのタイプ。
distribution クライアント ソフトウェアの配布コード。
language クライアント ソフトウェアの言語設定。
CPU クライアントが動作しているプロセッサのタイプ。ハードウェア浮動小数点ユニットが搭載されていないプロセッサでは、CPU フィールドの末尾に区切り文字なしで文字列 no-FPU が追加されます。

例を示します。 

[WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]

注意 :RealAudio Player 1 では、[client_info] には 2 つのフィールドだけがログに記録されます。 platform と client です。

Windows Media Player

Windows Media Player では、[client_info] フィールドに、次のようにプレーヤーのバージョンが記録されます。 

[NSPlayer/7.1.0.3055]

QuickTime Player

QuickTime Player では、プレーヤーのバージョンとオペレーティング システムが記録されます。下記に例を示します。 

[QTS (qtver=5.0.2;os=Windows NT 5.0)]

不明なクライアント

要求したクライアントが統計を送信しないように設定されていたり、Helix Administrator のページを要求しているブラウザから要求があったりするために、クライアント情報を収集できない場合、[client_info] フィールド内は [UNKNOWN] となります。

プロキシされたメディア

メディアがクライアントに対してプロキシされている場合は、少なくとも、プロキシされたクライアントのバージョンとタイプがログに表示されます。プロキシのプル スプリッティングやキャッシュによって配信されたメディアでは、追加レコードとして RealNetworks Broadcast Receiver、または Helix Universal Proxy のバージョンとタイプが表示されます。下記に例を示します。 

[linux-2.2-libc6-i586-server_RealProxy_9.0.2_RealNetworks]

詳細情報 :「プロキシされたクリップ情報」を参照してください。

クライアント識別子

[client_ID] では、各メディア プレーヤーの識別番号が記録されます。識別番号はグローバル一意識別子になります。RealNetworks のプレーヤの場合は、Cookie を基にした ID です。以下のセクションでは、使用できるフィールド エントリを説明します。Helix Universal Server と RealNetworks のプレーヤのデフォルト設定では、クライアントのアクセス試行ごとに Cookie ベースの ID が記録されます。しかし、ユーザーは ID の転送と Cookie の受け入れについて、コントロールすることが可能です。同様に、GUID のロギングや Cookie の設定を、クライアントの設定に関係なく、Helix Universal Server を通じて無効にすることができます。

詳細情報 : クライアント ID のロギングを無効にする方法については、「アクセス ログの変更」を参照してください。

RealNetworks クライアントのグローバル一意識別子 (GUID)

RealNetworks のプレーヤがグローバル一意識別子を送信するように構成されている場合は、そのようになります。ただし、プライバシー保護の観点から、RealOne Player のデフォルトは、GUID を送信しません。GUID の送信は各ユーザーの裁量であるため、アクセス ログにユーザーの GUID が表示されるようにするには、ユーザーはデフォルトの GUID 設定を変更しなければなりません。RealOne Player で GUID のレポートを制御するユーザー コマンドは、[Tools (ツール)] > [Preferences (環境設定)] > [Connection (接続)] > [Internet Settings (インターネットの設定)] の順にクリックします。

詳細情報 : RealNetwork の Consumer Software Privacy Statement を確認するには、http://www.realnetworks.com/company/privacy/software. html を参照してください。

RealNetworks クライアントの Cookie ベースの ID

RealNetworks のプレーヤが GUID をレポートするようになっていない場合、Helix Universal Server ではクライアントの Cookie を基にした ID をログに記録します。この Cookie は、クライアントが最初にアクセスしたときに設定されます。それ以降のアクセス時には、クライアントは Cookie に設定された ID を返します。Cookie ベースの ID は GUID と同じ形式であり、そのクライアントにコンテンツを配信する Helix Universal Server ごとに一意です。ただし、同じクライアントでも、通信する Helix Universal Server ごとに異なる ID を返します。

RealNetworks のプレーヤの場合、デフォルトで Cookie は有効ですが、ユーザーは Cookie を受け入れないように選択することもできます。その場合、Helix Universal Server では設定しようとした ID の値を記録しますが、 Cookie が拒否されたことは認識されません。同じクライアントが、次回のメディア要求で Cookie ベースの ID を返さないときは、Helix Universal Server によって別の Cookie が送信され、もう一度、拒否された Cookie の ID を記録します。これは、そのメディア プレーヤーからメディア要求があるたびに発生し、毎回同じメディア プレーヤーから Cookie が拒否されるために、異なる ID がリストされた複数レコードが記録されてしまいます。

注意 : RealOne Player で Cookie を制御するには、[Tools (ツール)] > [Preferences (環境設定)] > [Connection (接続)] > [Internet Settings (インターネットの設定)] の順にクリックします。

Windows Media Player の ID と QuickTime Player の ID

Windows Media Player と QuickTime Player で GUID を送信するように構成されている場合、Helix Universal Server では、その ID の値を記録します。プレーヤーが GUID を送信しない場合は、ログ用に ID を生成します。その場合、ログでは、同じメディア プレーヤーが複数の ID で識別されることがあります。Windows Media Player と QuickTime Player では、Cookie ベースの ID をサポートしていません。

不明な ID

クライアントが GUID や Cookie をサポートしていない (Helix Administrator ページを要求しているブラウザなど) ために、Helix Universal Server で ID を収集できないときは、中に何もない角かっこ—[ ]—が [client_ID] フィールドに表示されます。GUID のレポートがサーバーやメディア プレーヤー側で無効であり、さらに Helix Universal Server で Cookie ベースの ID を設定しようとしない場合は、[client_ID] フィールドに、次のように、一意のクライアント識別子ではなく、連続した 0 が表示されます。 

00000000-0000-0000-0000-000000000000

統計の結果

[client_stats_results] フィールドには、「クライアント統計」で説明するように、クリップの再生終了時にクライアントが送信する拡張接続統計が記録されます。クライアントが接続統計の送信をブロックしている場合や統計が収集できない場合、このフィールドは [UNKNOWN] と表示されます。

ファイル情報

以下の各フィールドには、要求されたクリップに関する情報が保持されます。

再送信情報

resends フィールドでは、転送エラーが原因で再送信されたパケットのうち、成功したパケット数がリストされます。failed_resends フィールドには、転送エラーを修正するために再送信されたパケットのうち時間内に送信が成功しなかったパケット数が示されます。

ストリーム コンポーネント

[stream_components] フィールドは、RealNetworks のメディア プレーヤーの場合だけ記録されます。送信されたコンテンツのタイプを示し、以下のパターンで表されます。 

RealAudio_stream RealVideo_stream Event_stream Image_maps

値 1 は、クリップにそのタイプのストリームが含まれていることを表します。値 0 はそうでないことを表します。したがって、RealVideo や RealAudio を含み、イベント ストリームやイメージ マップを含まないクリップは、以下のようにアクセス ログに記録されます。 

1 1 0 0

開始時刻

[start_time] フィールドは、クリップがストリームし始めたときのタイムスタンプを、Helix Universal Server の時刻で示します。各アクセス レコードの先頭にあるタイムスタンプの形式は同じですが、協定標準時からの時間差はリストされません。たとえば、次のようになります。 

[26/Jun/2002:10:05:14]

サーバーのアドレス

server_address フィールドには、クリップを配信した Helix Universal Server の IP アドレスがリストされます。

平均ビット レート

average_bitrate フィールドは、クリップの平均ビット レートをリストします。単位はビット/秒 (bps)。

送信パケット数

packets_sent フィールドでは、クライアントへの送信パケットの合計数をリストします。

プレゼンテーション ID

presentation_ID フィールドでは、同一の SMIL プレゼンテーションまたは Ram プレゼンテーション内のすべてのクリップに使用される値が記録されます。SMIL ファイル自身もログに記録され、そのクリップと同じ値が使用されます。たとえば、SMIL ファイル、ビデオ クリップ、および GIF 画像のログ エントリすべてで、プレゼンテーション ID 437 がリストされる場合、その SMIL ファイルはビデオと画像で構成されていると結論付けることができます。Helix Universal Server では、クリップを転送するときに、ID を割り当てます。この ID は、ロギング スタイル 5 の場合にだけ記録されます。

プロキシされたクリップ情報

クリップがプロキシされると、プロキシのプル スプリッティングまたはキャッシュで配信された、プロキシされたクリップごとに 2 つのレコードが作成され、アクセス ログでは接続に関する追加情報が提供されます。パススルーで配信されたプロキシされたクリップは、アクセス ログに 1 レコードで記録されます。アクセス ログに含まれるプロキシ固有のデータについて、Helix Universal Proxy 配信のタイプと、アクセス ログ フィールドでまとめ、以下の表に示します。

プロキシされたクリップのアクセス ログのデータ
プロキシ配信 アクセス ログのレコード アクセス ログのフィールド
IP_address bytes_sent [client_info]
ライブ
プル スプリット		 プロキシ制御チャネル Helix Universal Proxy の IP アドレス 0 プロキシされたクライアントのバージョンとタイプ
プロキシ ライブ データ チャネル Helix Universal Proxy の IP アドレス プロキシへの送信バイト数 RealNetworks Broadcast Receiver
オンデマンド キャッシュ プロキシ制御チャネル Helix Universal Proxy の IP アドレス 0 プロキシされたクライアントのバージョンとタイプ
プロキシ キャッシュ データ チャネル Helix Universal Proxy の IP アドレス プロキシへの送信バイト数 プロキシ サーバーのバージョンとタイプ
パススルー プロキシされたクライアント接続 Helix Universal Proxy の IP アドレス プロキシへの送信バイト数 プロキシされたクライアントのバージョンとタイプ

注意 : Helix Universal Proxy と Helix Universal Server とのあいだの制御チャネルのレコードでは、実際のデータが別々のデータ チャネルで送信されるため、bytes_sent の値は 0 (ゼロ) になります。

GET ステートメント

アクセス ログのレコード内にある GET ステートメントには、Helix Universal Server が配信したファイルのパスとファイル名に加えて、ファイルのストリーミングまたはブロードキャストに使用したプロトコルおよびプロトコル バージョンが示されています。以下のセクションでは、オンデマンドとライブ コンテンツのさまざまなタイプで使われる GET ステートメントのエントリ例を示します。

詳細情報 :レコード内の GET ステートメントを見るには、「ロギング スタイル」を参照してください。

オンデマンド コンテンツ

オンデマンド コンテンツのそれぞれのタイプが、アクセス ログの GET ステートメントで表示される形式を、以下の表に示します。SMIL プレゼンテーションの場合は、SMIL ファイルと、プレゼンテーション内のファイルとで、別々のレコードが生成されます。ロギング スタイルが 5 の場合、各アクセス レコードの末尾にある数字の識別子によって、どのファイルが同じプレゼンテーションにあるかを特定できます。

GET ステートメントとオンデマンド コンテンツ
機能 プロトコル アクセス ログのステートメント例
オンデマンド ストリーミング コンテンツ RTSP "GET presentation/presentation.rm RTSP/1.0"
PNA "GET presentation/presentation.rm PNA/10"
HTTP "GET presentation/presentation.rm PNH/10"
SMIL ファイル (SMIL ファイルについて 1 レコード、SMIL ファイル内の各ファイルについて 1 レコード) RTSP "GET presentation/presentation.smi""GET presentation/presentation.rt"
"GET presentation/presentation.rp"
"GET presentation/presentation.rm"
ISP ホスティング — アカウント ベース RTSP "GET ~schu/music.rm RTSP/1.0"
PNA "GET ~schu/music.rm PNA/10"
HTTP "GET ~schu/music.rm PNH/10"
ISP ホスティング — 専用 RTSP "GET s/sc/schu/music.rm RTSP/1.0"
PNA "GET s/sc/schu/music.rm PNA/10"
HTTP "GET s/sc/schu/music.rm PNH/10"
Helix Administrator アクティビティ HTTP "GET admin/index.html HTTP/1.0"
ソース要求の参照 (オンデマンドおよびライブ クリップ) HTTP "GET viewsource/template.html HTTP/1.0"
認証済みオンデマンド ストリーミング コンテンツ RTSP "GET secure/topsecret.rm RTSP/1.0"
PNA "GET secure/topsecret.rm PNA/10"
HTTP "GET secure/topsecret.rm PNA/10"

ライブ ブロードキャスト

ライブ コンテンツのそれぞれのタイプが、アクセス ログで表示される形式を、以下の表にまとめます。Helix Producer 以降からのライブ ストリームでは、ブロードキャストのマウント ポイントは、通常、broadcast/ か redundant/ になります。RealProducer G2 〜 8.5 の場合は、encoder/ です。それ以前のエンコーダでは、live/ になります。Windows Media ブロードキャストの場合、マウント ポイントは通常 /wmtencoder/ になります。QuickTime の場合は qtencoder/ です。

ほとんどのクリップはアクセス ログのレコードは 1 つになりますが、スケーラブル マルチキャストで配信されたクリップでは、クライアントごとに 2 つのレコードが生成されます。1 つは .sdp ファイルに対するレコードで、もう 1 つはライブ ブロードキャスト ストリームに対するレコードです。ただし、ユーザーが Web ページのリンクをクリックするのではなく、.sdp ファイルを保存し、そのファイルを開いて接続する場合は、ライブ ブロードキャスト ストリームについてだけレコードが生成されます。スケーラブル マルチキャストの詳細については、「スケーラブル マルチキャストの設定」を参照してください。

ライブ コンテンツの GET ステートメント例
機能 プロトコル アクセス ログのステートメント例
Helix Producer 以降によるユニキャスト コンテンツ RTSP "GET broadcast/live.rm RTSP/1.0"
PNA "GET broadcast/live.rm PNA/10"
HTTP "GET broadcast/live.rm PNH/10"
ユニキャストされた冗長コンテンツ RTSP "GET redundant/live.rm RTSP/1.0"
PNA "GET redundant/live.rm PNA/10"
HTTP "GET redundant/live.rm PNH/10"
RealProducer G2 〜 8.5 によるユニキャスト コンテンツ RTSP "GET encoder/live.rm RTSP/1.0"
PNA "GET encoder/live.rm PNA/10"
HTTP "GET encoder/live.rm PNH/10"
G2 より前のエンコード ソースからのユニキャスト コンテンツ RTSP "GET live/live.rm RTSP/1.0"
PNA "GET live/live.rm PNA/10"
HTTP "GET live/live.rm PNH/10"
SLTA コンテンツ 任意 ライブ ユニキャスト コンテンツと同じ
認証済みライブ ストリーミング コンテンツ RTSP "GET secure/broadcast/live.rm RTSP/1.0"
PNA "GET secure/broadcast/live.rm RTSP/1.0"
HTTP "GET secure/broadcast/live.rm RTSP/1.0"
プッシュ スプリット — トランスミッタのアクセス ログ RTSP 作成されるレコードなし
PNA
プッシュ スプリット — レシーバのアクセス ログ RTSP "GET broadcast/Japan/broadcast/live.rm RTSP/1.0"
PNA "GET broadcast/Japan/broadcast/live.rm PNA/10"
プル スプリット — トランスミッタのアクセス ログ RTSP 作成されるレコードなし
PNA
プル スプリット — レシーバのアクセス ログ RTSP "GET broadcast/pull/Japan:2030/encoder/live.rm RTSP/1.0"
PNA "GET broadcast/pull/Japan:2030/encoder/live.rm PNA/10"
マルチキャスト — バックチャネル RTSP "GET encoder/live.rm RTSPM/1.0"
PNA "GET encoder/live.rm PNAM/10"
マルチキャスト — スケーラブル (通常、2 つのレコードを作成) HTTP と RTP "GET concert.rm.sdp HTTP/1.0"
"GET concert.rm RTP/2.0"

詳細情報 : ブロードキャスト マウント ポイントについては、第 7 章で説明します。

クライアント統計

すべてのロギング スタイルには、これまでのセクションで [client_stats_results] とされた、クライアント統計が含まれます。統計には 4 タイプあり、アクセス ログにはこれらの任意の組み合わせで記録できます。統計の各組は、角かっこで囲まれ、Stat1 などの接頭辞が付きます。4 タイプの統計すべてのログを記録する場合、[client_stats_results] は以下のようになります。 

[Stat1:statistics_1][Stat2:statistics_2][Stat3:statistics_3][Stat4:statistics_4]

ほかのアクセス ログのフィールドはスペースで区切られますが、この統計 type を閉じるかっこと、次の統計 type を開くかっこの間に、スペースはありません。統計 type 1 を収集するロギング スタイル 5 (ここをクリック) の例を以下に示します。 

207.188.7.125 - - [26/Jun/2002:10:11:03 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[00000000-0000-0000-0000-000000000000] [Stat1:487 2 1 2 0
44_kbps_Stereo_Music_High_Response_-_RA8] 926322 217 205 1 0 124

以下のセクションでは、4 つの統計 type それぞれで収集される情報について説明します。統計 1 および 2 では、再生に関する基本的な情報がレポートされます。統計 3 では、ユーザー アクションについての情報が提供されます。統計 4 では、RealOne Player から得られる高度な再生情報についてレポートされます。デフォルトのロギング設定では、統計 1 および 2 を収集します。さまざまな統計 type を送信できるメディア プレーヤーとバージョンについて、以下の表に示します。

メディア プレーヤーとサポートされるクライアント統計 type
メディア プレーヤー 統計 1 統計 2 統計 3 統計 4
RealPlayer 2 以前 はい いいえ いいえ いいえ
RealPlayer 3 以降 はい はい いいえ いいえ
RealPlayer 5 以降 はい はい はい いいえ
RealOne Player 以降 はい はい はい はい
Windows Media Player 制限あり 制限あり はい いいえ
QuickTime Player いいえ いいえ いいえ いいえ
そのほかの RTP ベースのプレーヤー いいえ いいえ いいえ いいえ

クライアント統計については、次の点に注意してください。

統計 type 1

統計 type 1 には、クライアントによるメディア クリップの受信状況に関する基本情報が収集されます。クライアントがクリップのオーディオ部分をデコードするために使用したコーデックも含まれます。RealNetworks のメディア プレーヤーの場合、これらの統計は、クリップのオーディオ ストリームにだけ適用されます。フィールドは以下のとおりです。 

[Stat1:received out_of_order missing early late codec]

これらのフィールドで提供される情報は以下のとおりです。

received クライアントが受信したパケット数の合計。
out_of_order クライアントが受信したが順序通りでなかったパケット数。これらのパケットの順序は、クライアントがクリップを再生すると並べ替えられます。Windows Media Player ではこの情報が記録されません。
missing クライアントが要求したパケットのうち受信できなかったパケット数。
early クライアントが要求したパケットのうち受信が早かったパケット数。Windows Media Player ではこの情報が記録されません。
late クライアントが要求したパケットのうち受信が遅すぎたパケット数。Windows Media Player ではこの情報が記録されません。
codec Windows Media Player の場合は、使用されるオーディオとビデオのコーデック名。RealNetworks クライアントの場合は、サウンドトラックをエンコードするためのオーディオ コーデック名。RealNetworks のメディア プレーヤーでの有効値は以下のとおりです。
sipr— RealAudio バージョン 5 形式
dnet— RealAudio バージョン 3 形式
28.8— RealAudio バージョン 2 の 28.8 形式
lpcJ— RealAudio バージョン 2 の 14.4 形式
cook— RealAudio バージョン 6 形式

統計 type 2

統計 type 2 には、クリップ配信状況の詳細と、帯域幅要求に関する情報が記録されます。再送信されたパケットの詳細がわかります。この統計 type では、接続の確立に使用した転送タイプや、クリップを再生したオーディオ コーデックについても記録されます。RealNetworks のメディア プレーヤーの場合、これらの統計は、クリップのオーディオ ストリームにだけ適用されます。この統計値の形式は以下のとおりです。 

[Stat2:bandwidth available highest lowest average requested received late 
rebuffering transport startup codec]

これらのフィールドで提供される情報は以下のとおりです。

bandwidth クリップの帯域幅。単位はビット/秒 (bps)。
available ユーザーによるクリップ再生中の平均 bps。Windows Media Player ではこの情報が記録されません。
highest クライアントによるパケットの再送要求から、再送されたパケットの到着までの最長時間。単位はミリ秒。Windows Media Player ではこの情報が記録されません。
lowest クライアントによるパケットの再送要求から、再送されたパケットの到着までの最短時間。単位はミリ秒。Windows Media Player ではこの情報が記録されません。
average クライアントによるパケットの再送要求から、再送されたパケットの到着までの平均時間。単位はミリ秒。Windows Media Player ではこの情報が記録されません。
requested クライアントが要求した再送パケット数。
received クライアントが受信した再送信パケット数の合計。
late クライアントが要求した再送信パケットのうち受信が遅すぎたパケット数。
rebuffering クリップの再バッファ率。
transport 接続の転送タイプ。値は以下のとおりです。
0—UDP
1—TCP
2—IP マルチキャスト
3—HTTP 上の PNA
startup クライアントが最初のクリップ データ パッケージを受信したメディア要求の時刻。単位はミリ秒。データはクリップ再生の開始前に到着することがあります。
codec Windows Media Player の場合は、使用されるオーディオとビデオのコーデック名。RealNetworks クライアントの場合は、サウンドトラックをエンコードするためのオーディオ コーデック名。有効値は以下のとおりです。
sipr— RealAudio バージョン 5 形式
dnet— RealAudio バージョン 3 形式
28.8— RealAudio バージョン 2 の 28.8 形式
lpcJ— RealAudio バージョン 2 の 14.4 形式
cook— RealAudio バージョン 6 形式

統計 type 3

統計 type 3 には、クリップを再生中でライブ ブロードキャストを受信していないあいだの、ユーザーのアクションに関する詳細情報が記録されます。広告やイメージ マップなど、ストリーミングの拡張機能に対応しています。たとえば、ユーザーがイメージ マップをクリックしたり、クリップを停止したりしたときの時刻がわかります。ユーザーは複数のアクションを行うことがあるため、これらの統計を収集すると、アクセス ログ ファイルのサイズは急速に大きくなります。ログ ファイルを頻繁に確認するか、ログが管理可能なサイズに収まるようにログ ファイルのローリングを設定してください。この統計 type が使用する形式は以下のとおりです。 

[Stat3:timestamp|elapsed_time|action|;]

アクティビティのレコードは、セミコロン (;) で区切られます。そのため、ユーザーが一時停止、再生の再開、クリップ終了まで再生を行った場合の Stat3 レコードは、以下のようになります。 

[Stat3:4360|2107|PAUSE|;8401|2107|RESUME|;12608|6321|STOP|;]

タイムスタンプ

最初のタイムスタンプのフィールドは、アクションが発生したときの時刻をミリ秒単位で表示します。クライアントの接続時刻からの経過時間で示されます。前の例では、最初のタイムスタンプは 4360 であり、クライアント接続後 4.360 秒の時点でこのアクションが発生したことを表します。

経過時間

elapsed_time フィールドでは、アクションが発生した時点が、クリップのタイムラインでどれだけ過ぎたかをミリ秒で表します。前の例では、PAUSE アクションが 2107 の時点で発生しており、クリップのタイムラインで 2.107 秒であることを表します。RESUME アクションも、同じ経過時間でリストされます。これは、このアクションでは、一時停止したのと同じ時点でクリップが再開されるためです。

アクション

アクション フィールドには、STOP、PAUSE など、後述のいくつかのアクションから 1 つが記録されます。

CLICK

ユーザーがイメージ マップをクリック。詳細情報は以下のとおりです。

x-coord クリック位置の水平座標。
y-coord クリック位置の垂直座標。
action 発生したアクション。この値は、以下のどれかになります。

PLAYER="url"—ユーザーがクリックしたメディア リンクの URL。
URL="url"—ユーザーがクリックしたブラウザ リンクの URL。
SEEK="destination"—シーク先のポイント。ミリ秒。

PAUSE

ユーザーによるクライアントの一時停止。

RESUME

一時停止後、シーク後、または終了後の再開。

SEEK

シーク先のポイント。単位はミリ秒。

STOP

クリップの終わりに到達。

RECSTART

メディア プレーヤーがクリップのレコーディングを開始。

RECEND

メディア プレーヤーがクリップのレコーディングを終了。

統計 type 4

統計 type 4 は、RealOne Player からだけ送信されます。この統計 type では、統計 type 1 および 2 とほぼ同じ情報を収集し、さらにビデオ クリップの映像トラックを含む、各ストリームのパケットや帯域幅の情報が追加されています。統計 type 4 で使用する形式は以下のとおりです。 

[Stat4:stream_number|mime_type|codec|received|lost|resent|average_bandwidth
|current_bandwidth|;...information for next stream...|transport turobplay duration
clip_end]

以下は、RealVideo Clip に対する統計 type 4 のログ エントリの例です。 

[Stat4:2 audio/x-pn-realaudio|44_kbps_Stereo_Music_High_Response_-_RA8
|44100|940|0|0|;video/x-pn-realvideo|N/A|180889|2918|0|0| 1 0|1|0| 90 2]

注意 : 統計 type 4 を、統計 type 1 や 2 とあわせて有効にしても、RealOne Player がレポートするのは統計 type 4 だけです。ただし、ほかのメディア プレーヤーの場合は統計 type 1 または 2 がレポートされ、統計 type 4 はレポートされません。

ストリーム数

stream_number フィールドでは、クリップに含まれるメディア ストリームの数を示します。ビデオ クリップには、オーディオ トラックに 1 つと映像トラックに 1 つ、というように 2 つのストリームが含まれています。この後に続いて、各ストリームの情報がレポートされます。

ストリーム情報

各ストリームの情報がレポートされます。情報は、セミコロンで終わります。各ストリームでは、以下のフィールドがレポートされます。

mime_type MIME タイプ。audio/x-pn-realaudio など。
codec ストリームで使われるコーデック。44_kbps_Stereo_Music_High_Response_-_RA8 など。
received 受信パケット数。
lost 消失パケット数。
resent 再送信パケット数。
average_bandwidth クリップを再生するあいだの平均帯域幅。単位はビット/秒 (bps)。
current_bandwidth 統計がレポートされるときに使われる帯域幅。単位はビット/秒 (bps)。

トランスポート

transport フィールドでは、接続に使われるトランスポート プロトコルについて表示します。値は以下のとおりです。

0 IP マルチキャスト
1 UDP
2 TCP
3 HTTP クローキング

TurboPlay

3 つの turboplay フィールドでは、RealOne Player の TurboPlay 機能の使用とその結果について示されます。3 つのフィールドは、以下のようにパイプで区切られます。 

1|513234|1120

次の表は、使用できる値をまとめたものです。2 番目と 3 番目のフィールドの値は、TurboPlay がオンまたはオフによって変わります。TurboPlay のオンまたはオフは、1 番目のフィールドで示されます。

TurboPlay フィールドの値
フィールド 1 フィールド 2 フィールド 3
0 (オフ) TurboPlay がオフの理由
1—ユーザーの初期設定。
2—利用可能な帯域幅が 256 Kbps 未満。
3—SureStream が使用中。
4—過剰な再バッファリング。
5—プレゼンテーションで TurboPlay を使用できない。
6—サーバーで TurboPlay を使用できない。
7—ライブ プレゼンテーションをサポートしていない。		 0 (使用されていない)
1 (オン) TurboPlay で要求された、加速された配信レート。単位はビット/秒 (bps)。 再生やシークなどを開始するまでの平均バッファリング時間 (ミリ秒)。

接続時間

duration フィールドでは、クライアントの初期要求からクライアントが受信した最初のデータ パケットまでの時間 (ミリ秒) を示します。

クリップの終了

clip_end フィールドには、プレゼンテーションが終了した理由がリストされます。有効値は以下のとおりです。

0 プレゼンテーションの終わりに到達。
1 停止コマンドが発行された。
2 再接続が必要。
3 リダイレクト。
PNR_n エラー コード n が発行された。

アクセス ログとエラー ログのカスタマイズ

以下のセクションでは、アクセス レコードやエラー レコードのロギングを変更する方法について説明します。ロギングはデフォルトで有効になっています。しかし、デフォルト オプションを変更することができます。

アクセス ログの変更

アクセス ログは、メディア プレーヤー要求に対する基本的なクライアント統計を収集するように、あらかじめ構成されています。ロギング スタイルやクライアントの統計 type を変更したり、ログ ファイルのローリングを設定したりすることができます。

アクセス ロギングを変更するには、以下の手順に従ってください。

  1. [Logging & Monitoring (ロギングとモニタリング)] > [Access & Error Logging (アクセス ログとエラー ログ)] をクリックします。アクセス ロギングのフィールドが、ページの上部に表示されます。

  2. [Logging Style (ロギング スタイル)]で、0 〜 5 で番号を選択します。デフォルトは 5 です。ロギング スタイルの詳細については、「ロギング スタイル」を参照してください。

  3. クライアント識別子を収集しない場合は、[Disable Client GUIDs (クライアント GUID を無効にする)] プルダウン リストから [Yes (はい)] を選択します。これにより、クライアントの GUID や Cookie ベースの ID の収集を収集しなくなります。詳細については、「クライアント識別子」を参照してください。

  4. [Domain Cookie ID (ドメイン Cookie ID)] プルダウン リストは、デフォルトで [Enabled (有効)] に設定されています。つまり、Helix Universal Server は、各クライアントに Cookie を設定しようとします。この Cookie では、クライアントがコンテンツを要求したときに、隠された GUID の代わりにログに記録されるクライアント ID が提供されます。Cookie の設定を無効にする場合は、[Disabled (無効)] を選択します。詳細については、「クライアント識別子」を参照してください。

    5. ヒント : [Disable Client GUIDs (クライアント GUID を無効にする)] で [Yes (はい)] を選択した場合、Helix Universal Server では Cookie ベースの ID も無効になります。

  5. [Client Stats Interval (クライアント統計の間隔)] 設定で、クライアントが統計をレポートする頻度を秒で指定します。たとえば値が 30 のとき、30 秒ごとに、クライアントが統計を送信し、Helix Universal Server が新しいログ エントリを作成します。この値を 0 (ゼロ) に設定した場合、クライアントが統計を送信するのはプレゼンテーションが終わったあとの 1 回だけです。

  6. [Client Stats (クライアント統計)] で、各メディア プレーヤーがレポートするクライアントの統計 type をオンにします。統計 type は任意に組み合わせることができ、すべてのチェック ボックスをオフにすることで、クライアント統計をまったく収集しないようにできます。デフォルトの設定は Type 1 および Type 2 です。詳細については、「クライアント統計」を参照してください。

    7. ヒント : 統計 type 3 または 4 を収集する場合は、アクセス ログ ファイルのサイズが急速に大きくなります。この場合は、ログ ファイルを頻繁に調査する必要があります。または、ログ ファイルのローリングを使用してください。

  7. 「ログ ファイルのローリング」 で説明したように、一定のインターバルで新しいログ ファイルを作成するように選択できます。

    1. 一定のインターバルで新しいログ ファイルを作成するには、[Log Rolling Frequency (ログのローリング頻度)] プルダウン リストから期間を選択します。時間、日、週、月のいずれかの単位でログをローリングできます。

    2. ログをファイル サイズで制限するには、[Log Rolling Size (ログのローリング サイズ)] ボックスにログ ファイルの最大サイズをメガバイト単位で入力します。

      3. ヒント : 一般に、頻度かサイズのどちらかでログ ファイルを制限します。ただし、両方の方法を選択して、最初に達した制限に基づいてログ ファイルを作成することもできます。たとえば、最初のファイルが 10 MB に達するか、3 日分のアクティビティに達するかのどちらか早い時点で、次のログ ファイルを作成できます。

  8. [Access Log File (アクセス ログ ファイル)] フィールドで、ログ ファイル名と絶対パスを指定します。デフォルトのパスは、Helix Universal Server のメイン ディレクトリにある Logs サブディレクトリです。アクセス ログ ファイルのデフォルトのファイル名は、rmaccess.log です。

    9. 注意 :[Access Log File (アクセス ログ ファイル)] にファイル名が入力されていない場合、Helix Universal Server は rmaccess.log というファイルにアクセス情報を記録します。このファイルは、Helix Universal Server の実行可能ファイルと同じディレクトリに格納されています。

  9. [Apply (適用)] をクリックします。

エラー ログの変更

エラー ログを使用するには、構成は必要ありません。しかし、ログ ファイルのローリングを設定したり、エラー ログの場所と名前を別のものに指定したりすることができます。エラー ログの構文の基本的な情報については、「エラー ログ」を参照してください。

エラー ログを変更するには、以下の手順に従ってください。

  1. [Logging & Monitoring (ロギングとモニタリング)] > [Access & Error Logging (アクセス ログとエラー ログ)] をクリックします。エラー ロギングのフィールドが、ページの下部に表示されます。

  2. 「ログ ファイルのローリング」 で説明したように、一定のインターバルで新しいエラー ログ ファイルを作成するように選択できます。

    1. 一定のインターバルで新しいログ ファイルを作成するには、[Log Rolling Frequency (ログのローリング頻度)] プルダウン リストから期間を選択します。時間、日、週、月のいずれかの単位でログをローリングできます。

    2. ログをファイル サイズで制限するには、[Log Rolling Size (ログのローリング サイズ)] ボックスにログ ファイルの最大サイズをメガバイト単位で入力します。

      3. ヒント : 一般に、頻度かサイズのどちらかでログ ファイルを制限します。ただし、両方の方法を選択して、最初に達した制限に基づいてログ ファイルを作成することもできます。たとえば、最初のファイルが 10 MB に達するか、3 日分のアクティビティに達するかのどちらか早い時点で、次のログ ファイルを作成できます。

  3. [Error Log File (エラー ログ ファイル)] フィールドで、ログ ファイル名と絶対パスを指定します。デフォルトのパスは、Helix Universal Server のメイン ディレクトリにある Logs サブディレクトリです。エラー ログ ファイルのデフォルトのファイル名は、rmerror.log です。

  4. Windows NT システム上では、エラー メッセージを Windows のイベント ビューアに送信できます。[NT Event Log Filter (NT イベント ログ フィルタ)] で、Helix Universal Server エラー メッセージに割り当てる NT エラー レベルを選択します。

  5. [Apply (適用)] をクリックします。

RealNetworks, Inc. © 2002 RealNetworks, Inc. All rights reserved.
詳細については、RealNetworks を参照してください。
画面左側に目次フレームが表示されない場合は、ここをクリックしてください。
戻る 次へ