11 Oracle Access ManagementのパフォーマンスとAccess Managerのヘルスのモニタリング

パフォーマンス・モニタリングとは、Oracle Access Managementの特定のコンポーネントの状態を確認するために、パフォーマンス・メトリックを観察(表示)することを指します。

サーバー・ヘルスのモニタリングは、ハートビートURLまたはヘルス・チェック・フレームワークを使用して実行できます。

ハートビートURLは、事前定義済の一連のテストを実行して、httpsステータス・コードのみを返し、追加情報はありません。

ヘルス・チェック・フレームワークでは、httpレスポンス本文での追加情報がサポートされています。この情報では、テストの性質とテストの結果に関する情報を示すことができます。実行されるテストは、構成またはリクエスト自体によって制御することもできます。

現在サポートされているテストは、DMSメトリックおよびログ情報のみに依存します。

この章には、Oracle Access ManagementのパフォーマンスおよびAccess Managerのヘルスのモニタリングに関する次の各項で構成されています。

• パフォーマンス・モニタリングの概要

• Oracle Access Managementコンソールを使用したサーバー・メトリックの監視

• OAMプロキシ・メトリックとチューニング

• DMSコンソールを使用したメトリックの監視

• Access Managerサーバーのヘルスのモニタリング

• ヘルス・チェック・フレームワークによるサーバー・ヘルスのモニタリング

これに加えて、管理サーバーではJMXでDMSメトリックが公開されます。displayOAMMetrics WLSTコマンドを参照してください。

関連項目:

• Oracle Enterprise Manager Fusion Middleware Controlを使用する場合は、「Fusion Middleware Controlによるパフォーマンスおよびログのモニタリング」を参照してください。

11.1 パフォーマンス・モニタリングの概要

コンポーネント・パフォーマンス・メトリックは、特定のイベントを完了する間に、メモリー内で収集されます。これらのメトリックはメモリー内でのみ保持されるため、Oracle Enterprise Manager Fusion Middleware Control (FMW)、Oracle Dynamic Monitoring Service (DMS)、Oracle Process Manager and Notification Server (OPMN)など、メトリックを抽出して表示するメカニズムが複数用意されています。

• FMW Controlは、監視オプションを備えたWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースです。詳細は、「Fusion Middleware Controlによるパフォーマンスおよびログのモニタリング」を参照してください。

• DMSでは、DMSスパイ・サーブレットを使用して、WebブラウザからDMSメトリック・データにアクセスします。情報はナウン・タイプ別に分類され、Oracle Access Managementの場合、接頭辞はOAMS.OAM_です。「DMSコンソールを使用したメトリックの監視」を参照してください。

• dmsダンプはDMSによって提供され、dms構成ファイルの定義に基づいて、サーバーからメトリックを取得します。dmsダンプが生成されると、多くのOAMメトリックが表示されます。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のOracle Dynamic Monitoring Service (DMS)に関する説明を参照してください。

• OPMNでは、dmsダンプを使用してメトリックにアクセスします。

11.2 Oracle Access Managementコンソールを使用したサーバー・メトリックの監視

有効なOracle Access Management管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールにログインして、様々なパフォーマンス・メトリックを監視できます。

この項では次のトピックを記載しています:

• サーバー・インスタンス・パフォーマンスのモニタリング

• Oracle Access Managerサーバー・メトリック

11.2.1 サーバー・インスタンス・パフォーマンスのモニタリング

有効なOracle Access Management管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールで「システム構成」タブの「アクション」メニューの「モニタリング」コマンドを使用して、Access Managerのパフォーマンスを監視できます。

詳細は、「Oracle Access Managementコンソールの理解」を参照してください。

開始する前に、OAMサーバーを実行している必要があります。

1. Oracle Access Managementコンソールで、「サーバー・インスタンス」をクリックし、目的のサーバー・インスタンスをクリックします。

2. サーバー・インスタンス:

   1. ナビゲーション・ツリーの「アクション」メニューで、「モニター・メニュー」をクリックします。

   2. 「モニター」ページで、必要なサブタブをクリックして、サーバー・インスタンスの結果を表示します。

      • サーバー・プロセス概要
      • セッション操作
      • サーバー操作
      • WebGates

   3. 「Oracle Access Managerサーバー・メトリック」に進みます。

3. 「OAMプロキシ・メトリックとチューニング」も参照してください。

11.2.2 Oracle Access Managerサーバー・メトリック

このトピックでは、コンソールの「構成」セクションにある「サーバー・インスタンス」タブの「モニター」オプションで選択できるサーバー・メトリックについて説明します。

図11-1は、サーバー・プロセスのページを示しています。

図11-1 「サーバー・プロセス概要」ページ

「図11-1 「サーバー・プロセス概要」ページ」の説明

「サーバー・プロセス概要」タブでは、次のOAMサーバー・イベントが各列に個別に整理されて表示されます。

