ログ・ファイル・モニタリングを使用すると、WebLogic Serverとアプリケーション・デプロイメントのログ・ファイルをモニターして特定のパターンを確認できます。パターンが検出された場合にターゲットのコンテキストでアラート通知を受信するようにCloud Controlを設定できます。これにより、ユーザーが問題を発見する前に、管理者として問題に事前に対処し、学習することができます。
ログ・ファイル・モニタリングを設定および使用する方法は、次のトピックを参照してください。
ログ・ビューアによって、管理者は、ディスク上のファイルの存在場所に関係なく、ミドルウェア関連のログ・ファイルを表示、検索およびダウンロードできます。複数のFusion MiddlewareファームおよびWebLogicドメインに及ぶ複数のミドルウェア・コンポーネントのパフォーマンスの問題を、管理者が迅速に診断する際に役立つように、複雑な検索基準を指定し、後で参照するために保存できます。
注意:
Cloud Controlでログ・ビューアの機能をすべて使用する際に、ログ・メッセージを表示するターゲット・ドメインが、カスタム証明書を使用してSSLに対応している場合は、ログ・ビューアの機能が正常に機能しません。ログ・ビューアのほとんどの機能では、OMSにより、そのドメインの管理サーバーにJMX接続が確立されます。OMSにより管理サーバーに直接JMX接続が確立されないログ・ビューアの機能は、アーカイブ・ログ・ファイルに使用される機能のみです。アーカイブ・ログ・ファイルの表示には、エージェントがかわりに使用されます。
この環境でログ・ビューア機能が完全に機能するには、追加の構成変更を適用する必要があります。ログ・メッセージを表示するドメインの管理サーバー・ターゲットからカスタム証明書のrootcaを取得し、OMSのトラスト・ストアにインポートします。
ログ・ビューアにアクセスすると、選択したターゲット・タイプに対して、デフォルトの検索基準が指定されます。管理者は、特定のFusion Middlewareファームの診断の要件に基づいて、検索基準を絞り込むことができます。「フィールドの追加」ボタンを使用して、含める検索基準を絞り込むことができます。
Fusion Middlewareファームの1つ以上のメンバー・ターゲットの選択
日付範囲の指定
メッセージ・タイプの選択
検索するメッセージの指定
検索するECIDの指定
アプリケーション名の指定
ユーザー名の指定
検索基準を定義したら、管理者は「検索」ボタンをクリックします。
管理者は、必要に応じて検索を変更し、ログ・ビューアで「検索の保存」ボタンをクリックします。
検索を実行したターゲットなど、指定した検索基準は、現在ログインしている管理者の管理リポジトリに保存されます。
「保存済検索」ボタンをクリックして、以前に保存した検索基準を取得および保存することができます。
「保存済検索の管理」をクリックして、以前に保存した検索基準を編集または削除するポップアップを起動できます。
ログ・ファイル・モニタリングを使用すると、WebLogic Serverとアプリケーション・デプロイメントのログ・ファイルをモニターして特定のパターンを確認できるため、トラブルシューティングの時間を短縮できます。パターンが検出された場合にターゲットのコンテキストでアラート通知を受信するようにCloud Controlを設定できます。
「ログ・ファイル・モニタリング」のメトリック(WebLogic Serverおよびアプリケーション・デプロイメントのターゲット・タイプ用のログ・ファイル・パターン一致行数)を使用すると、1つ以上のログ・ファイルで、1つ以上の検索パターンの出現をモニタリングできます。また、ログ・ファイルで無視されるパターンも指定できます。最後のスキャン後に追加された新しい内容に対しては、デフォルトで60分ごとの定期的なスキャンが実行されます。無視パターンと一致する行が最初に無視され、指定した一致パターンに行が一致すると、パターンごとに1つのレコードがリポジトリにアップロードされます。指定されたパターンに一致する行の数のしきい値を設定できます。所定のファイル内でファイル・ローテーションが行われます。
また、モニタリング・テンプレート機能も使用できます。これによって管理者は、1度メトリックをテンプレートで構成すると、そのテンプレートを複数のWebLogic Serverまたはアプリケーション・デプロイメントのターゲットに同時に適用できるため、それぞれのWebLogic Serverログ・ファイルのモニタリング・メトリックを個別に構成する必要はありません。
ホスト・ターゲット・タイプを介したログ・ファイル・モニタリングを使用している場合、Fusion Middleware関連のターゲット・タイプを介してログ・ファイル・モニタリングを構成し、Fusion Middlewareターゲットのコンテキストでアラートが表示されるようにします。
ログ・ファイル・モニタリングの前提条件
ログ・ファイル・モニタリングには、ローカルの管理エージェント・モニタリング・ターゲットが必要です。つまり、モニタリング対象のログ・ファイルのホストに管理エージェントがインストールされており、稼働している必要があります。管理エージェントをインストールしたオペレーティング・システム・ユーザーには、モニタリング対象のログ・ファイルが存在するディレクトリへの読取りアクセス権が必要です。ログ・ファイル・モニタリングはデフォルトで無効になっています。この機能を使用するには、有効にする必要があります。
ログ・ファイル・モニタリングを構成するには、次の手順に従います。
ターゲット・メニューから、「モニタリング」を選択します。
「モニタリング」メニューから「メトリックと収集設定」を選択します。
「メトリックと収集設定」ページの「メトリック」タブで、「表示」ドロップダウン・メニューから「すべてのメトリック」を選択します。
「ログ・ファイル・モニタリング」を検索します。
「ログ・ファイル・モニタリング」行の下の「ログ・ファイル・パターン一致行数」行で、右側にある「編集」アイコンをクリックします。
「詳細設定の編集: ログ・ファイル・パターン一致行数」ページの「モニター対象オブジェクト」セクションで、「追加」をクリックして、モニタリング対象のログ・ファイルの設定を指定します。
「モニター対象オブジェクト」セクションの表には、このメトリックに設定されているすべてのログ・ファイル名、一致パターンおよび無視パターンがリストされます。列ごとに異なるしきい値設定を指定できます。「並替え」ボタンでは、最初にスキャンするログ・ファイルを指定します。
検索基準を設定するとき、ワイルドカードと正規表現を組み合せて使用できます。
「ログ・ファイル名」列に、検索するログ・ファイル名パターンを入力します。
「ログ・ファイル名」列でワイルドカードまたは正規表現(あるいはその両方)を使用する場合は、ログ・ファイルが存在するログ・ディレクトリの場所のパスを識別するためではなく、ログ・ファイル名を識別する目的でのみワイルドカードを使用してください。
次に例を示します。
/u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%.log
を指定した場合は、ログ・ディレクトリ内の.log拡張子を持つすべてのファイルが選択されます。
/u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%diagnostics%
を指定した場合は、ログ・ディレクトリ内のファイル名にdiagnosticsを含むすべてのファイルが選択されます。
/u01/domains/%_DOMAIN%/servers/EMGC_OMS1/logs/%diagnostics%
を指定した場合は、無効なパターンとして処理されます。ログ・ディレクトリ・パスの識別にワイルドカードを使用しないでください。
「一致パターン」列に、ログ・ファイル内で考慮する必要がある一致パターンを入力します。ワイルドカードと正規表現を組み合せて使用できます。大文字小文字も無視されます。
次に例を示します。
一致パターンをFATAL
と設定します。このパターンは、fatalを含むすべての行に対して真になります。
一致パターンを%fatal%critical%
と設定します。このパターンは、fatalとcriticalを含むすべての行に対して真になります。
「無視パターン」列に、ログ・ファイル内で無視する必要がある一致パターンを入力します。デフォルトでは、列に%が表示されます。何も無視しない場合は、デフォルト値を削除する必要があります。ワイルドカードと正規表現を組み合せて使用できます。大文字小文字も無視されます。
一致パターンをBEA-0023
と設定し、無視パターンをwarning
と設定します。このパターンでは、BEA-0023を検索しますが、同じ行にwarningが含まれている場合は無視します。
一致パターンをADFC-1023%FAILED%
と設定します。このパターンでは、同じ行内でFAILEDが後に続くADFC-1023のみを検索します。
一致パターンをBEA-%
と設定し、無視パターンをBEA-1005
と設定します。このパターンでは、BEA-で始まるすべてのパターンを検索しますが、BEA-1005は無視します。
「警告のしきい値」および「クリティカルのしきい値」列で、パターンが収集スケジュール内で指定した回数ログ・ファイルに出現した場合にアラートがトリガーされるように、しきい値をその回数に設定します。発生回数が詳細設定で指定されている場合は、この係数がアラート発生時に考慮されます。
たとえば、クリティカルしきい値を1に設定(パターンがログ・ファイルに複数回見つかると、クリティカル・アラートになります)し、発生数を2に設定した場合、クリティカル・アラートが発生するのは、連続する2回の収集内でログ・ファイルにパターンが複数回見つかる場合のみです。
「ログ・ファイル・パターン一致行数」メトリックをモニタリング・テンプレートの一部に含める
ログ・ファイル・モニタリングが有効化および構成されている場合、「ログ・ファイル・パターン一致行数」メトリックをモニタリング・テンプレートの一部に含めることができます。ログ・ファイルの場所は、テンプレートが適用されるターゲット全体で同じである必要があります。モニタリング設定をターゲットごとに個別に設定するのではなく、テンプレートを複数のWebLogic Serverまたはアプリケーション・デプロイメントのターゲットに一度に適用できます。
ログ・ファイル・モニタリング・メトリックの構成後に、指定したパターンがログ・ファイルに含まれるが、アラートがOMSに生成されない場合は、次を実行してください。
ログ・ファイル名にPerlパターンが含まれているかどうかを確認します。
無視パターンにアスタリスク(*)が含まれているかどうかを確認します。無視パターン・フィールドにアスタリスクを指定すると、一致するパターンが含まれるすべての行も無視されます。
構成の問題
特定のターゲットについてロギング構成が見つからないか、無効であることを示すエラー・メッセージが表示される場合、次のオプションを試行できます。
最初に、アクセスしようとしているWebLogicドメインがOracle JRF (Java必須ファイル)有効でない可能性があります。Oracle JRFはOracle WebLogic Serverインストールに含まれていないコンポーネントで構成されており、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークの共通機能を提供します。ログ・メッセージを表示するには、ターゲットがOracle JRF有効である必要があります。WebLogicドメインがOracle JRF有効であるかどうかなどを確認するには、次の手順を実行します。
ドメインの「JRF適用可能」プロパティの値がtrueの場合、そのドメイン内のすべての管理対象サーバーがOracle JRF有効でなくてもかまいません。特定の管理対象サーバーのコンテキストでログ・メッセージにアクセスできない場合、関連する管理対象サーバーの「モニタリング構成」ページに移動します。「モニタリング構成」ページから、「JRF有効」プロパティを検索します。このプロパティの値はtrueまたはfalseのいずれかです。値がfalseの場合、管理対象サーバーはOracle JRF有効ではありません。
2番目に、Enterprise Manager Cloud Control管理者がログ・メッセージへのアクセスを試行していますが、必要なターゲット権限がありません。ログ・メッセージを表示するには、管理者に、該当するターゲットに対する「Fusion Middlewareのログを表示する権限」ターゲット権限が付与されている必要があります。Oracle Enterprise Managerのサイト管理者またはスーパー管理者に、ユーザー自身にこの権限が付与されているかどうかを問い合せます。このターゲット権限、および管理者への権限の付与の詳細は、このドキュメントの後半の質問を参照してください。