REST APIログ収集の設定

Oracle Log Analyticsを使用すると、ログ・メッセージで応答するエンドポイントURLから、継続的なREST APIベースのログ収集を設定できます。REST APIログ・ソースは、リクエストで指定された時間枠内に生成されたログ・メッセージで応答するAPIで構成する必要があります。

これは、環境、プラットフォーム、またはOCIサービス、Fusion Apps、ERPアプリケーションなどのアプリケーション、またはAPIを介してログを生成するその他のアプリケーションからの継続的なログ収集を自動化する場合に推奨される方法です。ソース定義で使用できるマクロは、ログ収集の開始元のログ時間を指定したり、ログ・エンドポイントのページ結果に対してデータを反復および収集するオフセットを指定したり、収集ウィンドウまたは時間枠でログを収集するために使用できます。

REST APIソースを使用して、HTTPまたはHTTPSを介してSOAP APIからログを収集することもできます。SOAP APIの場合、POSTエンドポイントをSOAP XMLペイロードで構成し、application/xmlまたはAPIに必要なコンテンツ・タイプを使用し、XMLパーサーまたはサブパーサー設定を使用してSOAPレスポンスからログ・レコードを抽出します。

REST APIベースのソースを使用してログを収集するための全体的なフロー

次に、REST APIベースのソースを介してログ情報を収集するための大まかなタスクを示します。

  • エンドポイント・サーバーへのhttpまたはhttpsアクセス権を持つホストに管理エージェントをインストールします。管理エージェントを使用した連続ログ収集の設定を参照してください。

  • 管理エージェントとREST APIソース間の接続を認可するには、まずエージェントの資格証明ストアでAPI資格証明を構成します。「管理エージェントのソース資格証明」を参照してください。
  • ログ出力ホストを表すエンティティをOracle Log Analyticsに作成します。「ログ出力リソースを表すエンティティの作成」を参照してください。

  • APIからのレスポンスとして指定されたログ・エントリを処理するための適切なパーサーを作成します。パーサーの作成を参照してください。

    SOAP APIの場合:

    • SOAPレスポンスにログ・フィールドが直接含まれる場合は、XMLパーサーを使用します。
    • SOAPレスポンスに、BI Publisher reportBytesなどのエンコードおよび圧縮されたコンテンツが含まれている場合は、抽出されたコンテンツを解析する前に、XMLフィールドをマップし、Base64 decodeBase64 decode and unzipなどのサブパーサー・アクションを構成します。
  • REST APIエンドポイントを定義して、REST APIソースを作成します。REST APIソースの作成を参照してください

  • エンティティをソースに関連付けます。新しいソースとエンティティのアソシエーションの構成を参照してください。

Fusion Applications監査ログの取込みのエンドツーエンド・フローについては、Fusion Applications監査ログの取込みを参照してください。

ノート

SOAP APIコレクションでは、次の側面を考慮する必要があります。

  • pdfまたは圧縮されたpdf形式のコンテンツはサポートされていません。
  • チャンク・レポートの取得および再アセンブリはサポートされていません。
  • XMLネームスペース処理では、SOAPレスポンスに応じて、パーサーのignore namespaceオプションまたはネームスペースに依存しないXPathの使用が必要になる場合があります。

REST APIソースの作成

Oracle Log Analyticsには、REST APIログ収集用のOracle定義のログ・ソースがすでに用意されています。使用可能なOracle定義REST APIソースまたはOracle定義パーサーを使用できるかどうかを確認します。そうでない場合は、次のステップを使用して新しいログ・ソースを作成します。