次に、「サーバー・プロセス概要」タブ内のサーバー・メトリック列を示します。

• 認可プロセス

• 認可リクエスト

• 認証プロセス失敗

• 認証プロセス成功

• 認証前プロセス失敗

• 認証前プロセス成功

図11-2は、「セッション操作」タブを示しています。

図11-2 OAMサーバー・メトリック: 「セッション操作」の「モニター」ページ

「図11-2 OAMサーバー・メトリック: 「セッション操作」の「モニター」ページ」の説明

OAMサーバーの「セッション操作」のメトリックには、次のものが含まれます。

• セッション検証チェック

• セッション検証チェック失敗

• セッション検証チェック成功

• セッション作成

• セッション作成失敗

• セッション作成成功

• セッション破棄

• セッション破棄失敗

• セッション破棄成功

• クライアント・セッション削除

• クライアント・セッション削除失敗

図11-3は、「サーバー操作」タブを示しています。

図11-3 OAMサーバー・メトリック: 「サーバー操作」タブ

「図11-3 OAMサーバー・メトリック: 「サーバー操作」タブ」の説明

次に、「サーバー操作」タブ内のOAMサーバー操作のメトリックを示します。

• 認証ポリシー・レスポンス失敗

• 認証ポリシー・レスポンス成功

• 認証スキーム・レスポンス失敗

• 認証スキーム・レスポンス成功

• 認証の失敗

• 認証失敗レスポンス

• 認証ポリシー・レスポンス

• 認証リクエスト

• 認証スキーム・レスポンス

• 認可の失敗

• 認可の失敗

• 認可プロセス失敗

• 認可プロセス成功

図11-4は、使用可能なメトリックがすべて表示されているOAMサーバー・メトリック: 「Webゲート」タブを示しています。

図11-4 OAMサーバー・メトリック: 「Webゲート」タブ

「図11-4 OAMサーバー・メトリック: 「Webゲート」タブ」の説明

Webゲートのパフォーマンス・メトリックには次のものがあります。

• エージェント名

• エージェント・ステータス

• バージョン

11.3 OAMプロキシ・メトリックとチューニング

管理者は、Java EEコンテナ管理コンソールを通じてOAMプロキシのパフォーマンスをチューニングできます。

この項では次のトピックを記載しています:

• OAMプロキシ・メトリック

• OAMプロキシ・サーバーのチューニング・パラメータ

関連項目:

• パフォーマンスのチューニング

11.3.1 OAMプロキシ・メトリック

スループットとは、1秒間に処理されるリクエスト数を言います。待機時間とは、特定のリクエストを処理するために必要な時間を言います。WebGateとOAMサーバーの間にプロキシを導入することによる待機時間の増加は20%未満です。

表11-1は、使用できる様々なOAMプロキシ・メトリックを示しています。

表11-1 OAMプロキシ・メトリック

メトリック	説明
handshakes.active	ハンドシェイクを行うアクティブ・スレッドの数
handshakes.avg	初期ハンドシェイクの実行に要した平均時間
handshakes.completed	初期ハンドシェイクが実行された回数
handshakes.maxTime	初期ハンドシェイクの実行に要した最大時間
handshakes.minTime	初期ハンドシェイクの実行に要した最小時間
handshakes.time	初期ハンドシェイクの実行に要した合計時間
failedHandshakes.count	失敗したハンドシェイク数
peerCompatibilityFailures.count	ピア互換性チェック失敗の発生回数
openSecurityMode.count	オープン・セキュリティ・モード・ハンドシェイクの発生回数
simpleSecurityMode.count	シンプル・セキュリティ・モード・ハンドシェイクの発生回数
SSLSecurityMode.count	SSLセキュリティ・モード・ハンドシェイクの発生回数
negotiateSecurityMode.active	セキュリティ・モード・ネゴシエーションを実行中のアクティブ・スレッド数

11.3.2 OAMプロキシ・サーバーのチューニング・パラメータ

OAMプロキシのパフォーマンスは、Java EEコンテナ管理コンソールを通じてその構成を変更することによってチューニングすることができます。

Java EEコンテナ管理者とOracle Access管理者はどちらも、Java EEコンテナ管理コンソール(このドキュメントでは取り上げません)を使用してパフォーマンスをチューニングできます。

OAMプロキシのチューニング・パラメータを表11-2に示します。

表11-2 OAMプロキシのチューニング・パラメータ

目的	パラメータ	タイプ	値	説明
サービス拒否攻撃	ConnectionValidationInterval	整数	120	サービス拒否攻撃に関して定期的に接続の検証を行う際の時間間隔(秒)
サービス拒否攻撃	BacklogQueue	整数	50	バックログ・キューの最大長さ
サービス拒否攻撃	MaxNAPHandShakeTime	整数	100	クライアント同士がNAPシェイクハンドを完了させるまでに使用できる最大時間(ミリ秒)。ある接続を介したNAPシェイクハンドがこの時間内に完了しなかった場合、その接続は悪意あるものとしてマークされます。

