ヘッダーをスキップ

Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース3 (12.1.0.4) for Linux x86-64 E49732-01 |
| 目次 | 索引

前 | 次 |

# 15 システムの監視およびメンテナンス

この章では、管理者が実行するタスクについて説明します。これには、システムのステータスの監視、バックアップおよびアップグレードの実行、イベント・ログの処理、システム・ユーザーの管理、データ保存ポリシーの構成が含まれます。

## 15.1 システムのステータスの監視

管理者は、システムの状態を確認し、ステータス・ページで自動ステータス監視メッセージを受信できます。このページにアクセスするには、「システム」→「ステータス」を選択します。例を図15-1に示します。

図15-1 「ステータス」ウィンドウ

「図15-1 「ステータス」ウィンドウ」の説明

ステータス・ページでは、接続されているコレクタのステータス、ログ・ファイル処理、システムにおける現在の処理レベル、レポータおよび処理エンジンのデータベース表領域に十分な領域があるかどうか、およびイベント・ログを確認できます。また、システム・ステータス・エラーが発生した場合に通知を受け取るユーザー(およびその方法)も構成できます。

コンポーネントの失敗の概要

図15-1に示す各コンポーネントは、現在のステータスを示しています。通常の運用では、これは「OK」とレポートされます。ただし、1つ以上のコンポーネントで「Error」とレポートされる場合は、表15-1の情報を使用して、問題の特定と解決を行ってください。

表15-1 レポートされたエラーの原因