開始する前に、ログに適した新しいパーサーを作成する必要がある場合は、完了します。パーサーの作成を参照してください。

  1. ナビゲーション・メニューを開き、「オブザーバビリティおよび管理」をクリックします。「Log Analytics」で、「管理」をクリックします。

    管理リソースが、左側のナビゲーション・ペインにある「管理」の下にリストされます。「ソース」をクリックします。

  2. 「ソース」ページが開きます。「ソースの作成」をクリックします。

    「ソースの作成」ダイアログ・ボックスが表示されます。

  3. 「名前」フィールドに、ログ・ソースの名前を入力します。

  4. 「ソース・タイプ」リストから、「REST API」を選択します。

  5. 「エンティティ・タイプ」をクリックし、アプリケーションを最も適切に識別するタイプを選択します。

  6. 「パーサー」をクリックし、収集するログのタイプに適したパーサーを選択します。

  7. 「エンドポイント」タブで、エンドポイントを実行する必要がある順序で追加します。「ログ・エンドポイントの追加」をクリックして、「ログ」エンドポイントまたは「初期化」エンドポイントを追加します。1つのエンドポイントがアイテムのリストを返し、子ログ・エンドポイントが各アイテムの詳細を収集する必要がある場合は、複数のログに対して「複数のログのリスト・エンドポイントの追加」をクリックします。

    ログイン、セッション・トークンの取得、コンテナ作成などの設定コールには、「初期化」を使用します。初期化エンドポイント・レスポンスは、後のエンドポイントで参照できますが、ログ・レコードとして収集されません。Initializationエンドポイントを、レスポンス値を使用するエンドポイントの前に配置します。HTTP Cookieは、後続のエンドポイントに渡されます。

    • 単一のエンドポイントを指定するには、「ログ・エンドポイントの追加」をクリックします。「ログ・エンドポイントの追加」ダイアログ・ボックスが開きます。

      次の情報を入力します:

      1. ログ・エンドポイント・タイプを選択します:

        • エンドポイント・レスポンスに収集するログ・レコードが含まれる場合は、「ログ」を選択します。
        • 「初期化」は、エンドポイントがセッション・トークンなどの値を後で取得するときに選択します。HTTP Cookieは、後続のエンドポイントに渡されます。
          ノート

          ワークフロー内の他のエンドポイントの実行中に使用できるように、取得した値(セッション・トークンなど)を保存してください。
      2. ログ・エンドポイント名を入力します。

      3. 定期的にログを収集するログURLを構築します。エンドポイントのタイプログ・エンドポイントURLを参照してください。

      4. APIメソッドGETまたはPOSTを選択します。

        POSTを選択した場合は、POSTペイロードを入力し、APIで必要なリクエスト・コンテンツ・タイプをapplication/jsontext/plaintext/javascripttext/htmlまたはapplication/xmlから指定します。SOAP APIの場合、POSTペイロードにSOAPエンベロープを入力し、エンドポイントで必要なコンテンツ・タイプapplication/xmlを使用します。POSTペイロードでUSERNAME/PASSWORDマクロを使用するには、USERNAMEおよびPASSWORDマクロを参照してください。

      5. オプションで、ログ・プロキシ・サーバーURLを指定します。

      6. オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。

      7. オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。

      8. 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。

        POSTペイロードにUSERNAMEまたはPASSWORDが含まれている場合は、「資格証明」セクションでUSERNAME/PASSWORDマクロの資格証明名を指定します。管理エージェントは、これらのマクロを収集時に選択した資格証明の値に置き換えます。

      9. 入力した構成情報を検証するには、「検証」をクリックします。エラーがある場合は、それらを修正します。

        「変更の保存」をクリックします。

    • JSONまたはXMLレスポンスを返すエンドポイントに、複数のログ・エンドポイント・リクエストの生成に使用される情報を指定するには、「複数のログのリスト・エンドポイントの追加」をクリックします。「複数ログのリスト・エンドポイントの追加」ダイアログ・ボックスが開きます。

      1. 「リスト・エンドポイントの構成」タブ:

        • 「ログ・リスト・エンドポイント名」を入力します。

        • ログ・リストURLを構築して、ログ・ファイルに関する情報を取得します。エンドポイントのタイプログ・リスト・エンドポイントURLを参照してください。例:

          https://example.org/fetchlogfiles_data
        • オプションで、ログ・プロキシ・サーバーURLを指定します。

        • APIメソッドGETまたはPOSTを選択します。

          POSTを選択した場合は、POSTペイロードを入力し、APIで必要なリクエスト・コンテンツ・タイプをapplication/jsontext/plaintext/javascripttext/htmlまたはapplication/xmlから指定します。SOAP APIの場合、POSTペイロードにSOAPエンベロープを入力し、エンドポイントで必要なコンテンツ・タイプapplication/xmlを使用します。POSTペイロードでUSERNAME/PASSWORDマクロを使用するには、USERNAMEおよびPASSWORDマクロを参照してください。

          次のXMLペイロードの例は、初期化エンドポイントから抽出されたセッション・トークンの使用を示しています。

          <sessionToken>{getSessionToken:/Envelope/Body/loginResponse/loginResult}</sessionToken>
        • オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。

        • オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。

        • 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。

          POSTペイロードに{USERNAME}または{PASSWORD}が含まれている場合は、「資格証明」セクションでUSERNAME/PASSWORDマクロの資格証明名を指定します。管理エージェントは、これらのマクロを収集時に選択した資格証明の値に置き換えます。

        • 「次」をクリックします。

      2. 「ログ・エンドポイントの構成」タブ:

        • ログ・リスト・エンドポイントのサンプル・レスポンスを指定します。JSONレスポンスの場合は、JSONPath変数を使用します。XMLまたはSOAPレスポンスの場合は、XPath変数を使用します。

          これは、前のタブで指定したログ・リスト・エンドポイントに対して取得するレスポンスのJSONの例です。例:

          { "totalSize": 4, "records": [ {"id": "firstId", "type": "firstType"}, {"id": "secondId", "type": "secondType"} ] }

          前述の例から、エンドポイントURLでJSONパスrecords[*].idを使用できます。JSONパス変数の詳細は、REST APIログ収集の変数を参照してください。

          これは、SOAPのXMLの例です。

          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://example.oracle.com/">
            <soapenv:Body>
              <ns:getItemsResponse>
                <ns:getItemsResult>
                  <ns:string>Widget</ns:string>
                  <ns:string>Gadget</ns:string>
                </ns:getItemsResult>
              </ns:getItemsResponse>
            </soapenv:Body>
          </soapenv:Envelope>

          XPath変数の例:

          {getItems_ListEndpoint:/Envelope/Body/getItemsResponse/getItemsResult/string}
        • ログ・エンドポイント名を入力します。

        • リスト・エンドポイント・レスポンスの変数を組み込んで、ログURL、リクエスト・ヘッダー、フォーム・パラメータまたはPOSTペイロードを構築します。JSONPathはJSONレスポンスに使用し、XPathはXMLまたはSOAPレスポンスに使用します。エンドポイントのタイプログ・エンドポイントURLを参照してください。例:

          https://example.org/fetchLogs?time={START_TIME}&id={testLogListEP:$.records[*].id}
        • APIメソッドGETまたはPOSTを選択します。

          POSTを選択した場合は、POSTペイロードを入力し、APIで必要なリクエスト・コンテンツ・タイプをapplication/jsontext/plaintext/javascripttext/htmlまたはapplication/xmlから指定します。SOAP APIの場合、POSTペイロードにSOAPエンベロープを入力し、エンドポイントで必要なコンテンツ・タイプapplication/xmlを使用します。

          このログ・エンドポイント・ペイロードは、以前の初期化エンドポイント値とリスト・エンドポイントからの現在のアイテムの両方を参照できます。

          セッション・トークンおよびリスト・エンドポイントを参照するPOSTコールのXMLペイロードの例:

          <ns:getItemDetail>
            <ns:sessionToken>{getSessionToken:/Envelope/Body/loginResponse/loginResult}</ns:sessionToken>
            <ns:itemName>{getItems_ListEndpoint:/Envelope/Body/getItemsResponse/getItemsResult/string}</ns:itemName>
          </ns:getItemDetail>
        • オプションで、ログ・プロキシ・サーバーURLを指定します。

        • オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。

        • オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。

        • 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。

        • 「次」をクリックします。

      3. 「確認および追加」タブ: 前のタブで指定した構成情報が検証されます。ログの収集元となるURLのリストを確認します。

        エラーがある場合は、それらを修正します。

        初期化エンドポイントが、それらを参照するエンドポイントの前に表示され、各ログ・リスト・エンドポイントに、レコードを収集する子ログ・エンドポイントがあることを確認します。

        「保存」をクリックします。

  8. 「ソースの作成」をクリックします。