11.4 DMSコンソールを使用したメトリックの監視

Oracle Access Managementは、Oracle Dynamic Monitoring Systems (DMS)を使用し、OAMサーバーおよび登録されたエージェントについてアプリケーション固有のパフォーマンス情報を測定します。メトリックを使用すると、特定の領域内で経過した時間をモニターしたり、特定の発生事象や状態変化を追跡したりすることができます。

DMSコンソールにアクセスするには、次のURLをブラウザ・ウィンドウに入力し、Oracle Access Management管理者資格証明でログインします。

http:// <example_AdminServer:Port/dms/Spy

DMSコンソールにログインすると、次の項に説明されてるようにメトリックを監視できます。

• OAMメトリックの監視

11.4.1 OAMメトリックの監視

OAMメトリックは、DMSメトリック表パネルで確認できます。

図11-5に示すように、OAMに関するメトリックにアクセスできます。表示されている必要なメトリックをクリックして、コンソールの右側に結果を表示します。

図11-5 OAMメトリック表

「図11-5 OAMメトリック表」の説明

11.5 Access Managerサーバーのヘルスのモニタリング

Access Managerサービスはビジネス上重要なものであり、保護されている組織のWebサービスやアプリケーションに対するユーザーのアクセス制御のために、常に利用可能であることが必要です。ハードウェアやネットワーク接続性の問題、およびその他の障害が発生することがあるため、ロード・バランサはハートビート・モニタリングを活用して、ユーザー・トラフィックが正常なOAMサーバーに確実にルーティングされるようにする場合があります。

たとえば、ユーザー・エージェントまたはWebGateとAccess Managerサーバーとの間にファイアウォールがインストールされている場合に、周辺装置は、ハートビートURLにアクセスすることによって、Access Managerサーバーの可用性(そのヘルス)をチェックできます。次の各項では、詳細を説明します。

• WebGateとAccess Manager通信の理解

• Access Managerサーバーのヘルスのモニタリング

11.5.1 WebGateとAccess Manager通信の理解

WebGateとAccess Managerサーバーの間にネットワーク・ファイアウォールをデプロイする場合、WebGateはメッセージ・チャネルを確立するために、Access ManagerとのTCPソケット接続を作成して、OAPプロトコルを使用して通信します。WebGateは、メッセージ・チャネルを使用して、リソース要求(isprotectedやisauthorizedなど)に応えるために必要な様々なOAPメッセージを送信します。ここで、WebGate/Oracle HTTP Serverがアイドル状態である状況を想定してみます。この場合には、WebGateはリソース要求を受け取っておらず、認証や認可のためにAccess Managerにメッセージを送信することもありません。また、ソケット接続上での読取り/書込み動作も行われません。

ファイアウォールでは、30-40分間アクティブではなかった場合(構成に依存します)に、この接続がアイドルであると判定してソケット接続を終了しますが、WebGateやAccess Managerサーバーには通知を行いません。このケースでは、WebGateがリソース要求を受け取ってAccess ManagerサーバーにOAPメッセージを送信する際には、既存の接続を使用してリプライを待ちます。接続はファイアウォールによって削除されているため、WebGateがリプライを受け取ることはなく、TCPタイムアウトを待つことになります。TCPタイムアウトの後、WebGateはメッセージ・チャネルが使用できないことを理解し、メッセージ・チャネルを新規に作成する処理を開始します。WebGateがユーザー要求を処理できなくなるTCPタイムアウトはOS固有の機能であり、数分から数時間までの幅があります。

ノート:

setKeepAlive WebGateパラメータによって、ロード・バランサによるOAP接続の削除を停止できます。詳細は、表15-2を参照してください。

11.5.2 Access Managerサーバーのヘルスのモニタリング

OAMモニタリング・モデルでは、既定の時間間隔にて、Web層コンポーネント(ロード・バランサ)がOAM管理対象サーバーのハートビート・エンドポイントに向けて、pingをHTTP(S)経由で送信できます。これによってWeb層コンポーネントは、受信HTTPトラフィックを異常なOAM管理対象サーバー以外にルーティングさせることが可能です。

すべてのOAM管理対象サーバーは、次のハートビートURLを公開しています。

Scheme://ManagedServerHost:ManagedServerPort/oam/server/HeartBeat

このURLの構成要素は次のとおりです。

• scheme = https | http

• ManagedServerHost = Access Manager WLS管理対象サーバーのホスト名

• ManagedServerPort = Access Manager WLS管理対象サーバーが使用しているポート

ハートビートURLは次のように動作します。

