REST APIログ収集の設定
Oracle Log Analyticsを使用すると、ログ・メッセージで応答するエンドポイントURLから、継続的なREST APIベースのログ収集を設定できます。REST APIログ・ソースは、リクエストで指定された時間枠内に生成されたログ・メッセージで応答するAPIで構成する必要があります。
これは、環境、プラットフォーム、またはOCIサービス、Fusion Apps、ERPアプリケーションなどのアプリケーション、またはAPIを介してログを生成するその他のアプリケーションからの継続的なログ収集を自動化する場合に推奨される方法です。ソース定義で使用できるマクロは、ログ収集の開始元のログ時間を指定したり、ログ・エンドポイントのページ結果に対してデータを反復および収集するオフセットを指定したり、収集ウィンドウまたは時間枠でログを収集するために使用できます。
REST APIベースのソースを使用してログを収集するための全体的なフロー
次に、REST APIベースのソースを介してログ情報を収集するための大まかなタスクを示します。
-
エンドポイント・サーバーへのhttpまたはhttpsアクセス権を持つホストに管理エージェントをインストールします。ホストからの継続的なログ収集の設定を参照してください。
- 管理エージェントとREST APIソース間の接続を認可するには、まずエージェントの資格証明ストアでAPI資格証明を構成します。「管理エージェントのソース資格証明」を参照してください。
-
ログ出力ホストを表すエンティティをOracle Log Analyticsに作成します。「ログ出力リソースを表すエンティティの作成」を参照してください。
-
APIからのレスポンスとして指定されたログ・エントリを処理するための適切なパーサーを作成します。パーサーの作成を参照してください。
-
REST APIエンドポイントを定義して、REST APIソースを作成します。REST APIソースの作成を参照してください
-
エンティティをソースに関連付けます。新しいソースとエンティティのアソシエーションの構成を参照してください。
Fusion Applications監査ログの取込みのエンドツーエンド・フローについては、Fusion Applications監査ログの取込みを参照してください。
REST APIソースの作成
Oracle Log Analyticsには、REST APIログ収集用のOracle定義のログ・ソースがすでに用意されています。使用可能なOracle定義REST APIソースまたはOracle定義パーサーを使用できるかどうかを確認します。そうでない場合は、次のステップを使用して新しいログ・ソースを作成します。
開始する前に、ログに適した新しいパーサーを作成する必要がある場合は、完了します。パーサーの作成を参照してください。
-
ナビゲーション・メニューを開き、「監視および管理」をクリックします。「Log Analytics」で、「管理」をクリックします。「管理の概要」ページが開きます。
管理リソースが、左側のナビゲーション・ペインの「リソース」の下にリストされます。「ソース」をクリックします。
-
「ソース」ページが開きます。「ソースの作成」をクリックします。
「ソースの作成」ダイアログ・ボックスが表示されます。
-
「名前」フィールドに、ログ・ソースの名前を入力します。
-
「ソース・タイプ」リストから、「REST API」を選択します。
-
「エンティティ・タイプ」をクリックし、アプリケーションを最も適切に識別するタイプを選択します。
-
「パーサー」をクリックし、収集するログのタイプに適したパーサーを選択します。
-
要件に応じて、「エンドポイント」タブで、「ログ・エンドポイントの追加」または「複数のログのリスト・エンドポイントの追加」をクリックします:
-
ログを継続的に収集できる単一のログ・エンドポイントURLを指定するには、「ログ・エンドポイントの追加」をクリックします。「ログ・エンドポイントの追加」ダイアログ・ボックスが開きます。
次の情報を入力します:
-
ログ・エンドポイント名を入力します。
-
ログURLを作成して、ログを定期的に収集します。エンドポイントURLのタイプのログ・エンドポイントURLを参照してください。
-
APIメソッドGETまたはPOSTを選択します。
「POST」を選択した場合は、メソッドの「POSTペイロード」を入力し、
JSON
、Text
、Javascript
、HTML
およびXML
からリクエスト・コンテンツのタイプを選択します。 -
オプションで、ログ・プロキシ・サーバーURLを指定します。
-
オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。
-
オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。
-
「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。
-
入力した構成情報を検証するには、「検証」をクリックします。エラーがある場合は、それらを修正します。
「変更の保存」をクリックします。
-
-
複数のログを収集するためのログ・エンドポイントURLのリストの生成に使用できる情報を含むJSONレスポンスを返すURLを指定するには、「複数のログのリスト・エンドポイントの追加」をクリックします。「複数ログのリスト・エンドポイントの追加」ダイアログ・ボックスが開きます。
-
「リスト・エンドポイントの構成」タブ:
-
「ログ・リスト・エンドポイント名」を入力します。
-
ログ・リストURLを作成して、ログ・ファイルに関する情報を取得します。エンドポイントURLのタイプのログ・リスト・エンドポイントURLを参照してください。例:
https://example.org/fetchlogfiles_data
-
オプションで、ログ・プロキシ・サーバーURLを指定します。
-
APIメソッドGETまたはPOSTを選択します。
「POST」を選択した場合は、メソッドの「POSTペイロード」を入力し、
JSON
、Text
、Javascript
、HTML
およびXML
からリクエスト・コンテンツのタイプを選択します。 -
オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。
-
オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。
-
「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。
-
「次」をクリックします。
-
-
「ログ・エンドポイントの構成」タブ:
-
ログ・リスト・エンドポイントのサンプル・レスポンスを指定します。これは、前のタブで指定したログ・リスト・エンドポイントに対して取得するレスポンスの例です。例:
{ "totalSize": 4, "records": [ {"id": "firstId", "type": "firstType"}, {"id": "secondId", "type": "secondType"} ] }
前述の例から、JSONパス
records[*].id
をエンドポイントURLで使用できます。JSONパス変数の詳細は、REST APIログ収集の変数を参照してください。 -
ログ・エンドポイント名を入力します。
-
ログURLを構築し、ログ・リスト・エンドポイントに対するレスポンス例で識別されるJSONパス・キーを組み込むことで、定期的にログを収集します。エンドポイントURLのタイプのログ・エンドポイントURLを参照してください。例:
https://example.org/fetchLogs?time={START_TIME}&id={testLogListEP:$.records[*].id}
-
オプションで、ログ・プロキシ・サーバーURLを指定します。
-
APIメソッドGETまたはPOSTを選択します。
「POST」を選択した場合は、メソッドの「POSTペイロード」を入力し、
JSON
、Text
、Javascript
、HTML
およびXML
からリクエスト・コンテンツのタイプを選択します。 -
オプションで、ログ・プロキシ・サーバーURLを指定します。
-
オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式でリクエスト・ヘッダーを指定します。
-
オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」から「値」のペアの形式で問合せパラメータを指定します。
-
「資格証明」セクションで、「ログ資格証明タイプ」を選択します。「REST APIログ収集の資格証明タイプの選択」を参照してください。
-
「次」をクリックします。
-
-
「確認および追加」タブ: 前のタブで指定した構成情報が検証されます。ログの収集元となるURLのリストを確認します。
エラーがある場合は、それらを修正します。
「保存」をクリックします。
-
-
-
「ソースの作成」をクリックします。
エンドポイントURLのタイプ
ログ・リスト・エンドポイントURL: ログ・リスト・エンドポイントURLは、ログを収集するためのログ・エンドポイントURLのリストの作成に使用できる情報を含むJSONレスポンスを返す必要があります。JSONレスポンスからログ・エンドポイントのリストを作成するために必要なJSONパス変数を指定します。また、マクロ{START_TIME}
および{CURR_TIME}
を使用して、対応する時間値をURLに動的に挿入できます。
ログ・エンドポイントURL: ログ・エンドポイントURLは、特定のREST APIエンドポイントから定期的にログを収集するために使用されます。マクロ{START_TIME}
、{CURR_TIME}
および{TIME_WINDOW}
を使用すると、対応する時間値をURLに動的に挿入できます。{OFFSET}
マクロを使用すると、ページ区切りをサポートできます。ログ・リスト・エンドポイント・コールのレスポンスからのJSONパス変数を使用して、特定のプロパティを置換することもできます。
{START_TIME}
: ログを収集する時間を指定します。{OFFSET}
: ページ区切りログ収集を処理するため{CURR_TIME}
: 現在の時刻を指定します。{TIME_WINDOW}
: コレクションの間隔または期間を指定します。
マクロの使用の詳細は、START_TIMEマクロ、CURR_TIMEマクロ、OFFSETマクロおよびTIME_WINDOWマクロを参照してください。
ログ・エンドポイントURLで指定できるログ・リスト・エンドポイント・レスポンスの変数、JSONパスの例および変数フィルタの使用の詳細は、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に含めることができます。
-
例:
{START_TIME:yyyy-MM-dd'T'HH:mm:ss.SSS.TZ=UTC}
{START_TIME:epoch}
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_WINDOW
を6h
として指定して、ログ収集間隔を6時間に設定します。
https://example.org/fetchLogs?timewindow={TIME_WINDOW(6h)}
フォーマット: {TIME_WINDOW(<number><timeunit>)}
前述の形式:
-
number: ゼロより大きい数字。
-
timeunit: 時間の場合は
h
、日の場合はd
、分の場合はm
。デフォルト値はd
(日)です。
エージェント収集間隔が指定された時間ウィンドウより小さいことを確認してください。TIME_WINDOW
マクロは、エンドポイントで1回のみ使用できます。
REST APIログ収集の変数
変数を使用して、ログ・リスト・エンドポイントによってレスポンスの一部として提供される属性を、実行時に動的にログ・エンドポイントのリクエストに置換します。変数は、URL、フォーム・パラメータ、POSTペイロードまたはログ・エンドポイントのHTTPリクエスト・ヘッダー値で使用できます。
ログ・リスト・エンドポイントへのコールが失敗した場合、依存関係のためにログ・エンドポイントからのログ・メッセージは収集されません。
ログ・エンドポイントの変数の形式:
{<log_list_endpoint_name>:<json path(<filter_field_name>='<value>')>}
-
前述の形式では、
log_list_endpoint_name
はログ・リスト・エンドポイントの名前です。フィルタ
(<filter_field_name>=<value>)
はオプションです。filter_field_name
に一致する属性のみが、ログ・リスト・エンドポイントのJSONレスポンスから取得され、ログ・エンドポイントで使用されます。例:https://www.example.com/log/{foo:$.items[*].links[*].href(rel='self')}
フィルタの詳細な例は、フィルタの例を参照してください。
-
プロパティ値のフェッチには、JSONコンテンツ・タイプのみがサポートされています。
-
同じ変数を複数回指定できます。
-
変数は有効なリスト・エンドポイントのみを参照でき、ログ・エンドポイントは参照できません。
-
次のJSONパス形式がサポートされています: 単純なJSONパス、配列JSONパスおよび複数の配列JSONパス。
単純なJSONパス
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"
}
}
配列JSONパス
JSONレスポンスにデータの抽出元となるオブジェクトの配列がある場合は、配列オブジェクトの名前を指定し、[]
を使用してその配列オブジェクト内の適切な要素を抽出します。たとえば、次のJSONレスポンスには、オブジェクトrecords
とitem
の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パスに条件を指定することもできます。前述の例では、type
がfirstType
であるrecords
からのみid
をフェッチするには、JSONパス$.records[*].id(type='firstType')
を使用します。
複数配列JSONパス
次の例を考えます:
ログ・リスト・エンドポイント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
フィルタの例
ログ・リスト・エンドポイント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
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
: 資格証明に適した名前 -
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インスタンスのベースURLpod_url
: Fusion ApplicationsインスタンスのベースURLproxy_url
: (オプション)プロキシ・サーバーにリクエストを送信するURL
URLの詳細は、Doc ID 2661308.1 in Oracle My Supportを参照してください。
- Fusion Applications REST APIアクセス: APIアクセスが有効で、必要なロール/権限が割り当てられていることを確認します。
Fusion Applicationsからの監査ログ収集の設定
-
Fusion ApplicationsのベースURLの検証:
- ユーザー・インタフェースにログインして、Fusion Applications資格証明を検証します。
- オプションで、ネットワーク・トレース・コールを分析してベースURLを検証します。
- 監査APIアクセスが有効になっていることを確認します。
-
必要なIAMポリシーの作成: 管理エージェントを使用した継続的なログ収集の許可
-
Fusion Applicationsインスタンス/サーバーへのhttpまたはhttpsアクセス権を持つホストに管理エージェントをインストールします。インストール中にLog Analyticsプラグインがデプロイされていることを確認します。管理エージェントのインストールを参照してください。
-
エージェントの資格証明ストアでAPI資格証明を構成します:
管理エージェントの/binフォルダに移動し、資格証明JSONファイルを作成します。次の例は、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資格証明の構成の詳細は、管理エージェント・ソース資格証明を参照してください。
-
エージェントがインストールされているインスタンスからFusion Applications APIエンドポイントに到達できるかどうかを確認します。curlなどのツールを使用してチェックを実行できます。
-
エンティティの作成:
Oracle Fusion Applications
型のエンティティを作成し、login_url
およびpod_url
のプロパティ値を追加します。必要に応じて、proxy_url
の値も追加します。「ログ出力リソースを表すエンティティの作成」を参照してください。 -
ソースの構成: 使用できる適切なFusion Applications監査ログのOracle定義ソースを識別します。必要に応じて、既存のソースの複製を作成して編集できます。ソースの編集を参照してください。
- 資格証明がソースのログ・エンドポイントで正しく参照されていることを確認します。
- 必要に応じて、ログ・エンドポイントにプロキシを追加します。
-
エージェント側でのデータ収集のスケジュール: ソースをエンティティに関連付けて、データ収集をスケジュールします。管理エージェントを使用して、Fusion Applications監査APIを定期的に起動し、データをLog Analyticsにプッシュします。新しいソースとエンティティのアソシエーションの構成を参照してください。
-
ログ・エクスプローラでの確認および検証: ログ・エクスプローラでログが収集され、適切に分析されていることを確認します。チャートおよびコントロールを使用したデータのビジュアル化を参照してください。