エンドポイントのタイプ

ログ・リスト・エンドポイント: REST APIログ・ソースの作成時に「複数のログのリスト・エンドポイントの追加」をクリックすると、アイテムのリストを返すログ・リスト・エンドポイントを指定できます。ログ・リスト・エンドポイントは、JSONPath for JSONおよびXPath for XMLを使用して、JSONまたはXMLレスポンスを返す必要があります。JSONPathまたはXPathを使用して、ログを収集するログ・エンドポイントURLのリストを作成できます。レスポンスからログ・エンドポイントのリストを作成するために必要な変数を指定します。また、マクロ{START_TIME}および{CURR_TIME}を使用して、対応する時間値をURLに動的に挿入できます。

ログ・エンドポイント: REST APIログ・ソースの作成時に「ログ・エンドポイントの追加」をクリックすると、2つのタイプのログ・エンドポイントのいずれかを追加できます。ログ・エンドポイント・タイプは、次の2つの「初期化」および「ログ」のいずれかです。初期化エンドポイントは、セッション・トークンなどの値を後でエンドポイント用に取得します。初期化エンドポイントでは、ログ・レコードは抽出されません。レスポンスの要素は、後続のエンドポイントで使用できます。ログ・エンドポイントは、特定のREST APIエンドポイントからのログを定期的に収集するために使用されます。マクロ{START_TIME}{CURR_TIME}および{TIME_WINDOW}を使用して、対応する時間値をURLに動的に挿入できます。{OFFSET}マクロを使用すると、ページ区切りをサポートできます。ログ・リスト・エンドポイント・コールのレスポンスからJSONパス変数を使用して、特定のプロパティを置換することもできます。

  • {START_TIME}: ログを収集する時間を指定します。
  • {OFFSET}: ページ区切りログ収集を処理するため
  • {CURR_TIME}: 現在の時刻を指定します。
  • {TIME_WINDOW}: コレクションの間隔または期間を指定します。
  • {USERNAME}および{PASSWORD}: POSTペイロードでユーザー名とパスワードの値を必要とするSOAP APIの場合。管理エージェントは、収集時に構成された資格証明の値でマクロを置換します。

マクロの使用の詳細は、START_TIMEマクロCURR_TIMEマクロOFFSETマクロおよびTIME_WINDOWマクロを参照してください。

ログ・エンドポイントURLで指定できるログ・リスト・エンドポイント・レスポンスからの変数の使用、JSONPathおよびXPathの例、および変数フィルタの使用の詳細は、REST APIログ収集の変数を参照してください。

START_TIMEマクロ

START_TIMEマクロを使用して、ログを収集する必要がある時間を指定します。START_TIMEマクロは、エンドポイントURL、フォーム・パラメータまたはPOSTペイロードで使用できます。