1. Web層コンポーネントは、Access Manager管理対象サーバーのハートビート・エンドポイントにHTTPリクエストを送信します。
2. すると、Access Manager管理対象サーバーは、次の処理を実行します。

   • Idストアの接続性を確認します。

   • ポリシー・ストアの接続性を確認します。

   • 資格証明コレクタURLがアクセス可能であることを確認します。

   • コヒーレンス・レイヤーの動作の健全性チェックを行います。

   • NAP接続性をチェックします。

   前述のテストが成功した場合には、Access Managerサーバーは正常であるとみなされ、HTTP 200応答がロード・バランサに送信されます。それ以外のHTTPステータス・コードはすべて、Access Manager管理対象サーバーが異常であることを示します。

3. 複数台のAccess Manager管理対象サーバーがデプロイメント中に存在する場合、Web層コンポーネントは各OAM管理対象サーバーに対してこの処理を繰り返します。

ノート:

ヘルス・ステータスのテスト結果またはチェック結果のいずれも、HTTP応答のボディ部で通信することはできません。ハートビート・チェックが成功すると、HTTPコード200が返されます。

WARNING:

OAMサーバーのヘルス・チェックでは、サーバーの最大ヒープ・サイズが1.5 GB未満になるように構成されている場合に、Weblogic管理コンソールでOAMに対する警告を生成します。

11.6 ヘルス・チェック・フレームワークによるサーバー・ヘルスのモニタリング

ヘルス・チェック・フレームワークにより、サーバーのヘルス・チェックが可能になります。

次の項では、ヘルス・チェックについて説明します

• ヘルス・チェック・フレームワークの概要

• ヘルス・チェック・テスト構成の理解

• REST APIを使用したヘルス・チェックの実行

• スケジュール済ヘルス・チェックの構成

• ヘルス・スクリプト・エバリュエータの使用

11.6.1 ヘルス・チェック・フレームワークの概要

ヘルス・チェック・フレームワークにより、サーバーのヘルス・チェックが可能になります。これらのチェックを実行するには、REST APIを使用するか、サーバーの定期的なチェックをスケジュールします。各スケジュールは、実行する特定のテスト・セットに関連付けることができます。

REST API呼出しは、事前構成済のヘルス・チェック・テストをサーバーに対して実行し、テスト実行のステータスを返します。

フレームワークでは、コンポーネントによる/health/check APIを介した問題の通知がサポートされています。リクエストにテスト・リストが指定されていない場合、デフォルトのテスト・セットの結果が返されます。

フレームワークでは、ヘルス・チェック・テストに集計サービスが提供されます。これらの集計サービスにより、構成された期間にわたって複数のテストの結果を累積できます。

テスト結果は、サーバーで実行されるアクションにマップされます。これらのアクションは、テストおよびヘルスの結果に基づきます。アクションおよびマッピングはoam-config.xmlファイルで構成します。

これらのアクションには、Weblogicヘルス・チェック・コールバックのサブスクライブやWeblogicサーバー状態の適切な設定などが含まれます。詳細は、『Oracle® Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理』のサーバー・ヘルス・モニタリングの構成に関する項を参照してください

11.6.2 ヘルス・チェック・テスト構成の理解

ヘルス・チェック・フレームワークには、ヘルス・チェックAPIの呼出し時またはスケジュール済のヘルス・チェック中に実行される事前構成済のヘルス・チェック・テストが用意されています。

ヘルス・チェック・テストは、oam-config.xmlファイルのHealthCheck要素の下のTestList設定で構成されます。