コンポーネント | 考えられる原因
--- | ---
コレクタ・ステータス | レポータにコレクタが登録されていない。 (1つまたは複数の)コレクタに接続の問題がある(ネットワークまたはSSH認証に関する問題など)。 (1つまたは複数の)コレクタが動作していない。 (1つまたは複数の)コレクタが頻繁にクラッシュする。 直近のログ・ファイル生成から10分を超える時間が経過している。
ログ・ファイル処理 | 直近のログ・ファイル処理から10分を超える時間が経過している。
データ処理 | データ処理が遅延している(つまり、直近のログ・ファイル更新から15分を超える時間が経過している)。
イベント・ログ | (1つまたは複数の)未読のエラー・イベントがイベント・ログに報告されている。
使用可能なデータベース領域 | データベース領域の使用率が警告制限を超えている場合の警告ステータス。 データベース領域の使用率がエラー制限を超えている場合のエラー・ステータス。 (15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。
ディスク領域 | ディスク領域の使用率が警告制限を超えている場合の警告ステータス。 ディスク領域の使用率がエラー制限を超えている場合のエラー・ステータス。 (15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。

### 15.1.1 一時遅延およびアラート

図15-1に示したシステム・ステータス・インジケータが更新されるのは、ブラウザ画面のリフレッシュ時のみです。1つ以上のシステム・プロセスで障害が発生していることが検出されたときにシステム・アラートを生成するように設定できます(15.3項「システム障害アラートの構成」を参照)。このため、1つのプロセスに一時的に障害が発生していることが(赤いxによって)示されるが、アラートは生成されないという状況が生じる場合があります。これは、システム・プロセスがチェックされる時点までにシステム・ステータス・インジケータが正常状態に戻っていたことが原因です。

このような設計のため、アラートがトリガーされた場合は、システム障害が発生し始めているという警告とみなすことをお薦めします。障害は、デフォルトの境界よりもシステム遅延の方が長くなった結果、発生する場合があります。たとえば、監視対象の行がヒットした時点と、このヒットに基づく情報がレポータで使用可能になる時点との間の待機時間がそれほど長くない場合です。この待機時間が、トラフィックが多い環境における境界を超えている可能性があります。また、障害は、トラフィックが一時的にピークを示した結果である場合もあります。ただし、この状況が続く場合は、監視対象のトラフィック・レベルを確認することをお薦めします。

## 15.2 コレクタのステータスの表示

システムに接続された各コレクタのステータスを表示するには、「システム」→「ステータス」→コレクタ・ステータスを選択します。これにより、「ネットワーク・データ・コレクタ・ステータス」ウィンドウが開きます。例を図15-2に示します。

図15-2 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ

「図15-2 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ」の説明

「システム(ローカル・ホスト)」項目はレポート・システム上のコレクタ・インスタンスを示すことに注意してください。ネットワーク内の他のコレクタは、IPアドレスで表します。目的のコレクタをクリックするか、またはコンテキスト・メニューから「統計の表示」を選択して、コレクタの監視対象トラフィックの詳細なレポートを表示します。例を図15-3に示します。

図15-3 「コレクタ統計」ウィンドウ

「図15-3 「コレクタ統計」ウィンドウ」の説明

このウィンドウに表示される情報は、選択したコレクタについて午前0時以降またはカウンタのリセット以降に監視されたトラフィックを示します。ウィンドウの左下にある稼働時間フィールドは、コレクタが稼働している時間を示します。コレクタが構成を更新するために再起動されると、この稼働時間はリセットされます。ウィンドウに表示されているすべてのHTTPリクエスト・カウンタをリセットするには、「ビュー」メニューで「カウンタのリセット」を選択します。このカウンタが自動的にリセットされるのは、ネットワーク・パケットが次回検出されたときです。このため、ネットワーク・トラフィックが行われていないインストール環境の場合、カウンタはリセットされません。この表示は2秒ごとに自動的にリフレッシュされます。

「コレクタ統計」ウィンドウの使用

ウィンドウの左上部分にあるタブにより、選択したコレクタによって監視されたトラフィックの詳細なブレークダウンを確認できます。これについて表15-2で説明します。

表15-2 「コレクタ統計」レポートのタブ

タブ | 説明
--- | ---
インタフェース | データ収集に使用可能なネットワーク・インタフェースについての情報を提供します。インタフェースの数とステータスはシステム構成によって異なります。標準的に構成されるインタフェースは表示されません。使用可能なインタフェースごとに、名前(`eth` `x`形式)、使用状況(現在の帯域幅)および状態が表示されます。状態には、「OK」、「停止」、「未構成」、「非アクティブ」または「無差別ではない」(ネットワーク・アダプタが確認できるのはそのMACアドレスに送信されたトラフィックのみ)があります。
イーサネット | 監視対象のポートを介して送信されるRAWパケット・データのブレークダウンを、そのプロトコル(IPv4やARPなど)および測定されたフレーム数として表示します。「切捨て」リストは、フレームが破損しているか削除されていることを示します。
TCP | TCPストリームの分析結果を示します。レポートされるカウンタは、次のとおりです。 処理中: 現在アクティブなTCPセッションの数。これには、現在データが転送されているセッション、まだ接続の確立段階のセッション、または切断手順が開始されているがまだ完了していないセッションがあります。このカウンタはネットワークの負荷を直接反映しています。 最大同時: コレクタが起動されてから「処理中」カウンタが到達した最大数。 接続リセット: TCP RESETセグメントによって終了されたセッションの数。このようなセッションは通信の両側によって即座に削除されます。これらのセッションでは、これ以上のデータは送信できません(切断手順の場合も含む)。 接続が拒否されました: リクエストしたサービスが存在していなかったために確立できなかったセッションの数。この状況が発生するのは、ピアが接続を確立しようとするシステム上のポートがリスニングされていない場合です。 合計: コレクタが起動してから実行されたセッションの合計数。 次のネットワーク・エラー・メーターも表示されます。 順序が間違っています: 順序が乱れて受信されたセグメント数を示します。このようなエラーのセグメント数が非常に多数ある場合、ピア間のネットワークの性能に問題が潜んでいることを示します。このネットワークは通常、クライアントPCとサーバー間のインターネットです。 無効なチェックサム: 破損の途中であるセグメントの数を示します。このような問題のセグメントの数が多い場合、ハードウェア、配線またはネットワークに問題が潜んでいることを示します。 無効なオフセットおよび/または長さ: 通知されている長さと比べると長さが正しくないパケットの数を示します。これで、破損したパケットが示されます。 削除されたセグメント: チェックサムや長さが正しくないなどの予期しない理由のために削除されたセグメントの合計数を示します。この値が常に高くなった場合は、ハードウェアおよびネットワークのアーキテクチャをチェックしてください。 複雑な構成においては、この値は、必要なトラフィックがコレクタのTAPデバイスに対して正確にルーティングされていないことを示す場合があることに注意してください。たとえば、2つのネットワーク・トランク(インバウンド・トラフィックおよびアウトバウンド・トラフィック用)を使用できますが、コレクタが認識できるのは1つだけです。この場合、TAPデバイスが両方のトランクに正しく接続されていることを確認する必要があります。また、VLANトランクが使用される構成(たとえば、インバウンド・トラフィックとアウトバウンド・トラフィックを分けるため)では、VLANトラフィックと非VLANトラフィックを混在させることはできません。 これらいずれかのメーターで問題が示されるときは、TCP診断機能を使用して可能性のある原因を特定することをお薦めします。
TCP診断 | この機能の使用方法の詳細は、付録R「監視対象ネットワーク・トラフィックの確認」に記載されています。
HTTP | 監視したHTTPストリームの分析結果を示します。特に、ストリームに含まれるリクエストのタイプ(GETやPOSTなど)を示します。
SSL接続 | 暗号化されたデータのパケットに使用されている暗号化メソッドをレポートします。具体的には、次のとおりです。 SSLv2: SSLバージョン2の接続数(これらの接続の追跡はコレクタではサポートされません)。 SSLv23: 混在モードのSSL接続の数(SSLバージョン2として開始されたが、接続の確立フェーズでこれより高いバージョン3に切り替えられたセッション)。コレクタはこれらの接続を追跡できないことに注意してください。 SSLv3: SSLバージョン3の接続数。 TLSv1: TLSバージョン1の接続数。 その他: その他の接続(前述のいずれのカテゴリにも当てはまらない接続)の数。 SSL鍵管理に関するエラーがレポートされます。具体的には、次のとおりです。 サーバー鍵がありません: リクエストしたサーバー接続用の秘密SSL鍵で、コレクタが使用できるものがありません。 マスター鍵がありません: 接続のマスター鍵が計算できなかったために削除された接続の数。 セッション鍵がありません。: 接続のセッション鍵がないために削除された接続の数。 (現時点で)サポートされていない暗号化メソッドは、次のとおりです。 純正のSSLv2: クライアントは純正のSSLバージョン2プロトコルを使用しています。これはコレクタではサポートされていません。 エフェメラル: セッションは一時的な鍵を使用して暗号化を行います。このような鍵はコレクタが認識できないため、このようなセッションは追跡できません。 匿名DH: セッションは匿名のDiffie-Hellman鍵交換アルゴリズムに依存します。このような鍵はコレクタが認識できないため、このようなセッションは追跡できません。 復号化エラー・ゲージは、復号化できなかった接続の数を示します。これには、マスター鍵を復号化できなかった、セッション鍵の計算が間違っていた、またはセグメントを復号化できなかったなどの複数の理由があります。
SSL暗号化 | 監視対象の暗号化データのブレークダウンを、採用された暗号化アルゴリズムの観点から示します。「使用中」列は、暗号化アルゴリズムを使用した監視対象のSSL暗号化トラフィック(割合)を示します。「エラー」列は、失敗した(読み取ることができなかった)測定対象のSSL暗号の割合を示します。
パフォーマンス | コレクタに対する影響をレポートします。ピークの負荷が100%に近づいた場合は、データがコレクタによって削除されないようにするためのアクションを即座に実行する必要があります。トラフィックのサンプリングは、13.4.3項「全体のトラフィックの制限」を参照してください。これでも問題が解決されない場合は、Oracleサポート・サービスに連絡することも必要になってきます。コレクタのメモリー使用率も示されます。最大メモリーしきい値は、レポータとコレクタが両方ともあるシステムの場合は30%、コレクタのみのシステムの場合は70%です。

SSLトラフィックおよびFormsトラフィックの監視

SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。

したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。また、「コレクタ統計」ウィンドウに表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。

## 15.3 システム障害アラートの構成

KPIおよびSLAの違反に関する通知を受信できるのみでなく、システム障害のアラートを構成することもできます。そのようにすることを強くお薦めします。システム・アラートを使用すると、システムの問題(コレクタの障害など)に際してすぐにアクションを実行できるだけでなく、外部の深刻な問題(DoS攻撃など)を示すためにも役立ちます。それには、「システム」→「ステータス」→「ステータス通知」の順に選択します。表示されるダイアログは、7.5.1項「アラート・プロファイル」に示したダイアログに似ています。

基本的に、図15-1に示すインジケータ(1つまたは複数)が警告またはエラーのステータスをレポートするイベントによって、システム・アラートがトリガーされます。たとえば、コレクタ・ステータスのアラートは、コレクタが使用できないかコレクタの障害が発生していることを示します。

重要:

特に次の点に注意することをお薦めします。

- 構成された受信者には、データベース領域およびディスク領域の使用率の警告とエラーも通知されます(15.4項「データベースおよびディスクの領域制限とアラートの構成」を参照)。

- システム・ステータスのアラートでは、アラートのスケジュールやエスカレーション・レベルは考慮されません。アラートを構成するときは、受信者のすべての情報(電子メール・アドレスや電話番号など)を正しく指定してください。また、システム・ステータスのチェックが10分ごとに実行されることにも注意してください。このため、図15-1のページにシステム障害が表示された場合、その障害に関するアラートをすぐには受信せず、スケジュールされたシステム・チェックが実行されたときに受信することがあります。

- イベント・ログのアラートの場合、15.7項「イベント・ログの使用」で説明するように、レポートされたイベントを確認することをお薦めします。イベント・ログ・インジケータのステータスを「OK」に戻すためには、イベント・ログの警告またはエラーを読取り済としてマーキングする必要があることに注意してください。

- コレクタ・ステータスのアラートの場合、「コレクタ統計」ウィンドウ(15.2項「コレクタのステータスの表示」を参照)を使用して問題をトラブルシューティングすることをお薦めします。

- 他のエラーまたは警告の際(あるいはエラーや警告が長く続く場合)は、カスタマ・サポートに連絡してください。

SNMPトラップ通知

KPIおよびSLAの違反のように、SNMPトラップを使用してシステム・イベント通知を送信するように構成できます。この場合、イベント・ログでレポートされる各イベント(15.7項「イベント・ログの使用」を参照)は、独立したSNMPトラップになります。

システム・イベントに対してSNMPトラップを構成する手順は、次のとおりです。

1. 「システム」→「ステータス」→「ステータス通知」の順に選択します。図7-9に示すようなダイアログが表示されます。

2. SNMPタブをクリックします。図15-4に示すダイアログが表示されます。

   図15-4 「システム・ステータス監視」ダイアログ

   「図15-4 「システム・ステータス監視」ダイアログ」の説明

3. 「有効」および「イベント・ログ監視」チェック・ボックスが選択されていることを確認してください。そうしないと、システム・イベントに対してSNMPトラップは生成されないことに注意してください。

4. 「イベント・ログ送信制限」フィールドを使用して、1分間に送信されるSNMPトラップの最大数を指定します。この機能は、受信側のSNMPマネージャに大量のトラップが過度に送信されるのを防ぐのに役立ちます。たとえば、1分間に500件のイベントがレポートされる場合について考えます。原則として、これらはそれぞれ独立したSNMPトラップになります。ただし、送信制限が100に設定されている場合は、最も深刻な100件のイベントのみがSNMPトラップとして生成されます。

5. ダイアログにある別のフィールドの使用方法は、7.5.6項「SNMP通知の使用方法」を参照してください。

6. 管理情報ベース(MIB)定義をダウンロードし、管理対象オブジェクトのアドレス帳に取り込みます。この定義には、受信したSNMPメッセージの解釈方法に関して必要な情報が含まれています。MIBファイル(`oracle-ruei.mib`)は、`RUEI/extra`ディレクトリのRUEIインストールzipファイル内でも使用できます。

## 15.4 データベースおよびディスクの領域制限とアラートの構成

システムが中断しないで運用されるようにするために、使用可能なデータベース領域およびディスク領域の使用率に上限を設定します。データベースの使用率が上限に達すると、管理メカニズムによってデータベースのサイズが許容された境界内に戻るまで、新しいデータが書き込まれなくなります。同様に、ディスク領域使用量が最大レベルに達すると、コレクタが停止し、管理者が既存ファイルの削除処理を行うまで、(ログ形式の)データはファイル・システムに書き込まれません。この結果、進行中のセッションの情報が失われ、フル・セッション・リプレイ(FSR)・データも同様です。さらに、これらのいずれかの問題が発生しそうな場合にアラートを生成するように設定することも可能です。

重要: RUEIを熟知していて、これらの設定の用途と効果を明確に理解している場合にのみ、デフォルト設定を変更することを強くお薦めします。

データベース領域またはディスク領域のしきい値を定義する手順は、次のとおりです。

1. 「構成」→「一般」→「詳細設定」→「データベース/ディスク領域の使用率」の順に選択します。図15-5に示すしきい値選択パネルが表示されます。

   図15-5 データベース領域とディスク領域のしきい値

   「図15-5 データベース領域とディスク領域のしきい値」の説明

2. 目的のしきい値を選択します。図15-6に示すようなダイアログが表示されます。

   図15-6 データ保存の変更

   「図15-6 データ保存の変更」の説明

3. アラートのしきい値の場合には、このダイアログを使用してデータベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらアラートが生成されるようにします。生成されたアラートは同じ受信者に送信され、システム障害アラートに定義した通知メカニズム(15.3項「システム障害アラートの構成」を参照)と同じ通知メカニズムが使用されます。停止のしきい値の場合には、データベース領域またはディスク領域の最大使用率を指定し、その使用率を超えたらデータベース処理またはデータ収集が停止するようにします。次に、「保存」をクリックします。指定した変更は、即座に有効になります。

しきい値の定義

しきい値を定義するときには、次の点に注意してください。

- データベース領域またはディスク領域の使用を停止するために指定可能な最大設定は、95%です。これは、使用可能なディスク領域が完全に(100%)いっぱいになった場合、システム上の他のコンポーネントが動作しなくなることがあるためです。また、システムへのリモート・ログオンができなくなる可能性もあります。同様に、データベースが完全にいっぱいになることを許可した場合には、そのサイズを削減するための管理メカニズムが動作できなくなります。

- 指定したしきい値は、RUEIで使用されるすべてのパーティションに適用されます。つまり、`/var/opt/ruei`、およびその下にマウントされたすべてのパーティションです。少なくとも1つのパーティションが指定されたしきい値に達すると、アラート・メカニズムおよび停止メカニズムがトリガーされます。

- 定義されたしきい値のチェックは、絶えず実行されるのではなく、10分ごとに実行されます。したがって、チェックが実行されてアラートが発行されるまでに、データベース領域またはディスク領域の使用率が指定されたしきい値をすでに上回っている場合もあります。そのため、しきい値は、意図したターゲットより少し低く設定することをお薦めします。たとえば、ディスク領域の停止しきい値は95%でなく93%か94%に設定します。

- アラート通知しきい値は、関連する停止しきい値より高い値に設定することはできません。たとえば、データベースの停止しきい値が95%の場合には、アラートしきい値をそれより高い値に設定することはできません。

- デフォルトでは、アラートしきい値は85%、停止しきい値は95%です。

- Linuxオペレーティング・システムでも、ディスク領域使用率の制限は95%です。この制限に達すると、ディスクに書き込めるのは`root`ユーザーのみとなります。RUEIにはこの権限がないため、ディスク領域をそれ以上使用できなくなります。

## 15.5 トラフィック・サマリーの表示

監視対象のネットワーク・トラフィックの概要を開くには、「システム」→「ステータス」→「データ処理」の順に選択します。これにより、ヒット、ページ、セッション処理および各処理ユニットのシステム・ロードに関する情報が即座に表示されます。例を図15-7に示します。

図15-7「データ処理」ダイアログ

「図15-7 「データ処理」ダイアログ」の説明

「パフォーマンス」タブの「使用可能なリソース使用率(%)」項目は、現在の処理レベルを示します。この値が100%に近づくと、データの処理に遅延が発生し始め、データをリアルタイムで処理できなくなります。

この機能はアプリケーション・ロジックに基づいているため、表示されるレポートには非アプリケーション(スイート、サービス、SSOなど)のトラフィックは示されません。

重要: RUEIが監視しているトラフィックに関して正確にレポートするには、このトラフィック・サマリーを定期的に確認することを強くお薦めします。必要であれば、RUEIの構成を確認して適切なものにしてください。たとえば、他のCookieテクノロジを追加します。また、システムでセッションを追跡できない場合は、ユーザー・フローも適切に追跡できません(ユーザー・フロー・レポートではセッションの追跡が必要になるため)。

## 15.6 構成バックアップの作成とリストア

システムの現在の構成のバックアップを作成したり、必要に応じてそのバックアップをリストアできます。バックアップは定期的に作成することをお薦めします。バックアップにはシステム設定のみが含まれることに注意してください。セキュリティ上の理由により、SSL鍵と収集されたデータは含まれません。

バックアップを作成またはリストアする手順は、次のとおりです。

1. 「システム」→「メンテナンス」→「バックアップおよびリストア」の順に選択します。図15-8に示すダイアログが表示されます。

   図15-8 「バックアップおよびリストア」ダイアログ

   「図15-8 「バックアップおよびリストア」ダイアログ」の説明

2. ラジオ・ボタンを使用して、必要な操作を選択します。次に、「次へ」をクリックします。

3. 図15-8の「ファイルからのシステムのリストア」オプションを選択した場合、図15-9に示すダイアログが表示されます。

   図15-9 「システム・リストア」ダイアログ

   「図15-9 「システム・リストア」ダイアログ」の説明

   「参照」をクリックして、必要なバックアップ・ファイルを検索および選択します。

   デフォルトでは、コレクタと処理エンジンに関する管理情報はリストアされません。「コレクタ」と「処理エンジン」のチェック・ボックスを使用すれば、この情報がリストアされるように指定することができます。バックアップを作成した時点でシステムに構成されており、その後で削除されたコレクタと処理エンジンが、リストア後のシステムには追加されることに注意してください。同じように、現在システムで構成されており、バックアップ作成時には構成されていなかったコレクタと処理エンジンは無効化されます。次に、「次へ」をクリックします。

4. 図15-8の「ファイルへのシステムのバックアップ」オプションを選択した場合、ブラウザの構成方法によって、zipファイルの保存場所の指定を求めるメッセージが表示されるか、定義済のデフォルトの場所にファイルがすぐに保存されます。

重要:

- 生成されるバックアップ・ファイルには、Oracleサポート・サービス専用の大量の情報が含まれます。このファイルの内容を変更しないでください。リストアを実行するときは、現在のすべての設定がリストアされる設定で上書きされることに注意してください。

- バックアップからリストアを実行した後、すべての必要なSSL鍵をすぐにアップロードする必要があります。これは、すべての既存のSSL鍵が削除され、バックアップ・ファイルに含まれないためです。

## 15.7 イベント・ログの使用

RUEIでは、15.1項「システムのステータスの監視」で説明されているステータス情報の他に、イベント・ログが保持されます。これには、すべてのシステム・イベントのレコードが含まれます。ユーザーもカスタマ・サポートも、イベント・ログを使用することで、RUEIインストールで発生する可能性のある問題をすぐに特定して解決できます。

イベント・ログの内容を定期的に確認することをお薦めします。イベント・ログに未読のエラー・メッセージが含まれる場合、「ステータス」パネルの「イベント・ログ」項目にエラー・アイコンが表示されます。ほとんどのイベントはすぐにレポートされますが、コレクタ関連のイベントはレポートされるまで最大で5分かかることに注意してください。

イベント・ログを確認する手順は、次のとおりです。

1. 「システム」→「ステータス」→「イベント・ログ」の順に選択します。図15-10に示すようなダイアログに最近のイベントが表示されます。

   図15-10 イベント・ログ

   「図15-10 イベント・ログ」の説明

2. ツールバーのコントロールを使用して、イベントのリストをスクロールします。表示される各ログ・ページには、レポートされるイベントが最大100件まで含まれます。デフォルトでは、すべてのイベント・タイプが表示されます。ただし、「重大度」メニューを使用すると、選択したカテゴリのみに制限してリストを表示できます。イベントの潜在的な影響は、表15-3で説明している重大度によって示されます。

   図15-3 イベントの重大度

   重大度 | 説明
   --- | ---
   情報 | ユーザーが開始したアクションを示します。たとえば、コレクタの再起動、新規ユーザー・アカウントの作成、構成のバックアップまたはリストアがあります。
   警告 | RUEIインストールの障害を引き起こす可能性があるイベントを示します。たとえば、レポータ・システムのディスク領域が不足しかけている、またはログ・ファイルの処理でバックログが増えている場合です。
   エラー | RUEIインストールが完全には作動しなくなるイベントを示します。たとえば、リモート・コレクタが使用できなくなる場合です。

   また、「ステータス」メニューを使用すると、レポートされるすべてのイベントを表示したり、新しい(未読)イベントのみに表示リストを制限したりできます。

   注意: 5分間の期間内に同じイベントが複数回発生した場合は、レポートされるイベント内にリピート・カウンタが表示されます。

3. 必要に応じて、「イベント」メニューで、表15-4に示すオプションを選択できます。

   表15-4 「イベント」メニュー・オプション

   オプション | 説明
   --- | ---
   すべてのイベントを既読としてマーク | 表示されたイベント・リストを、ログを開いてから発生したイベント情報を使用して更新します。ツールバーの「リロード」アイコンをクリックしても同じ操作を実行できます。
   リロード | 表示されたイベント・リストを、ログを開いてから発生したイベント情報を使用して更新します。ツールバーの「リロード」アイコンをクリックしても同じ操作を実行できます。
   閉じる | イベント・ログを閉じます。

4. 表示されているイベントをクリックすると、その詳細を表示できます。図15-11に示すようなダイアログが表示されます。

   図15-11 イベント・ログ・エントリの例

   「図15-11 イベント・ログ・エントリの例」の説明

   このダイアログでは、完全なイベント・テキストと関連するイベント・コードが表示されます。カスタマ・サポートに問い合せるときには、これら両方を指定する必要があることに注意してください。リモート・コレクタの場合、レポートされるソースはコレクタのIPアドレスです。

## 15.8 テキスト・メッセージ・プロバイダの構成

RUEIでは、テキスト・メッセージ通知の使用がサポートされています。この機能を使用するには、使用するすべてのテキスト・メッセージ・プロバイダを構成してシステムに認識させる必要があります。プロバイダ情報を管理するには、「システム」→「メンテナンス」→「テキスト・メッセージ・プロバイダ」の順に選択します。図15-12に示すダイアログが表示されます。

図15-12 「テキスト・メッセージ・アカウント」ダイアログ

「図15-12 「テキスト・メッセージ・アカウント」ダイアログ」の説明

テキスト・メッセージ・プロバイダを構成する手順は、次のとおりです。

1. 「新規アカウントの追加」をクリックして、新規テキスト・メッセージ・プロバイダを定義します。図15-13に示すダイアログが表示されます。

   図15-13 「テキスト・メッセージ・プロバイダの選択」ダイアログ

   「図15-13 「テキスト・メッセージ・プロバイダの選択」ダイアログ」の説明

2. リストから目的のテキスト・メッセージ・プロバイダを選択します。リストには、サポートされている事前定義済のサービスが多数用意されています。これらの各サービスを使用するには、該当するプロバイダのアカウントが必要です。次に、「次へ」をクリックします。図15-14に示すようなダイアログが表示されます。

   重要: 「ローカルGSMモデム」を指定する場合は、システムにGSMモデムを装着しておく必要があります。装着が必要なローカル・モデムは、USBまたはシリアルGSM ETSI 07.05準拠のモデムです。

   図15-14 「アカウント詳細」ダイアログ

   「図15-14 「アカウント詳細」ダイアログ」の説明

3. ダイアログに表示される正確なフィールドは、図15-13で選択したプロバイダによって異なります。たとえば、「ローカルGSMモデム」を選択した場合は、ローカル・ポートとモデムのボー・レートを指定する必要があります。不明な場合は、自動検出を使用できます。オプションで、SIM PINも指定できます(必要な場合)。

4. 事前定義済のMollieまたはClickatellサービスを選択した場合は、アカウントのユーザー名、パスワード、作成者、API IDおよびプロトコル送信メソッドを指定する必要があります。これらの情報は、アカウント・プロバイダによって提供されます。次に、「保存」をクリックします。図15-12に示すダイアログ・ボックスに戻ります。

5. リストでプロバイダを右クリックし、「上に移動」および「下に移動」オプションを使用してリスト内のプロバイダの位置を制御します。プロバイダは、リストでの順序どおりに試行されます。つまり、最初のアカウントが試行され、それが失敗すると2番目のアカウントが試行されます(それ以降についても同様)。

6. 次に、「閉じる」をクリックしてダイアログを閉じます。

Unicodeサポート

テキスト・メッセージではUnicodeがサポートされていますが、多数の制限事項があることを認識しておく必要があります。ローカルに装着したモデムの場合では、7ビットGSM 3.38アルファベットを使用してメッセージが送信されます。サポートされていない文字が元のメッセージに含まれる場合は、疑問符(?)文字に置換されます。外部サービス・プロバイダの場合は、マルチバイト・キャラクタ・セットのサポートに関してサービス・プロバイダに問い合せることをお薦めします。ローカルに装着したモデムと外部サービス・プロバイダの両方で、テキスト・メッセージは160文字に制限されます。

## 15.9 ヘルプデスク・レポートの作成

RUEIの使用または操作に関して問題が発生した場合は、Oracleサポート・サービスに問い合せることができます。ただし、その前に、ご使用のシステムのヘルプデスク・レポート・ファイルを作成することをお薦めします。これを実行するには、「システム」→「メンテナンス」→「ヘルプデスク・レポート」の順に選択します。ヘルプデスクの作成に時間がかかる場合があります。完了すると、ファイルのダウンロード先となる場所を指定するように求められます。

ヘルプデスク・レポート・ファイルには、ユーザーがレポートした問題をOracleサポート・サービスが処理するときに非常に役立つ様々なシステム情報が含まれています。

重要: 生成されたファイルには、ソフトウェアの所有権情報が含まれます。コンテンツを変更しないでください。

## 15.10 セッション・デバッグ・モードの操作

デフォルトでは、内部エラーは次のような汎用エラー・メッセージでユーザー・インタフェース内に表示されます。

    An internal system error has occurred. Please contact the Administrator with the error details.

しかし、エラーの詳細が必要な場合には、次の手順を実行して、セッション・デバッグを有効にすることができます。

1. 「ヘルプ」メニューから「セッション・デバッグ」オプションを選択します。図15-15に示すダイアログが表示されます。

   図15-15 「セッション・デバッグ」ダイアログ

   「図15-15 「セッション・デバッグ」ダイアログ」の説明

2. デバッグ・モードを有効にするよう指定するには、「デバッグの有効化」チェック・ボックスをオンにします。次に、「保存」をクリックします。

有効にすると、詳細なエラー・メッセージがレポートされます。また、メッセージ(および対応する診断情報)は指定されたログ・ファイルにも追加されます。この設定が適用されるのは、現在のセッションのみです。

注意: カスタマー・サポートにエラーを報告する際には、セッション・デバッグの機能を有効にすることをお薦めします。

## 15.11 電子メール構成の管理

2.3項「メーリング機能の使用方法」で説明しているように、RUEIでは要求されたレポートの自動電子メールを送信できます。この機能では、初期構成フェーズ(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)で指定した情報を利用します。ただし、「システム」→「メンテナンス」→「電子メール設定」の順に選択して、この構成を変更できます。図15-16に示すダイアログが表示されます。

図15-16 「電子メール設定」ダイアログ

「図15-16 「電子メール設定」ダイアログ」の説明

図15-16に示すフィールドを表15-5で説明しています。

表15-5 「電子メール設定」のフィールド

フィールド | 説明
--- | ---
返信用アドレス | 失敗した電子メールまたは問題が発生した電子メールのレポート先となる電子メール・アドレスを指定します。このアドレスを定期的にチェックすることを強くお薦めします。
送信元アドレス | 受信者のメール・クライアントに表示されるアドレスを指定します。
返信先アドレス | ユーザーが電子メール内でクリックして返信できるアドレスを指定します。これが指定されていない場合は、「送信元アドレス」設定が使用されます。
メール・サイズ制限 | 電子メールの最大許容メッセージ・サイズ(KB単位)を指定します。電子メールにこの制限を超えるレポートが含まれる場合は、この制限に対応するために、レポートが個別の電子メールに分割されます。個別に送信するには大きすぎるレポートは送信されず、ユーザーに問題が通知されます。デフォルトのメール・サイズ制限は5000KBです。
レポータURL | 電子メールの受信者がレポータ・システムに接続するために必要となる詳細なURLを指定します。通常、このURLは、RUEIユーザーがレポータ・システムにアクセスするために使用するURLと同じです。

## 15.12 システムのリセット

原因不明の問題が発生した場合は、処理が適切に動作して同期化されるように、処理をリセットできます。ただし、このオプションを選択すると、データの可用性と監視に一時的な遅延が発生します。

最後の手段として、収集されたすべてのデータをシステムから削除できます。また、すべてのパラメータ(作成されたユーザーや環境パラメータなど)をデフォルト値にリセットできます。

システムをリセットする手順は、次のとおりです。

1. 「システム」→「メンテナンス」→「システム・リセット」の順に選択します。図15-17に示すダイアログが表示されます。

   図15-17 システム・リセット・ウィザード

   「図15-17 システム・リセット・ウィザード」の説明

2. 目的のオプションを選択します。これらは表15-6で説明しています。

   表15-6 「システム・リセット」のオプション

   オプション | 説明
   --- | ---
   最新構成の再適用 | すべての構成変更(`ruei.conf`構成ファイルへの変更など)を即座に有効にします。これがデフォルトです。
   システム処理の再起動 | システム処理を再アクティブ化します。
   収集したデータのパージ | 収集されたすべてのデータをシステムから削除します。
   出荷時のデフォルトにリセット | 収集されたすべてのデータとSSL鍵を削除し、すべてのシステム・パラメータをデフォルト値にリセットします。

   次に、「次へ」をクリックします。

注意: 「収集したデータのパージ」および「出荷時のデフォルトにリセット」オプションは、実行すると取消しできません。収集されたすべてのデータが消去されます。「出荷時のデフォルトにリセット」の場合、すべてのシステム設定も元の状態に戻ります。したがって、レポータ・インタフェースにアクセスするには、初期構成をすべて(および`set-admin-password.sh`スクリプトを使用した`admin`ユーザー・パスワードの定義)行うことが必要になります。以前にバックアップを作成している場合(15.6項「構成バックアップの作成とリストア」を参照)は、初期構成後にそのバックアップをリストアできます。この初期構成の手順は、『Oracle Real User Experience Insightインストレーション・ガイド』に記載されています。

## 15.13 データ変換のカスタマイズ

特定の要件に合わせて、データ・アイテム(データ・ブラウザ・グループ、フィールド名など)をカスタマイズできます。RUEIカタログの動作方法について正しい知識を持っている場合のみ、この機能を使用することをお薦めします。

デプロイメントで使用するデータ変換をカスタマイズするには、次の手順を実行します。

1. 「構成」→「一般」→「詳細設定」→「データ変換」の順に選択します。カタログ・リストが表示されます。

2. 適切なデータ・アイテムをクリックします。図15-18に示すダイアログが表示されます。

   図15-18 「表示値の編集」ダイアログ

   「図15-18 「表示値の編集」ダイアログ」の説明

3. 優先する変換を指定します。「デフォルトに戻す」をクリックすると、出荷時のデフォルトにアイテムをリセットできます。次に、「保存」をクリックします。