次の例は、START_TIMEマクロで指定されたタイムスタンプより大きいログを収集するエンドポイントURLを示しています。

https://example.org/fetchLogs?sortBy=timestamp&sortOrder=ascending&filter=timestamp+gt+{START_TIME:yyyy-MM-dd'T'HH:mm:ss.SSSZ}

構文:

{START_TIME<+nX>:<epoch | timestamp format supported by SimpleDateFormat java class>.TZ=<timezone name>}
  • nは、日付範囲の時間値です。Xは、日数(D)、時間数(h)、分数(m)、月数(M)、年(Y)で表されます。

  • +nXは、開始時間に追加する日数、時間数、分数、月数または年数です。オプションです。たとえば、+3Dです。

  • サポートされている時間形式は、javaクラスSimpleDateFormatと同じです。デフォルトの時間書式はyyyy-MM-dd'T'HH:mm:ss.SSSZです。たとえば、2001-07-04T12:08:56.235-0700のようになります。

    epochまたは時間書式の指定はオプションです。エポックが指定されている場合、マクロはエポックミリ秒値に置き換えられます。

    SimpleDateFormatでサポートされているタイムスタンプ書式については、Java Platform Standard Ed. 8: Class SimpleDateFormatを参照してください。

  • TZは、タイムスタンプのタイムゾーンを指定するためのものです。エポックがすでに指定されている場合は適用されません。サポートされている形式は、javaクラスTimeZoneの3文字のID (UTCなど)と同じです。

  • このマクロの複数のインスタンスをURLに含めることができます。

  • 例:

    1. {START_TIME:yyyy-MM-dd'T'HH:mm:ss.SSS.TZ=UTC}
    2. {START_TIME:epoch}

START_TIMEマクロの値は、次のいずれかの方法で決定されます。

  • エンドポイントのコレクションが初めて開始される場合、START_TIMEは、エージェント・コレクション・プロパティ「履歴データ」に基づく履歴日です。このプロパティのデフォルト値は30 daysです。つまり、タイムスタンプの値は現在のタイムスタンプの30日前です。

  • パーサーで「時間」フィールドが設定されている場合、後続のログ・コレクションでは、START_TIMEの値は、前のログ・コレクションで抽出されたタイムスタンプ値の最大値です。

  • 「時間」フィールドをパーサーで設定してログ・レコードから抽出しない場合、現在のタイムスタンプはSTART_TIMEの値になります。

APIにフィルタがある場合は、greater thanのかわりにgreater than equal toを使用して、同じタイムスタンプを持つすべてのログ・レコードがアップロードされるようにします。

CURR_TIMEマクロ

CURR_TIMEマクロを使用して、REST APIエンドポイントURL、フォーム・パラメータおよびPOSTペイロードに現在の時刻を挿入します。

次の例は、問合せパラメータでCURR_TIMEマクロを使用するエンドポイントURLを示しています。

https://example.org/fetchLogs?sortBy=timestamp&sortOrder=ascending&time={CURR_TIME:yyyy-MM-dd'T'HH:mm:ss.SSSZ}
  • マクロを使用する形式は、START_TIMEマクロと同じです。

  • このマクロの複数のインスタンスをURLに含めることができます。

OFFSETマクロ

OFFSETマクロは、ページ区切りレスポンスを提供するエンドポイント、またはAPIレスポンスのオフセット動作を処理する場合に使用します。OFFSETマクロは、REST APIエンドポイントURL、フォーム・パラメータおよびPOSTペイロードで使用して、単一のログ収集サイクルで複数のページまたはチャンクをフェッチできます。

フォーマット: {OFFSET(<start value>, <increment>)}

  • OFFSETマクロは、特定のログ・エンドポイントのページ区切り結果に関するデータを反復的にコールおよび収集して、使用可能なすべてのレコードを取得するために使用されます。最初のREST APIリクエスト・コールは、開始値で始まり、後続の各コールで増分の値によって増分されます。これらの再帰的な索引ベース・コールは、ログ・エントリがこれ以上見つからない場合に停止されます。オフセットは、次の収集サイクルに繰り越されません。各収集サイクルのデフォルト値または初期値から開始します。

  • 前述の形式では、開始値が索引の初期値で、デフォルト値は0です。開始値を指定することはオプションです。

    使用可能な値: 0を含む正の整数

  • 前述の形式では、incrementは後続のコールで開始値に追加する値を指定します。デフォルト値は1です。増分値を指定することはオプションです。

    使用可能な値: 正の整数のみ。0を除外します。

  • URLには、このマクロのインスタンスを1つのみ含めることができます。

次の例は、OFFSETマクロの様々な使用方法を示しています。

  • {OFFSET}

    デフォルト値の開始値 = 0、増分 = 1を使用します。

  • {OFFSET(5)}

    開始値 = 5、増分 = 1 (デフォルト)

  • {OFFSET(5,2)}

    開始値 = 5、増分 = 2

次の例は、OFFSETマクロを使用するエンドポイントURLを示しています。

https://example.org/fetchLogs?startIndex={OFFSET(0,1000)}&count=1000