<?xml version="1.0" encoding="UTF-8"?>
<Configuration xsd:schemaLocation="http://higgins.eclipse.org/sts/Configuration Configuration.xsd" Path="/DeployedComponent/Server/NGAMServer/Profile/HealthCheck">
  <Setting Name="HealthCheck" Type="htf:map">
    <Setting Name="TestLists" Type="htf:list">
      <Setting Name="0" Type="hcf:testList">
        <Setting Name="Id" Type="xsd:string">TL001</Setting>
        <Setting Name="Name" Type="xsd:string">TL001</Setting>
        <Setting Name="Lang" Type="xsd:string">EN</Setting>
        <Setting Name="Validity" Type="xsd:duration">PT5M</Setting>
        <Setting Name="TestList" Type="htf:list">
          <Setting Name="0" Type="xsd:string">HeapSizeCheck</Setting>
          <Setting Name="1" Type="xsd:string">FreeHeapCheck</Setting>
          <Setting Name="2" Type="xsd:string">LoginFailureCheck</Setting>
          <Setting Name="3" Type="xsd:string">DirectoryOutage</Setting>
          <Setting Name="4" Type="xsd:string">DirectoryLatency</Setting>
          <Setting Name="5" Type="xsd:string">AuthenticationLatency</Setting>
          <Setting Name="6" Type="xsd:string">AuthorizationLatency</Setting>
        </Setting>
      </Setting>
    </Setting>
    <Setting Name="Schedules" Type="htf:list">
      <Setting Name="0" Type="hcf:schedule">
        <Setting Name="Id" Type="xsd:string">TS001</Setting>
        <Setting Name="Name" Type="xsd:string">TS001</Setting>
        <Setting Name="Desc" Type="xsd:string">Default schedule. Runs every minute.</Setting>
        <Setting Name="Lang" Type="xsd:string">EN</Setting>
        <Setting Name="Cron" Type="xsd:string">* * * * *</Setting>
        <Setting Name="Enabled" Type="xsd:boolean">true</Setting>
        <Setting Name="TestListId" Type="xsd:string">TL001</Setting>
      </Setting>
    </Setting>
    <Setting Name="ComponentTests" Type="htf:list">
      <Setting Name="0" Type="hcf:compTest">
      </Setting>
      <Setting Name="1" Type="hcf:compTest">
      </Setting>
      <Setting Name="2" Type="hcf:compTest">
      </Setting>
      <Setting Name="3" Type="hcf:compTest">
        <Setting Name="Id" Type="xsd:string">DirectoryOutage</Setting>
        <Setting Name="Name" Type="xsd:string">DirectoryOutage</Setting>
        <Setting Name="Lang" Type="xsd:string">EN</Setting>
        <Setting Name="Criticality" Type="hcf:criticality">AUXILIARY        </Setting>
        <Setting Name="Timeout" Type="xsd:duration">P0Y0M0DT0H0M1.000S</Setting>
        <Setting Name="Class" Type="xsd:string">oracle.security.am.healthcheck.featuretest.dms.DmsMetricsDrivenChecks</Setting>
        <Setting Name="Parameters" Type="htf:list">
          <Setting Name="0" Type="xsd:string">/*Directory outages are detected based on LIBOVD-40067 messages that are issued every minute.*/refid = LogsUtil.recordLogMessage("oracle.ods.virtualization.engine.backend.jndi.adapter1", "LIBOVD-40067");windowSize = LogsUtil.getLogOccurrencesWindow(refid);if (windowSize <> 180000.0) {  LogsUtil.setLogOccurrencesWindow(refid, 180000.0);  windowSize = LogsUtil.getLogOccurrencesWindow(refid);};count = LogsUtil.getLogOccurrences(refid);ScriptUtil.removeVariable("refid");count < 0.5;</Setting>
        </Setting>
      </Setting>
      <Setting Name="4" Type="hcf:compTest">
      </Setting>
      <Setting Name="5" Type="hcf:compTest">
      </Setting>
      <Setting Name="6" Type="hcf:compTest">
      </Setting>
    </Setting>
  </Setting>
</Configuration>

/iam/admin/config/api/v1/config APIのGETメソッドとPUTメソッドを使用して、構成をフェッチおよび更新できます。詳細は、「スケジュール済ヘルス・チェックの構成」を参照してください。

ヘルス・チェック・テスト	説明
HeapSizeCheck	正しく構成されていないサーバーの特定に役立ちます。 DMSメトリックを呼び出して、ヒープ・サイズを特定します。 ヒープ・サイズが構成値より小さい場合、テストは失敗とみなされ、サーバーは警告状態になります。
FreeHeapCheck	サーバーが制限の対象であるかどうかの判断に役立ちます。 DMSメトリックを呼び出して、空きヒープを測定します。 空きヒープと最大ヒープの比率(割合)がしきい値変数freeThresholdの値より低い場合、テストは失敗とみなされ、サーバーは警告状態になります。
LoginFailureCheck	ユーザーのログイン失敗率の特定に役立ちます。
DirectoryOutage	サーバーは1分ごとにディレクトリの状態をテストします。停止があった場合、ログ・メッセージが生成されます。このようなログ・メッセージ(たとえば、LIBOVD-40067)がこのテストで検出されると、テストが失敗し、サーバーは失敗した状態になります。
DirectoryLatency	構成済のサンプリング・ウィンドウ内の現在のサンプルを対象に、ディレクトリ待ち時間の増加を検出します。待ち時間が構成済の許可された値よりも大きい場合、テストは失敗とみなされ、サーバーは警告状態になります。
AuthenticationLatency	構成済のサンプリング・ウィンドウ内の現在のサンプルを対象に、認証待ち時間の増加を検出します。待ち時間が構成済の許可された値よりも大きい場合、テストは失敗とみなされ、サーバーは警告状態になります。
AuthorizationLatency	構成済のサンプリング・ウィンドウ内の現在のサンプルを対象に、認可待ち時間の増加を検出します。待ち時間が構成済の許可された値よりも大きい場合、テストは失敗とみなされ、サーバーは警告状態になります。

ヘルス・チェック・フレームワークには、独自のテストを作成するためのヘルス・スクリプト・エバリュエータ・ツールも用意されています。詳細は、「ヘルス・スクリプト・エバリュエータの使用」を参照してください。

11.6.3 REST APIを使用したヘルス・チェックの実行

/health/check REST APIを使用して、事前構成済のテストをサーバーに対して実行できます。

