Oracle Coherence*Webには、事前定義済レポートの追加セットが用意されています。Coherence*Webレポートは、この章では説明しません。『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のパフォーマンス・レポートの実行に関する項を参照してください。
この章の内容は次のとおりです。
<local-scheme>
の<unit-calculator>
サブ要素をBINARY
に設定したキャッシュのサイズが報告されます。このキャッシュ・サイズ・レポートの名前は、timestamp
-cache-size.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-cache-size.txt
という名前のファイルは、2009年1月31日の午前1時のキャッシュ・サイズ・レポートを表します。表6-1は、キャッシュ・サイズ・レポートの内容を示しています。
表6-1 キャッシュ・サイズ・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
キャッシュ・サービスの名前 |
|
|
キャッシュの名前 |
|
|
キャッシュ内のオブジェクトの数 |
|
|
キャッシュ内のオブジェクトによって消費されたバイト数 |
|
|
キャッシュ内のオブジェクトによって消費されたメガバイト(MB)数 |
|
|
各オブジェクトの平均メモリー消費量 |
timestamp
-cache-usage.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2010013113-cache-usage.txt
という名前のファイルは、2010年1月31日の午後1時のキャッシュの使用レポートを表します。表6-2は、キャッシュの使用レポートの内容を示しています。
表6-2 キャッシュの使用レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュ・サービスの名前 |
|
|
キャッシュの名前 |
|
|
キャッシュがフロント層(ローカル・キャッシュ)とバック層(リモート・キャッシュ)のどちらに配置されているのか。値は |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してputが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してgetが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してアクセスした合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でヒットした |
|
|
前回レポートがリフレッシュされてからクラスタ全体でのキャッシュに対するミスの合計数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でミスした |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて記憶域への書込みが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で記憶域への書込み操作にかかった合計時間(ミリ秒) |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュのキャッシュ・ストアから読取りが実行された合計回数 |
|
|
前回レポートが実行されてからクラスタ全体でキャッシュのキャッシュ・ストアの読取りにかかった合計時間(ミリ秒) |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて障害が発生した合計回数 |
|
|
クラスタ全体のキュー・リンク・サイズの合計 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してエビクションが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してプルーニングが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でプルーニング操作にかかった合計時間(ミリ秒) |
timestamp
-federation-destination.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-federation-destination.txt
という名前のファイルは、2009年1月31日の午前1時のレポートを表します。表6-3は、フェデレーション・デスティネーション・レポートの内容を示しています。
表6-3 フェデレーション・デスティネーション・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フェデレーション統計の対象メンバー |
|
|
送信者の名前 |
|
|
参加者の状態。 |
|
|
参加者のステータス。ステータスは次のとおりです。
|
|
|
送信レプリケート・メッセージの1秒当たりの現在使用中の帯域幅(メガビット) |
|
|
送信されたバイトの総数 |
|
|
送信されたキャッシュ・エントリの総数 |
|
|
送信されたジャーナル・レコードの総数。ジャーナル・レコードは、同一のトランザクションの一部である複数のキャッシュ・エントリで構成されます |
|
|
送信されたレプリケーション・メッセージの総数。レプリケーション・メッセージには、複数のジャーナル・レコードが含まれます。 |
|
|
未応答のレプリケーション・メッセージの総数 |
|
|
ジャーナル・レコードがキャッシュ内でレプリケートを待機する時間の90パーセンタイル値(ミリ秒)です |
|
|
レプリケーション・メッセージおよびネットワーク上の関連する応答メッセージの送信にかかった時間の90パーセンタイル値(ミリ秒)です |
|
|
レプリケーション・メッセージをデスティネーションに適用するのに要した時間の90パーセンタイル値(ミリ秒)です |
|
|
1秒当たりの送信バイト数 |
|
|
1秒当たりの送信メッセージ数 |
|
|
送信レプリケート・メッセージの1秒当たりの最大帯域幅(メガビット)。 |
|
|
エラーの説明。送信者の状態が |
|
|
参加者に構成された送信タイムアウト |
|
|
参加者に構成された場所のメタデータ |
timestamp
-federation-origin.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-federation-origin.txt
という名前のファイルは、2009年1月31日の午前1時のレポートを表します。表6-4は、フェデレーション・オリジン・レポートの内容を示しています。
表6-4 フェデレーション・オリジン・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フェデレーション統計の対象メンバー |
|
|
受信されたバイトの総数 |
|
|
受信されたジャーナル・レコードの総数。ジャーナル・レコードは、同一のトランザクションの一部である複数のキャッシュ・エントリで構成されます |
|
|
受信されたキャッシュ・エントリの総数 |
|
|
受信されたレプリケーション・メッセージの総数。レプリケーション・メッセージには、複数のジャーナル・レコードが含まれます |
|
|
未応答のレプリケーション・メッセージの総数 |
|
|
レプリケーション・メッセージをデスティネーションに適用するのに要した時間の90パーセンタイル値(ミリ秒)です。 |
|
|
ジャーナル・レコードがキャッシュ内でレプリケートを待機する時間の90パーセンタイル値(ミリ秒)です |
|
|
1秒当たりの受信バイト数 |
|
|
1秒当たりの受信メッセージ数 |
timestamp
-federation-status.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-federation-status.txt
という名前のファイルは、2009年1月31日の午前1時のフキャッシュ・サイズ・レポートを表します。表6-5は、フェデレーション・ステータス・レポートの内容を示しています。
表6-5 フェデレーション・ステータス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
フェデレーション統計の対象メンバー |
|
|
送信者の名前 |
|
|
参加者の状態。 |
|
|
エラーの説明。送信者の状態が |
timestamp
-flashjournal.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2010013113-flashjournal.txt
という名前のファイルは、2010年1月31日の午後1時のフラッシュ・ジャーナル・レポートを表します。表6-6は、フラッシュ・ジャーナル・レポートの内容を示しています。
表6-6 フラッシュ・ジャーナル・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フラッシュ・ジャーナルの統計の対象メンバー |
|
|
現在使用中のジャーナル・ファイルの数 |
|
|
このジャーナルを使用しているアクティブな |
|
|
このジャーナルに現在保存されているバイト単位のデータ量 |
|
|
このジャーナルのすべてのジャーナル・ファイルの合計サイズ |
|
|
まだジャーナルに格納されていない、シリアライズされた値の数 |
|
|
バックログのバイト単位の最大サイズ。バックログは、まだジャーナルに格納されていない、シリアライズされた値の数です。クライアント・スレッドは、この制限を超えるとブロックされ、バックログが制限を下回るまでブロックされたままになります。 |
|
|
プール内の使用可能なバッファのバイト単位での合計サイズ |
timestamp
-jcache-configuration.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013113-jcache-configuration.txt
という名前のファイルは、2009年1月31日の午後1時の管理レポートを表します。表6-7は、JCache構成レポートの内容を示しています。
表6-7 JCache構成レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュを作成したJCache |
|
|
キャッシュの名前 |
|
|
キャッシュが必要とするキーの型です。 |
|
|
キャッシュが必要とする値の型です。 |
|
|
キャッシュの管理が有効化されているかどうかを示します |
|
|
キャッシュのパフォーマンス統計が収集されているかどうかを示します |
|
|
キャッシュ操作がリードスルー・モードかどうかを示します |
|
|
キャッシュ操作がライトスルー・モードかどうかを示します |
|
|
キャッシュが値による格納または参照による格納のどちらのセマンティクスを使用しているかを示します。 |
timestamp
-jcache-statistics.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013113-jcache-statistics.txt
という名前のファイルは、2009年1月31日の午後1時の管理レポートを表します。表6-8は、JCache統計レポートの内容を示しています。
表6-8 JCache統計レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュを作成したJCache |
|
|
キャッシュの名前 |
|
|
|
|
|
既存のエントリの置換操作を含むput操作の総数です |
|
|
|
|
|
成功した |
|
|
成功しなかった |
|
|
キャッシュからのエビクションの総数です。エビクションは、スペースを開放するため、キャッシュによって開始されます。エビクションは、 注意: この属性は、Coherence JCacheプロバイダでは実装されていません。 |
|
|
|
|
|
|
|
|
|
|
|
エントリを返したキャッシュ・リクエストの割合です。この割合は、キャッシュ・ヒットをキャッシュの |
|
|
エントリを返さなかったキャッシュ・リクエストの割合です。この割合は、キャッシュ・ミスをキャッシュの |
timestamp
-management.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013113-Management.txt
という名前のファイルは、2009年1月31日の午後1時の管理レポートを表します。表6-9は、管理レポートの内容を示しています。
表6-9 管理レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
現在設定されているリフレッシュ・ポリシー。このポリシーは、リモート・モデルのデータのリフレッシュ方法を決定します。 |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
MBeanサーバーによって情報が予測的にリフレッシュされ、その情報がアクセスされなかった回数 |
|
|
統計が最後にリセットされてから取得されたスナップショットの合計数 |
|
|
MBeanサーバーによって予測的なアルゴリズムが使用され、MBean情報がリフレッシュされた回数 |
|
|
この管理メンバーがリモートMBean属性のリフレッシュ試行中にタイムアウトした回数 |
timestamp
-memory-status.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013115-memory-status.txt
という名前のファイルは、2009年1月31日の午後3時のメモリー・ステータス・レポートを表します。表6-10は、メモリー・ステータス・レポートの内容を示しています。
表6-10 メモリー・ステータス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
前回のJVM起動からの経過時間 |
|
|
メモリー統計の対象メンバー |
|
|
ガベージ・コレクタの名前 |
|
|
前回のJVM起動以降のガベージ・コレクションの回数 |
|
|
前回のレポート・リフレッシュ以降のガベージ・コレクションの回数 |
|
|
JVMが起動後にガベージ・コレクションに費やした時間(ミリ秒) |
|
|
前回のレポート・リフレッシュ以降にJVMがガベージ・コレクションに費やした時間(ミリ秒) |
|
|
最後のガベージ・コレクションの開始時間 |
|
|
最後のガベージ・コレクションの合計時間 |
|
|
最後のガベージ・コレクションの停止時間 |
|
|
レポート実行時点におけるコミット済ヒープ・バイト数 |
|
|
レポート実行時点における初期化済ヒープ・バイト数 |
|
|
JVMが起動後に使用した最大バイト数 |
|
|
レポート実行時点でJVMが使用していたバイト数 |
timestamp
-network-health-detail.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013114-network-health-detail.txt
という名前のファイルは、2009年1月31日の午後2時のネットワーク・ヘルス詳細レポートを表します。 表6-11は、ネットワーク・ヘルス詳細レポートの内容を示しています。
表6-11 ネットワーク・ヘルス詳細レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
管理情報が、対応するノードから前回取得されたときのシステム時刻。ローカル・サーバーはローカル時間を表示します。 |
|
|
ネットワーク統計の対象メンバー。 |
|
|
メンバーにおけるパブリッシャの成功率。この値が、ネットワーク・ヘルス・ファイルのバッチ(表6-12を参照)に示される |
|
|
メンバーにおける受信側の成功率。この値が、ネットワーク・ヘルス・ファイルのバッチ(表6-12を参照)に示される |
|
|
メンバーから送信されたネットワーク・パケットの総数 |
|
|
前回のレポート・リフレッシュ以降にメンバーから送信されたパケットの数 |
|
|
メンバーから再送信されたネットワーク・パケットの総数。パケットの受信側が無効なパケットを受信した場合、または適切な時間内に確認パケットが送信されなかった場合、パケットは再送信されます。 |
|
|
前回のレポート・リフレッシュ以降にメンバーから再送信されたパケットの数 |
|
|
複数回受信したパケットの総数 |
|
|
前回のレポート・リフレッシュ以降に複数回受信したパケットの数 |
|
|
メンバーが受信したパケットの総数 |
|
|
前回のレポート・リフレッシュ以降にメンバーが受信したパケットの総数 |
timestamp
-network-health.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013113-network-health.txt
という名前のファイルは、2009年1月31日の午後1時のネットワーク・ヘルス・レポートを表します。表6-12は、ネットワーク・ヘルス・レポートの内容を示しています。
表6-12 ネットワーク・ヘルス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
クラスタ内のメンバーにおける受信側の最小成功率。この値が、 |
|
|
グリッド全体における受信側の成功率。この値が90%よりも低い場合、ネットワーク・ヘルス詳細レポートを分析してください。 |
|
|
クラスタ内のメンバーにおけるパブリッシャの最小成功率。この値が、 |
|
|
グリッド全体におけるパブリッシャの成功率。この値が90%よりも低い場合、ネットワーク・ヘルス詳細レポートを分析してください。 |
nodeId
)は一時的であるという性質をもつため、レポータは、メンバーのリストとユーザー定義のメンバーの識別情報をログに出力します。『Oracle Coherenceでのアプリケーションの開発』のmember-identityに関する項を参照してください。このノード・リスト・レポートの名前はtimestamp
-nodes.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-nodes.txt
という名前のファイルは、2009年1月31日の午前1時のノード・リスト・レポートを表します。表6-13は、ノード・リスト・レポートの内容を示しています。
表6-13 ノード・リスト・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
情報がリモート・メンバーからリフレッシュされた時間。この時刻がバッチに出力された他の行のリフレッシュ時刻と異なる場合、このメンバーは適時に応答しなかったことになります。この現象は一般に、ガベージ・コレクションを実行しているメンバーで発生します。リフレッシュ日付が古いメンバーに関する情報は信頼できません。 |
|
|
数値のメンバー識別子 |
|
|
メンバーのユニキャスト・アドレス |
|
|
メンバー名 |
|
|
メンバーのプロセス名 |
|
|
メンバーのロール名 |
|
|
メンバーのコンピュータ名 |
|
|
メンバーのラック名 |
|
|
メンバーのサイト名 |
timestamp
-persistence-detail.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-persistence-detail.txt
という名前のファイルは、2009年1月31日の午前1時の永続性詳細レポートを表します。表6-14は、永続性詳細レポートの内容を示しています。
表6-14 永続性詳細レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
パーティション化キャッシュ・サービスの名前 |
|
|
このサービスで使用される現在の永続性モードは、次のとおりです。
|
|
|
永続性統計の対象メンバー |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加された平均待機時間(ミリ秒) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加された最大待機時間(ミリ秒)。 |
|
|
アクティブな永続性で使用される領域の量(バイト) |
|
|
アクティブな永続性で使用するファイル・システムの合計サイズ(バイト) |
|
|
アクティブな永続性のファイル・システムで使用可能な残りの領域(バイト) |
|
|
スナップショットを格納するファイル・システムの合計サイズ(バイト) |
|
|
スナップショットを格納するためにファイル・システムで使用可能な残りの領域(バイト) |
timestamp
-persistence.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-persistence.txt
という名前のファイルは、2009年1月31日の午前1時の永続性レポートを表します。表6-15は、永続性レポートの内容を示しています。
表6-15 永続性レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
パーティション化キャッシュ・サービスの名前 |
|
|
このサービスで使用される現在の永続性モードは、次のとおりです。
|
|
|
アクティブな永続性で使用される領域の量(バイト) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加されたすべてのノードの平均待機時間(ミリ秒) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加されたすべてのノードの最大待機時間(ミリ秒)。 |
timestamp
-network-report-proxy.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-report-proxy.txt
という名前のファイルは、2009年1月31日の午前1時のプロキシ・レポートを表します。表6-16は、プロキシ・レポートの内容を示しています。
表6-16 プロキシ・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
プロキシ・サービスの名前 |
|
|
プロキシ・サービスのIPアドレスおよびポート |
|
|
数値のメンバー識別子 |
|
|
プロキシ・サービスの現在の接続数 |
|
|
プロキシ・サービスによる送信のキューに入れられたバイト数 |
|
|
プロキシ・サービスによるキューに入れられたメッセージ数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスから送信されたバイト数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスが受信したバイト数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスから送信されたメッセージ数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスが受信したメッセージ数 |
timestamp
-report-proxy-http.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2009013101-report-proxy-http.txt
という名前のファイルは、2009年1月31日の午前1時のプロキシ・レポートを表します。表6-17は、プロキシHTTPレポートの内容を示しています。
表6-17 プロキシHTTPレポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
プロキシ・サービスの名前 |
|
|
HTTPサーバーのタイプ、またはHTTPプロトコルを使用していな場合は |
|
|
プロキシ・サービスのIPアドレスおよびポート |
|
|
数値のメンバー識別子 |
|
|
HTTPリクエストの平均サイズ |
|
|
HTTPレスポンスの平均サイズ |
|
|
HTTPリクエストの平均処理時間(ミリ秒単位) |
|
|
エラーが発生したHTTPリクエストの数 |
|
|
HTTPサーバーが起動されてから、または統計が最後にリセットされてからのリクエストの数 |
|
|
100から199の範囲のHTTPレスポンスの数 |
|
|
200から299の範囲のHTTPレスポンスの数 |
|
|
300から399の範囲のHTTPレスポンスの数 |
|
|
400から499の範囲のHTTPレスポンスの数 |
|
|
500から599の範囲のHTTPレスポンスの数 |
timestamp
-ramjournal.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2010013113-ramjournal.txt
という名前のファイルは、2010年1月31日の午後1時のジャーナル・レポートを表します。表6-18は、ジャーナル・レポートの内容を示しています。
表6-18 RAMジャーナル・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
RAMジャーナルの統計の対象メンバー |
|
|
現在使用中のジャーナル・ファイルの数 |
|
|
このジャーナルを使用しているアクティブな |
|
|
このジャーナルに現在保存されているバイト単位のデータ量 |
|
|
このジャーナルのすべてのジャーナル・ファイルの合計サイズ |
Request Count
およびTask Count
の各値は、サービスのパフォーマンスとスループットを確認する場合に使用します。RequestPendingCount
およびTask Backlog
の各値は、容量の問題やブロックされたプロセスの特定に使用します。Task Hung Count
、Task Timeout Count
、Thread Abandoned Count
、およびRequest Timeout Count
の各値は、システムで発生した実行の失敗数を示します。このサービス・レポートの名前はtimestamp
-service.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、2010013113-service.txt
という名前のファイルは、2010年1月31日の午後1時のサービス・レポートを表します。表6-19は、サービス・レポートの内容を示しています。
表6-19 サービス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
サービス名 |
|
|
数値のメンバー識別子 |
|
|
サービス情報がリモート・メンバーから更新されたシステム時間 |
|
|
前回のレポート・リフレッシュ以降のリクエスト数 |
|
|
レポート実行時点における未処理のリクエスト数 |
|
|
レポート実行時点における未処理リクエストの待機時間 |
|
|
前回のレポート・リフレッシュ以降のリクエストのタイムアウト回数 |
|
|
前回のレポート・リフレッシュ以降に実行されたタスクの数 |
|
|
レポート実行時点におけるタスクのバックログ |
|
|
前回のレポート・リフレッシュ以降のタスクのタイムアウト回数 |
|
|
前回のレポート・リフレッシュ以降にハングしたタスクの数 |
|
|
前回のレポート・リフレッシュ以降に破棄されたスレッドの数 |