前述の例で、OFFSET(0,1000)は、最初のコールで開始値が0になり、後続のコールで1000ずつ増加することを示します。したがって、OFFSETマクロが解釈される場合、複数のコールのエンドポイントURLは次のようになります。

最初のコール: https://example.org/fetchLogs?startIndex=0&count=1000

2回目のコール: https://example.org/fetchLogs?startIndex=1000&count=1000

TIME_WINDOWマクロ

TIME_WINDOWマクロを使用して、ログを収集する収集間隔を指定します。REST APIエンドポイントURLで使用すると、エージェント収集間隔に関係なく、分、時間または日数でログをフェッチできます。たとえば、時間ウィンドウが1d (1日)で、エージェント間隔が10分の場合、後続のログ収集は1日後にのみ実行されます。

次の例では、エンドポイントURLでTIME_WINDOW6hとして指定して、ログ収集間隔を6時間に設定します。

https://example.org/fetchLogs?timewindow={TIME_WINDOW(6h)}

フォーマット: {TIME_WINDOW(<number><timeunit>)}

前述の形式:

  • number: ゼロより大きい数字。

  • timeunit: 時間の場合はh、日の場合はd、分の場合はm。デフォルト値はd (日)です。

エージェント収集間隔が指定された時間ウィンドウより小さいことを確認してください。TIME_WINDOWマクロは、エンドポイントで1回のみ使用できます。

USERNAMEとPASSWORDマクロ

POSTペイロードでユーザー名とパスワードの値を必要とするSOAP APIの場合、SOAP XMLエンベロープに{USERNAME}および{PASSWORD}を入力します。いずれかのマクロが存在する場合は、エンドポイントの「資格証明」セクションでUSERNAME/PASSWORDマクロの資格証明名を指定します。管理エージェントは、収集時に構成された資格証明の値でマクロを置換します。

これは、エンドポイント・レベルのBasic認証またはトークン認証とは別です。

ノート

SOAP APIでユーザー名とパスワードが必要な場合は、POSTペイロードにマクロ{USERNAME}および{PASSWORD}のみを含める必要があります。マクロをユーザー名とパスワードの実際の値に置き換えることはできません。値は、構成された資格証明から収集されます。

前述のマクロを含むPOSTコールのSOAP XMLペイロードの例:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://example.oracle.com/">
  <soapenv:Header/>
  <soapenv:Body>
    <ns:login>
      <ns:username>{USERNAME}</ns:username>
      <ns:password>{PASSWORD}</ns:password>
    </ns:login>
  </soapenv:Body>
</soapenv:Envelope>

REST APIログ収集の変数

変数を使用して、前のエンドポイント・レスポンスの値を、実行時に後のエンドポイント・リクエストに置換します。変数は、URL、フォーム・パラメータ、POSTペイロードまたはHTTPリクエスト・ヘッダーの値で使用できます。RESTレスポンスの場合は、JSONPath式を使用します。XMLまたはSOAPレスポンスの場合は、XPath式を使用します。

エンドポイント・リクエストが以前のエンドポイントの値に依存し、以前のエンドポイントで障害が発生した場合、依存エンドポイントはコールされず、その依存エンドポイントからログ・メッセージは収集されません。

後のエンドポイントでの変数の形式:

{<endpoint_name>:<JSONPath or XPath expression>}

JSONレスポンスの場合は、JSONPath式($.records[*].idなど)を使用します。XMLまたはSOAPレスポンスの場合は、/Envelope/Body/loginResponse/loginResultなどのXPath式を使用します。

  • 前述の形式では、endpoint_nameは、レスポンスが値を提供する以前のエンドポイントの名前です。SOAPフローの場合、これは、ログイン・エンドポイントやログ・リスト・エンドポイントなどの初期化エンドポイントになります。

    JSONPath式の場合、フィルタ(<filter_field_name>=<value>)はオプションです。filter_field_nameに一致する属性のみがJSONレスポンスから取得され、後のエンドポイントで使用されます。例:

    https://www.example.com/log/{foo:$.items[*].links[*].href(rel='self')}

    フィルタの詳細な例は、JSONPathフィルタの例を参照してください。

    XPATH式の例は、「SOAP/XPATHの例」を参照してください。

  • JSONおよびXMLレスポンス・コンテンツを使用して、変数値をフェッチできます。JSONPathはJSONレスポンスに使用し、XPathはXMLまたはSOAPレスポンスに使用します。

  • 同じ変数を複数回指定できます。

  • 変数は、後続のエンドポイント値に対して有効なソースである以前のエンドポイントを参照できます。セッション・トークンなどの設定値には、初期化エンドポイントを使用します。子ログ・エンドポイント・リクエストを駆動する値には、ログ・リスト・エンドポイントを使用します。

  • サポートされているJSONパス形式は、Simple JSONPathArray JSONPathおよびMultiple-array JSONPathです。

  • XMLネームスペースを使用するSOAPレスポンスの場合は、XMLパーサーおよびエンドポイント変数リゾルバでサポートされているXPath形式を使用します。パーサーまたは変数リゾルバがネームスペースを無視するように構成されている場合は、ネームスペース接頭辞なしでXPathを記述します。