次のREST APIコマンドを実行して、サーバーのヘルス・チェックを実行します:

curl -X GET --header 'Authorization:' 
--header 'Accept: application/json' 
'http://<ManagedServerHost>:<ManagedServerPort>/health/check' 
-d {report: summary, testlistid}

次の表に、パラメータの詳細を示します:

表11-3 ヘルス・チェックREST APIのパラメータ

パラメータ	説明
Report	レスポンスの内容を判断します。次の値がサポートされています。 summary – テストした各コンポーネントのサマリー・レポートがレスポンスで返されます。 details – テストした各コンポーネントの詳細レポートが、レスポンスで返されます。
testlistid	オプション。実行する一連のテストを指定します。このパラメータを指定しなかった場合は、oam-config.xmlファイル内でIDがrestTestListIdのtestList要素にリストされているすべてのテストが実行されます。

11.6.4 スケジュール済ヘルス・チェックの構成

ヘルス・チェック・フレームワークにより、スケジュール済ヘルス・チェックをサーバーに対して実行できます。特定のスケジュールに関連付けられている一連のテストが定期的に実行されます。構成済テストは、複数のスケジュールで実行できます。

定期的なヘルス・チェックは、oam-config.xmlファイルのHealthCheck要素で構成されたパラメータおよび値に基づいて実行されます。

特定のテスト・セットのスケジュールを作成するには、次のステップに従います:

1. 管理構成APIを使用して構成設定をフェッチします。HealthCheck設定のパスを指定します。たとえば:

   http://<AdminServerHost>:<AdminServerPort>/iam/admin/config/api/v1/config
   ?path=/DeployedComponent/Server/NGAMServer/Profile/HealthCheck

2. 次に示すように、実行する必要があるテストをTestLists設定に追加します。

   <Setting Name="TestLists" Type="htf:list"
   Path="/DeployedComponent/Server/NGAMServer/Profile/HealthCheck/TestLists">
   <Setting Name="0" Type="hcf:testList">
   <Setting Name="Id" Type="xsd:string">TL001</Setting>
   <Setting Name="Name" Type="xsd:string">TL001</Setting>
   <Setting Name="Lang" Type="xsd:string">EN</Setting>
   <Setting Name="Validity" Type="xsd:duration">-PT5M</Setting>
   <Setting Name="TestList" Type="htf:list">
   <Setting Name="0" Type="xsd:string">HeapSizeCheck</Setting>
   <Setting Name="1" Type="xsd:string">FreeHeapCheck</Setting>
   <Setting Name="2" Type="xsd:string">LoginFailureCheck</Setting>
   <Setting Name="3" Type="xsd:string">DirectoryOutage</Setting>
   <Setting Name="4" Type="xsd:string">DirectoryLatency</Setting>
   <Setting Name="5" Type="xsd:string">AuthenticationLatency</Setting>
   <Setting Name="6" Type="xsd:string">AuthorizationLatency</Setting>
   </Setting>
   </Setting>
   <Setting Name="1" Type="hcf:testList">
   <Setting Name="Id" Type="xsd:string">LoginTestList</Setting>
   <Setting Name="Name" Type="xsd:string">LoginTestList</Setting>
   <Setting Name="Lang" Type="xsd:string">EN</Setting>
   <Setting Name="Validity" Type="xsd:duration">-PT5M</Setting>
   <Setting Name="TestList" Type="htf:list">
   <Setting Name="0" Type="xsd:string">LoginFailureCheck</Setting>
   </Setting>
   </Setting>
   <Setting Name="2" Type="hcf:testList">
   <Setting Name="Id" Type="xsd:string">LDAPOutageTestList</Setting>
   <Setting Name="Name" Type="xsd:string">LDAPOutageTestList</Setting>
   <Setting Name="Lang" Type="xsd:string">EN</Setting>
   <Setting Name="Validity" Type="xsd:duration">-PT5M</Setting>
   <Setting Name="TestList" Type="htf:list">
   <Setting Name="0" Type="xsd:string">DirectoryOutage</Setting>
   </Setting>
   </Setting>
   <Setting Name="3" Type="hcf:testList">
   <Setting Name="Id" Type="xsd:string">LatencyTestList</Setting>
   <Setting Name="Name" Type="xsd:string">LatencyTestList</Setting>
   <Setting Name="Lang" Type="xsd:string">EN</Setting>
   <Setting Name="Validity" Type="xsd:duration">-PT5M</Setting>
   <Setting Name="TestList" Type="htf:list">
   <Setting Name="0" Type="xsd:string">DirectoryLatency</Setting>
   <Setting Name="1" Type="xsd:string">AuthenticationLatency</Setting>
   <Setting Name="2" Type="xsd:string">AuthorizationLatency</Setting>
   </Setting>
   </Setting>
   </Setting>