シンプルなJSONPath

JSONレスポンスに複数のレベルのネストされた要素がある場合、JSONパスをノードの特別な表記として指定し、その後続の子ノードへの接続を指定できます。

次の例では、JSONパス$.foo.abcを使用して、出力としてresultを取得します。

{
    "foo" : 
    {
        "abc" : "result"
    }
}

次の例では、JSONパス$.*.idを使用して["id1", "id3"]出力を取得するか、$.*.*を使用して出力["id1", "id2", "id3"]を取得します。

{
    "foo" : {
        "id" : "id1"
    },
    "foo2" : {
        "ID" : "id2",
        "id" : "id3"
    }
}

次の例では、JSONパス$.foo.*を使用して出力["id1", "value1"]を取得します。

{
    "foo" : {
        "id" : "id1",
        "abcd" : "value1"
    },
    "foo2" : {
        "id" : "id2"
    }
}

配列JSONPath

JSONレスポンスにデータの抽出元となるオブジェクトの配列がある場合は、配列オブジェクトの名前を指定し、[]を使用してその配列オブジェクト内の適切な要素を抽出します。たとえば、次のJSONレスポンスには、オブジェクトrecordsitemの2つの配列があります。

{
     "records": [
         {"id": "firstId", "type":"firstType"},
         {"id":"secondId", "type":"secondType"}
     ],
     "items": [
         {"name":"firstName", "field":"value"},
         {"name":"secondName", "field":"value"},
         {"name":"thirdName", "field":"value"}
     ]
}
  • JSONパス$.records[0].idを指定して出力としてfirstIdをフェッチし、$.records[1].idを指定して出力としてsecondIdをフェッチするか、$.records[*].idを指定してすべてのJSONオブジェクトからidをフェッチします。最後のケースでは、出力は文字列["firstId", "secondId"]のリストです。

  • ()を使用して、JSONパスに条件を指定することもできます。前述の例では、typefirstTypeであるrecordsからのみidをフェッチするには、JSONパス$.records[*].id(type='firstType')を使用します。

複数配列JSONPath

次の例を考えます:

ログ・リスト・エンドポイントURL getlistの場合:

https://www.example.com/url_list

ログ・リスト・エンドポイントに対するJSONレスポンス:

{
  "records": [ { "id": "firstId", "type": "firstType" }, { "id": "secondId", "type": "secondType" } ],
  "items": [ { "name": "firstName", "field": "value" }, { "name": "secondName", "field": "value" }, { "name": "thirdName", "field": "value" } ]
}

ログ・エンドポイントURL (getlistの変数を参照):

https://www.example.com/{getlist:$.records[*].id}/{getlist:$.items[*].name}

変数{getlist:$.records[*].id}および{getlist:$.items[*].name}を使用すると、エージェントは、2つの配列フィールド["firstId", "secondId"]および["firstName", "secondName", "thirdName"]のすべての組合せを持つ次のログ・エンドポイントを生成します。

  • https://www.example.com/firstId/firstName

  • https://www.example.com/secondId/firstName

  • https://www.example.com/firstId/secondName

  • https://www.example.com/secondId/secondName

  • https://www.example.com/firstId/thirdName

  • https://www.example.com/secondId/thirdName

JSONPathフィルタの例

ログ・リスト・エンドポイントfooからの次のJSONレスポンスについて考えてみます。

{
    "items": [
        {
            "BusinessEventCode": "JournalBatchApproved",
            "CreationDate": "2019-07-27T17:19:19.261+00:00",
            "links": [
                {
                    "rel": "self",
                    "href": "/erpBusinessEvents/self/100100120766717"
                },
                {
                    "rel": "canonical",
                    "href": "/erpBusinessEvents/rel/100100120766717"
                }
            ]
        }
    ]
}

次に、次のログ・エンドポイントの例を考えてみます。

https://www.example.com/log/{foo:$.items[*].links[*].href(rel='self')}

前述の例では、パス・パラメータは、ログ・リスト・エンドポイントfooのJSONレスポンスの配列要素$.items[*].links[*].hrefに置き換えられ、rel='self'のみを選択するための追加条件が指定されています。

前述のJSONレスポンスの場合、エージェントは次のログ・エンドポイントを生成します:

https://www.example.com/log/erpBusinessEvents/self/100100120766717

SOAP/XPathの例

XPath式は、以前のエンドポイントがXMLまたはSOAP XMLを返す場合に使用します。

  • 初期化エンドポイント・レスポンスの例:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://example.oracle.com/">
      <soapenv:Body>
        <ns:loginResponse>
          <ns:loginResult>abc123</ns:loginResult>
        </ns:loginResponse>
      </soapenv:Body>
    </soapenv:Envelope>
  • 後のエンドポイントPOSTペイロードで使用される変数の例:

    <ns:sessionToken>{getSessionToken:/Envelope/Body/loginResponse/loginResult}</ns:sessionToken>
  • ログ・リスト・エンドポイント・レスポンスの例:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://example.oracle.com/">
      <soapenv:Body>
        <ns:getItemsResponse>
          <ns:getItemsResult>
            <ns:string>Widget</ns:string>
            <ns:string>Gadget</ns:string>
          </ns:getItemsResult>
        </ns:getItemsResponse>
      </soapenv:Body>
    </soapenv:Envelope>
  • 子ログ・エンドポイントPOSTペイロードの例:

    <ns:getItemDetail>
      <ns:sessionToken>{getSessionToken:/Envelope/Body/loginResponse/loginResult}</ns:sessionToken>
      <ns:itemName>{getItems_ListEndpoint:/Envelope/Body/getItemsResponse/getItemsResult/string}</ns:itemName>
    </ns:getItemDetail>

REST APIログ・コレクションの資格証明タイプの選択

エージェントとREST APIソース間の接続を認可するには、まずエージェントの資格証明ストアでAPI資格証明を構成します。エージェント側の管理エージェント・サービスでソース資格証明を構成した後、REST APIログ・ソースの作成時にこの情報を使用できます。

管理エージェントがログ発行ホストからデータを収集できるように、管理エージェント・サービスのソース資格証明を構成するには、管理エージェントのソース資格証明を参照してください。

ログ・エンドポイントまたはログ・リスト・エンドポイントを追加するときに、「ログ資格証明タイプ」を選択して、ワークフローに資格証明情報を指定します。次のいずれかのオプションを選択します。

  • なし
  • 基本認証: 管理エージェント・サービスで作成した資格証明のログ資格証明名を指定します。
  • 静的トークン: 管理エージェント・サービスで作成した資格証明のログ資格証明名を指定します。
  • 動的トークン(OAuth 2.0):

    管理エージェント・サービスで作成したトークンのトークン資格証明名を指定します。また、「トークン・エンドポイント名」「トークン・エンドポイントURL」「付与タイプ」、およびオプションで「スコープ」などのトークン情報を指定します。

    トークン・プロキシがログ・エンドポイントと同じ場合は、「ログ・エンドポイントと同じプロキシ」チェック・ボックスを有効にしたままにします。そうでない場合は、チェック・ボックスを無効にし、「トークン・プロキシ・サーバーのURL」を指定します。

認証タイプへの資格証明タイプのマッピング:

認証タイプ 管理エージェントの資格証明タイプ 資格証明プロパティ
基本認証 HTTPSBasicAuthCreds HTTPSUserName, HTTPSPassword
HTTPSCreds HTTPSUserName、HTTPSPassword、sslトラストストアのプロパティ
静的トークン HTTPSTokenCreds HTTPSToken、HTTPSTokenType、sslトラストストア・プロパティ(オプション)
動的トークン HTTPSBasicAuthCreds HTTPSUserName, HTTPSPassword
HTTPSCreds HTTPSUserName、HTTPSPassword、sslトラストストアのプロパティ

sslトラストストアのプロパティには、次の情報が含まれています。

  • "ssl_trustStoreType": ストアのタイプ(たとえば、JKS)。

  • "ssl_trustStoreLocation": トラスト・ストアのパス

  • "ssl_trustStorePassword": トラスト・ストアのパスワード(オプション)

資格証明JSONの属性に関する次の点に注意してください:

  • source: 値はlacollector.la_rest_apiである必要があります

  • name: 次のいずれかの形式の資格証明に適した名前。

    • <cred_name>.<entity_name>: エンティティ名を持つ資格証明名
    • <cred name>: 資格証明名のみ

    エージェントは、最初の形式で名前を検索します。見つからない場合は、2番目の形式で名前が検索されます。

  • type: これは、前述の資格証明タイプ表の「管理エージェントでの資格証明タイプ」列で指定されている値のいずれかである必要があります。

資格証明JSONの例を参照してください。

資格証明JSONの例

信頼できるホストでのHTTPSを介したユーザー名とパスワードを使用したBasic認証の例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSBasicAuthCreds",
  "description":"These are HTTPS (BasicAuth) credentials.",
  "properties":
  [
    { "name":"HTTPSUserName", "value":"CLEAR[admin]" },
    { "name":"HTTPSPassword", "value":"CLEAR[myHTTPSPassword]" }
  ]
}

SSL証明書、ユーザー名およびHTTPSを介したパスワードを含むBasic認証の例(証明書を明示的に指定):

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSCreds",
  "description":"These are HTTPS (BasicAuth) credentials.",
  "properties":
  [
    { "name":"HTTPSUserName", "value":"CLEAR[admin]" },
    { "name":"HTTPSPassword", "value":"CLEAR[myHTTPSPassword]" },
    { "name":"ssl_trustStoreType", "value":"JKS" },
    { "name":"ssl_trustStoreLocation", "value":"/scratch/certs/mycert.keystore" },
    { "name":"ssl_trustStorePassword", "value":"mySSLPassword" }
  ]
}

信頼できるホストを使用したHTTPS経由のトークンの例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSTokenCreds",
  "description":"These are HTTPS (Token) credentials.",
  "properties":
  [
    { "name": "HTTPSToken", "value": "CLEAR[token value]" },
    {"name": "HTTPSTokenType", "value": "CLEAR[Bearer]" }
  ]
}