3. Schedules設定の下で、実行するテストのスケジュールを追加します。たとえば、テストLoginTestJobを2分ごとに、LDAPOUTAGEJobを10分ごとにスケジュールするには、次のようにパラメータを設定します:

   
   <Setting Name="Schedules" Type="htf:list" Path="/DeployedComponent/Server/NGAMServer/Profile/HealthCheck/Schedules">
               <Setting Name="1" Type="hcf:schedule">
                   <Setting Name="Id" Type="xsd:string">LoginTestJob</Setting>
                   <Setting Name="Cron" Type="xsd:string">*/2 * * * *</Setting>
                   <Setting Name="Enabled" Type="xsd:boolean">true</Setting>
                   <Setting Name="TestListId" Type="xsd:string">LoginTest</Setting>
               </Setting>
               <Setting Name="2" Type="hcf:schedule">
                   <Setting Name="Id" Type="xsd:string">LDAPOUTAGEJob</Setting>
                   <Setting Name="Cron" Type="xsd:string">*/10 * * * *</Setting>
                   <Setting Name="Enabled" Type="xsd:boolean">true</Setting>
                   <Setting Name="TestListId" Type="xsd:string">LDAPOUTAGE</Setting>
               </Setting>            
   </Setting>

4. 次のように、管理構成APIのPUTメソッドを使用して、構成を更新します:

   curl -u username:password -H 
   'Content-Type: text/xml' 
   -X PUT http://<AdminServerHost>:<AdminServerPort>/iam/admin/config/api/v1/config 
   --data-binary @ConfigFile

11.6.5 ヘルス・スクリプト・エバリュエータの使用

ヘルス・チェック・フレームワークにはスクリプト・エバリュエータ・ツールが含まれており、このツールを使用して、DMSメトリックに基づいたヘルス・チェック・テストを作成し、ツール内で評価できます。

エバリュエータ・ツールには、DMSセンサーから値を抽出するユーティリティ関数と、それらの値を取得する変数が用意されています。このツールでは、テストを評価するために、計算式とブール式とともにブランチもサポートされています。

エバリュエータ・ツールは、評価用のスクリプトを入力できるテキスト領域で構成されています。評価結果は下部のパネルに表示されます。

評価中に作成された暫定変数と実行完了後の値は、作成された変数パネルに表示されます。

最終値は、例外と戻り値パネルに表示されます。

ノート:

テスト結果を示すブール値を戻すには、スクリプトを作成する必要があります。

関数に無効な値が渡された場合、戻された例外の例外と戻り値パネルに、パラメータで使用可能な値が含まれていることがあります。

ヘルス・スクリプト・エバリュエータには、次のリンクからアクセスできます:

http://<ManagedServerHost>:<ManagedServerPort>/iam/access/api/v1/health/script/evaluate

ツールでサポートされている関数、ブランチ、変数および式に関する構文と詳細を参照するには、エバリュエータ・ツールの「ヘルプ」をクリックしてください。「ヘルプ」にはコード・スニペットも用意され、これらをクリックするとテキスト領域に直接コピーされます。

ツールで実行可能なすべての操作については、http://<ManagedServerHost>:<ManagedServerPort>/iam/access/api/v1/health/dms/infoを参照してください

次のリンクに示されたセンサー情報とメトリックを使用して、関数に追加されたパラメータの値を取得できます: http://<ManagedServerHost>:<ManagedServerPort>/iam/access/api/v1/health/dms/info?operation=sensors

ノート:

エバリュエータ・ツールでヘルス・チェック・スクリプトを作成および評価した後、スケジュール済チェック用のテストを構成ファイルに追加することもできます。詳細は、「スケジュール済ヘルス・チェックの構成」を参照してください。

エバリュエータ・ツールでの単純なヘルス・チェック・テストの作成

この例では、ヒープ・サイズが1500000KB未満の、正しく構成されていないサーバーを特定できます。次のステップの説明に従ってスクリプトを作成し、エバリュエータ・ツールに追加します:

1. サーバーで構成されているヒープ・サイズを取得するには、センサー関数DmsUtil.getMetricValue("type", "noun", "path", "sensorName", "metric")を使用し、その値をmaxHeap変数に割り当てます。

   関数のパラメータに必要な詳細を取得するには、http://<ManagedServerHost>:<ManagedServerPort>/iam/access/api/v1/health/dms/info?operation=sensorsを参照してください。この例で、typeはJVM_MemorySet、nounはHeap memory、pathはPath:/JVM/MxBeans/memory/type/Heap memory、sensorNameはmaxで、metricはvalueにできます。

2. DmsUtil.getMetricUnits(sensor, "metric")を使用して単位値を取得し、その値をunits変数に割り当てます。
3. 変数heapThreshold = 1500000を設定します。
4. ブール演算子>を使用して、maxheapをheapThresholdと比較します。

// Threshold determines free memory in percentage that triggers server criticality.
heapThreshold = 1500000;

maxHeap = DmsUtil.getMetricValue("JVM_MemorySet", "Heap memory", "/JVM/MxBeans/memory/type/Heap memory", "max", "value");
units = DmsUtil.getMetricUnits(DmsUtil.locateSensor("JVM_MemorySet", "Heap memory",
               "/JVM/MxBeans/memory/type/Heap memory", "max"), "value");

maxHeap > heapThreshold;

「評価」をクリックします。ツールから次のレスポンスが返されます:

サンプル・レスポンス

Variables Created
{heapThreshold=1500000.0, maxHeap=1864192, units=KB}
Exceptions and Returned Values
result:true

テスト・スクリプトの例

次の例は、その他のヘルス・テスト・スクリプトであり、エバリュエータ・ツールでサポートされる様々な関数を示しています:

例11-1 ユーザー・ログインの失敗

次の例は、システムの状態をテストするスクリプトです。指定された期間内のユーザー・ログインの失敗数を測定し、結果を返します。2分30秒以内のユーザー・ログインの90%を超えるログインが失敗した場合は、速やかな対処が必要な可能性のある問題がシステムにあると考えられます。

このスクリプトは、演算関数MathUtil.doCount()を使用して、ユーザー認証リクエストと失敗の数をカウントします。演算関数の詳細は、エバリュエータ・ツールのヘルプを参照してください。

/*
User Login Failure
*/
//Number of User login requests, when the test becomes effective
requestsThreshold = 100;
//Number of user login failures, in percentage
failedThreshold = 90;
//Free percentage averaged over two minutes and 30 seconds window
reqWinSize = 150000;  //2.5 * 60 * 1000;

windowSize = MathUtil.getAveWindowSize("LoginFailure","failed");
if (windowSize > reqWinSize) {
  MathUtil.setAveWindowSize("LoginFailure","failed", reqWinSize);
  windowSize = MathUtil.getAveWindowSize("LoginFailure","failed");
};

windowSize = MathUtil.getAveWindowSize("LoginFailure","users");
if (windowSize < reqWinSize) {
  MathUtil.setAveWindowSize("LoginFailure","users", reqWinSize);
  windowSize = MathUtil.getAveWindowSize("LoginFailure","users");
};
//Count of user authentications
MathUtil.doCount("LoginFailure","failed",DmsUtil.getMetricValue("OAMS.OAM_UserIdentityProvider", "UserIdentityProvider", "/OAMS/OAM/UserIdentityProvider", "authenticateUserFailure", "count"));
failed = MathUtil.getCount("LoginFailure","failed");

//Count of user authentication requests
MathUtil.doCount("LoginFailure","users",DmsUtil.getMetricValue("OAMS.OAM_UserIdentityProvider", "UserIdentityProvider", "/OAMS/OAM/UserIdentityProvider", "authenticateUser", "count"));

//The computed value of the count from MathUtil.doCount retrieved and assigned to this variable. This ensures the script does not hang, if the count takes longer duration to compute.
requests = MathUtil.getCount("LoginFailure","users");

//Always returns true if the number of requests are less than 100.
result = requests < requestsThreshold || failed/requests*100 < failedThreshold;
if (requests > requestsThreshold) {
  ScriptUtil.removeVariable("requestsThreshold");
};
ScriptUtil.removeVariable("reqWinSize");
result;

サンプル・レスポンス

Variables Created
{failed=0.0, failedThreshold=90.0, requests=0.0, requestsThreshold=100.0, result=true, windowSize=150000.0}
Exceptions and Returned Values
result:true

例11-2 ディレクトリの停止

次の例は、指定されたしきい値範囲のログ・メッセージをカウントするもので、ディレクトリの停止が発生したかどうかを確認するために使用できます。さらにその結果を使用して、管理サーバーのヘルス・モニタリングで警告を生成できます。

このスクリプトでは、ログ関数LogsUtil.recordLogMessage()およびLogsUtil.setLogOccurrencesWindow()を使用します。また、ScriptUtil.removeVariable()関数を使用して中間変数refidを削除します。ログ関数の詳細は、エバリュエータ・ツールの「ヘルプ」を参照してください。

/*
Directory outages are detected based on LIBOVD-40067 messages that are issued every minute.
*/
//set a reference to the log message when it happens
refid = LogsUtil.recordLogMessage("oracle.ods.virtualization.engine.backend.jndi.adapter1", "LIBOVD-40067");
//set a window size, using the reference id of the log message
windowSize = LogsUtil.getLogOccurrencesWindow(refid);
if (windowSize > 180000.0) {
  LogsUtil.setLogOccurrencesWindow(refid, 180000.0);
  windowSize = LogsUtil.getLogOccurrencesWindow(refid);
};

//count the number of log occurences
count = LogsUtil.getLogOccurrences(refid);
ScriptUtil.removeVariable("refid");
count < 0.5;

サンプル・レスポンス

Variables Created
{count=0.0, windowSize=180000.0}
Exceptions and Returned Values
result:true