明示的に指定された証明書を使用したHTTPS経由のトークンの例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSTokenCreds",
  "description":"These are HTTPS (Token) credentials.",
  "properties":
  [
    { "name": "HTTPSToken", "value": "CLEAR[token value]" },
    {"name": "HTTPSTokenType", "value": "CLEAR[Bearer]" },
    { "name":"ssl_trustStoreType", "value":"JKS" },
    { "name":"ssl_trustStoreLocation", "value":"/scratch/certs/mycert.keystore" },
    { "name":"ssl_trustStorePassword", "value":"mySSLPassword" }
  ]
}

Fusion Applications監査ログの取込み

Fusion Applications監査ログを収集するには、次のステップに従います。Fusion Applicationsで使用可能なOracle定義ソースのリストは、Oracle定義ソースを参照してください。

トピック:

前提条件

  • Fusion Applications監査ログAPIの理解: 監査ログAPIの使用方法および機能の詳細は、Fusion Applications REST APIのドキュメントを参照してください。

  • Fusion Applicationsへのアクセス: Fusion Applicationsインスタンスにアクセスするには、有効な資格証明および権限が必要です。

  • 次のエンドポイントおよびプロキシを識別します(オプション)。:

    • login_url: Fusion ApplicationsインスタンスのベースURL
    • pod_url: Fusion ApplicationsインスタンスのベースURL
    • proxy_url: (オプション)プロキシ・サーバーにリクエストを送信するURL

    URLの詳細は、Doc ID 2661308.1 in Oracle My Supportを参照してください。

  • Fusion Applications REST APIアクセス: APIアクセスが有効で、必要なロール/権限が割り当てられていることを確認します。

Fusion Applicationsからの監査ログ収集の設定

  1. Fusion ApplicationsのベースURLの検証:

    • ユーザー・インタフェースにログインして、Fusion Applications資格証明を検証します。
    • オプションで、ネットワーク・トレース・コールを分析してベースURLを検証します。
    • 監査APIアクセスが有効になっていることを確認します。
  2. 必要なIAMポリシーの作成: 管理エージェントを使用した継続的なログ収集の許可

  3. Fusion Applicationsインスタンス/サーバーへのhttpまたはhttpsアクセス権を持つホストに管理エージェントをインストールします。インストール中にLog Analyticsプラグインがデプロイされていることを確認します。管理エージェントのインストールを参照してください。

  4. エージェントの資格証明ストアでAPI資格証明を構成します:

    /binディレクトリの場所は、管理エージェントのデプロイ方法によって異なります。

    • Oracle Cloud Agentプラグインを介してコンピュート・インスタンスで実行されている管理エージェントの場合、スクリプトは/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/binにあります。

    • 手動でインストールした管理エージェントの場合、スクリプトは/opt/oracle/mgmt_agent/agent_inst/binにあります。

    資格証明JSONファイルを作成するには、設定に適した/binディレクトリに移動します。次の例は、fapps.jsonファイルに指定されている値を示しています。

    {
          "source": "lacollector.la_rest_api",
          "name": "FA-CREDS",
          "type": "HTTPSBasicAuthCreds",
          "description": "These are HTTPS (BasicAuth) credentials.",
          "properties": [
              {
                  "name": "HTTPSUserName",
                  "value": "USER"
              },
              {
                  "name": "HTTPSPassword",
                  "value": "PASS"
              }
          ]
      }

    FA-CREDS資格証明をエージェントの資格証明ストアに追加します:

    cat fapps.json | ./credential_mgmt.sh -s logan -o upsertCredentials

    エージェントの資格証明ストアでのAPI資格証明の構成の詳細は、管理エージェント・ソース資格証明を参照してください。

  5. エージェントがインストールされているインスタンスからFusion Applications APIエンドポイントに到達できるかどうかを確認します。curlなどのツールを使用してチェックを実行できます。

  6. エンティティの作成: Oracle Fusion Applications型のエンティティを作成し、login_urlおよびpod_urlのプロパティ値を追加します。必要に応じて、proxy_urlの値も追加します。「ログ出力リソースを表すエンティティの作成」を参照してください。

  7. ソースの構成: 使用できる適切なFusion Applications監査ログのOracle定義ソースを識別します。必要に応じて、既存のソースの複製を作成して編集できます。ソースの編集を参照してください。

    • 資格証明がソースのログ・エンドポイントで正しく参照されていることを確認します。
    • 必要に応じて、ログ・エンドポイントにプロキシを追加します。
  8. エージェント側でのデータ収集のスケジュール: ソースをエンティティに関連付けて、データ収集をスケジュールします。管理エージェントを使用して、Fusion Applications監査APIを定期的に起動し、データをLog Analyticsにプッシュします。新しいソースとエンティティのアソシエーションの構成を参照してください。

  9. ログ・エクスプローラでの確認および検証: ログ・エクスプローラでログが収集され、適切に分析されていることを確認します。チャートおよびコントロールを使用したデータのビジュアル化を参照してください。