このファンクションでは、ログ・ファイルのヘッダーのフィールドでログ・エントリをエンリッチできます。このファンクションは、ヘッダーとして本文のブロックが含まれ、その本文にエントリが含まれるログで特に役立ちます。

このファンクションは、ヘッダー・ログ・エントリのフィールドでログ本文の各エントリをエンリッチします。データベース・トレース・ファイルは、このようなログの例の1つです。

時間ベースの本文ログ・エントリをエンリッチするためのヘッダーおよび対応するフィールドを取得するには、パーサーの作成時に、「ファンクションの追加」ダイアログ・ボックスで対応する「ヘッダー・コンテンツ・パーサー」を選択します。

正規表現ヘッダー・コンテンツ・パーサーの例:

• これらのタイプのログでは、ヘッダーは通常、ログ・ファイルの先頭部分のどこかに出現し、その後に他のエントリが続きます。次を参照してください:

  Trace file /scratch/emga/DB1212/diag/rdbms/lxr1212/lxr1212_1/trace/lxr1212_1_ora_5071.trc
  Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
  With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
  Advanced Analytics and Real Application Testing options
  ORACLE_HOME = /scratch/emga/DB1212/dbh
  System name:    Linux
  Node name:  slc00drj
  Release:    2.6.18-308.4.1.0.1.el5xen
  Version:    #1 SMP Tue Apr 17 16:41:30 EDT 2012
  Machine:    x86_64
  VM name:    Xen Version: 3.4 (PVM)
  Instance name: lxr1212_1
  Redo thread mounted by this instance: 1
  Oracle process number: 35
  Unix process pid: 5071, image: oracle@slc00drj (TNS V1-V3)
   
  *** 2020-10-12 21:12:06.169
  *** SESSION ID:(355.19953) 2020-10-12 21:12:06.169
  *** CLIENT ID:() 2020-10-12 21:12:06.169
  *** SERVICE NAME:(SYS$USERS) 2020-10-12 21:12:06.169
  *** MODULE NAME:(sqlplus@slc00drj (TNS V1-V3)) 2020-10-12 21:12:06.169
  *** CLIENT DRIVER:() 2020-10-12 21:12:06.169
  *** ACTION NAME:() 2020-10-12 21:12:06.169
    
  2020-10-12 21:12:06.169: [    GPNP]clsgpnp_dbmsGetItem_profile: [at clsgpnp_dbms.c:345] Result: (0) CLSGPNP_OK. (:GPNP00401:)got ASM-Profile.Mode='legacy'
  *** CLIENT DRIVER:(SQL*PLUS) 2020-10-12 21:12:06.290
    
  SERVER COMPONENT id=UTLRP_BGN: timestamp=2020-10-12 21:12:06
  *** 2020-10-12 21:12:10.078
  SERVER COMPONENT id=UTLRP_END: timestamp=2020-10-12 21:12:10
  *** 2020-10-12 21:12:39.209
  KJHA:2phase clscrs_flag:840 instSid:
  KJHA:2phase ctx 2 clscrs_flag:840 instSid:lxr1212_1
  KJHA:2phase clscrs_flag:840 dbname:
  KJHA:2phase ctx 2 clscrs_flag:840 dbname:lxr1212
  KJHA:2phase WARNING!!! Instance:lxr1212_1 of kspins type:1 does not support 2 phase CRS
  *** 2020-10-12 21:12:39.222
  Stopping background process SMCO
  *** 2020-10-12 21:12:40.220
  ksimdel: READY status 5
  *** 2020-10-12 21:12:47.628
  
  ...
  
  KJHA:2phase WARNING!!! Instance:lxr1212_1 of kspins type:1 does not support 2 phase CRS

  前述の例で、ヘッダー詳細ファンクションを使用すると、Oracle Logging Analyticsによって時間ベースの本文ログ・エントリがヘッダー・コンテンツのフィールドでエンリッチされます。

• 次のログの例を参照してください:

  Server: prodsrv123
  Application: OrderAppA
   
  2020-08-01 23:02:43 INFO DataLifecycle Starting backup process
  2020-08-01 23:02:43 ERROR OrderModule Order failed due to transaction timeout
  2020-08-01 23:02:43 INFO DataLifecycle Backup process completed. Status=success
  2020-08-01 23:02:43 WARN OrderModule Order completed with warnings: inventory on backorder
  

  前述の例で、Oracle Logging Analyticsに取得する必要があるログ・エントリは4つです。サーバー名とアプリケーション名は、ログ・ファイルの先頭にのみ出現します。サーバー名とアプリケーション名を各ログ・エントリに含めるには:

  1. サーバー・フィールドとアプリケーション・フィールドを解析するヘッダー用のパーサーを定義します: Server:\s*(\S+).*?Application:\s*(\S+)

  2. ログの残りの本文を解析する2番目のパーサーを定義します: {TIMEDATE}\s(\S+)\s(\S+)\s(.*)

  3. 本文パーサーにヘッダー詳細ファンクション・インスタンスを追加し、ステップ1で定義したヘッダー・パーサーを選択します。

  4. ステップ2で定義した本文パーサーをログ・ソースに追加し、ログ・ソースをエンティティに関連付けてログ収集を開始します。

  これで、各エントリにサーバー名とアプリケーション名が追加された4つのログ・エントリを取得できます。

JSONヘッダー・コンテンツ・パーサーの例:

次に、ヘッダー詳細の様々なケースの例を示します。詳細ログ・エントリは、ヘッダー・ログ・エントリのフィールドでエンリッチされます。エンリッチされた詳細ログ・エントリの強調表示されたフィールドは、ヘッダー・ログ・エントリからコピーされたフィールドです。

• JSON PATH: ヘッダー= $、詳細= $.data

  {
    "id" : "id_ERROR1",
    "data": {
    "id" : "id_data_ERROR1",
     "childblock0": {
        "src": "127.0.0.1"
      },
      "childblocks": [
        {
          "childblock": {
            "srchost1": "host1_ERROR1"
          }
        },
        {
          "childblock": {
            "srchost2": "host2_ERROR1"
          }
        }
      ],
      "hdr": {
        "time_ms": "2021-05-21T04:27:18.89714589Z",
        "error": "hdr_ERROR1"
      }
    },
    "compartmentName": "comp_name_ERROR1",
    "eventName": "GetBucket_ERROR1"
  }

  抽出およびエンリッチされたログ・エントリ:

  ヘッダー・ログ・エントリ: {"id":"id_ERROR1","compartmentName":"comp_name_ERROR1","eventName":"GetBucket_ERROR1"}

  詳細ログ・エントリ: {"compartmentName":"comp_name_ERROR1","eventName":"GetBucket_ERROR1", "id": "id_data_ERROR1", "childblock0":{"src":"127.0.0.1"},"childblocks":[{"childblock":{"srchost1":"host1_ERROR1"}},{"childblock":{"srchost2":"host2_ERROR1"}}],"hdr":{"time_ms":"2021-05-21T04:27:18.89714589Z","error":"hdr_ERROR1"}}

  idフィールドは、ヘッダーと詳細の両方で使用できます。この場合、詳細のフィールドが選択されます。

• JSON PATH: ヘッダー= $.metadata、詳細= $.datapoints[*]

  この例では、1つ目のブロックにはヘッダーと詳細の両方がありますが、2つ目のブロックには詳細ログ・エントリのみが含まれています。

  {
     "namespace":"oci_streaming",
     "resourceGroup":null,
     "name":"GetMessagesThroughput.Count1",
     "dimensions":{
        "region":"phx1",
        "resourceId":"ocid1.stream.oc1.phx.1"
     },
     "datapoints":[
        {
           "timestamp":1652942170000,
           "value":1.1,
           "count":11
        },
        {
           "timestamp":1652942171001,
           "value":1.2,
           "count":12
        }
     ],
     "metadata":{
        "displayName":"Get Messages 1",
        "unit":"count1"
     }
  }
  {
     "namespace":"oci_streaming",
     "resourceGroup":null,
     "name":"GetMessagesThroughput.Count1",
     "dimensions":{
        "region":"phx1",
        "resourceId":"ocid1.stream.oc1.phx.1"
     },
     "datapoints":[
        {
           "timestamp":1652942170002,
           "value":2.1,
           "count":21
        },
        {
           "timestamp":1652942171003,
           "value":3.2,
           "count":32
        }
     ]
  }

  抽出およびエンリッチされたログ・エントリ:

  ヘッダー・ログ・エントリ: {"displayName":"Get Messages 1","unit":"count1"}

  詳細ログ・エントリ: {"displayName":"Get Messages 1","unit":"count1", "timestamp":1652942170000,"value":1.1,"count":11}

  詳細ログ・エントリ: {"displayName":"Get Messages 1","unit":"count1", "timestamp":1652942171001,"value":1.2,"count":12}

  詳細ログ・エントリ: {"timestamp":1652942170002,"value":2.1,"count":21}

  詳細ログ・エントリ: {"timestamp":1652942171003,"value":3.2,"count":32}

• JSON PATH: ヘッダー= $.instanceHealths:[*]、詳細= $.instanceHealths[*].instanceHealthChecks[*]

  {
    "reportType": "Health Status Report 1",
    "instanceHealths": [
      {
        "instanceHealthChecks": [
          {
            "HealthCheckName": "Check-A1",
            "Result": "Passed",
            "time": "2022-11-17T06:05:01Z"
          },
          {
            "HealthCheckName": "Check-A2",
            "Result": "Passed",
            "time": "2022-11-17T06:05:01Z"
          }
        ],
        "Datacenter-A" : "Remote A"
      }
    ]
  }

  抽出およびエンリッチされたログ・エントリ:

  ヘッダー・ログ・エントリ: {"Datacenter-A":"Remote A"}

  詳細ログ・エントリ: {"Datacenter-A":"Remote A", "HealthCheckName":"Check-A1","Result":"Passed","time":"2022-11-17T06:05:01Z"}

  詳細ログ・エントリ: {"Datacenter-A":"Remote A", "HealthCheckName":"Check-A2","Result":"Passed","time":"2022-11-17T06:05:01Z"}

• JSON PATH: Header1 = $.dimensions、Header2 = $.metadata、詳細= $.datapoints[*]

  この例では、2つの異なるヘッダーが適用されます。

  {
     "namespace":"oci_streaming",
     "resourceGroup":null,
     "name":"GetMessagesThroughput.Count1",
     "dimensions":{
        "region":"phx1",
        "resourceId":"ocid1.stream.oc1.phx.1"
     },
     "datapoints":[
        {
           "timestamp":1652942170000,
           "value":1.1,
           "count":11
        },
        {
           "timestamp":1652942171001,
           "value":1.2,
           "count":12
        }
     ],
     "metadata":{
        "displayName":"Get Messages 1",
        "unit":"count1"
     }
  }

  抽出およびエンリッチされたログ・エントリ:

  Header1ログ・エントリ: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1"}

  Header2ログ・エントリ: {"displayName":"Get Messages 1","unit":"count1"}

  詳細ログ・エントリ: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1", displayName":"Get Messages 1","unit":"count1", "timestamp":1652942170000,"value":1.1,"count":11}

  詳細ログ・エントリ: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1", displayName":"Get Messages 1","unit":"count1", "timestamp":1652942171001,"value":1.2,"count":12}

• JSON PATH: Header1 = $.hdr1、Header2 = $.hdr2、詳細= $.body

  この場合、両方が同じブロック内にある場合、ヘッダー・ログ・エントリは詳細ログ・エントリに関連付けられます。

  {
      "hdr1": {
          "module": "mod1",
           "error": "hdr1_error1"
      }
  }
  {
      "body": {        
          "id": "data_id_ERROR2",
           "error": "body_ERROR2"
      }
  }
  {
      "hdr2": {
  
          "module": "mod3",
          "error": "hdr2_error3"
      }
      "body": {        
          "id": "data_id_ERROR4",
          "error": "body_ERROR4"
      }
  }

  抽出およびエンリッチされたログ・エントリ:

  ヘッダー・ログ・エントリ: {"id":"data_id_ERROR1","error":"hdr1_error1"}

  詳細ログ・エントリ: {"id":"data_id_ERROR2","error":"body_ERROR2"}

  ヘッダー・ログ・エントリ: {"module":"mod3","error":"hdr2_error3"}

  詳細ログ・エントリ: {"module":"mod3", "id":"data_id_ERROR4","error":"body_ERROR4"}

  2番目の詳細ログ・エントリでは、ヘッダーおよび詳細で同じ要素が使用可能な場合、詳細からerrorの値が選択されます。

• JSON PATH: ヘッダー= $、Details1 = $.JDBC、Details2 = $.THREADS

  この場合、単一のヘッダー・ログ・エントリが複数の詳細ログ・エントリに関連付けられます。

  {
    "time": "2024-09-10T00:20:00",
    "instance": "GBOSBMXR1PR",
    "name": "gbosbmxr1pr_server_2",
    "JDBC": [
      {  "name":"XXAlsGoldXADS",
  	"Status": "Running",
  	"Url": "jdbc:oracle:thin:@PSOAPR1"
      }
    ],
    "THREADS": [
      {  "name": "[HOGGING][ACTIVE] ExecuteThread 56 ",
  	"WORKMGR": "OneWayJTACoordinatorWM",
  	"CATEGORY": "Internal", "APPNAME": "None"
      }
    ]
  }

  抽出およびエンリッチされたログ・エントリ:

  ヘッダー・ログ・エントリ(次の詳細ログ・エントリに適用): { "time": "2024-09-10T00:20:00", "instance": "GBOSBMXR1PR", "name": "gbosbmxr1pr_server_2" }

  詳細ログ・エントリ: { "name":"XXAlsGoldXADS", "Status": "Running", "Url": "jdbc:oracle:thin:@PSOAPR1" }

  詳細ログ・エントリ: { "name": "[HOGGING][ACTIVE] ExecuteThread 56 ", "WORKMGR": "OneWayJTACoordinatorWM", "CATEGORY": "Internal", "APPNAME": "None" }

このファンクションでは、ログ行からテキストを抽出し、指定したパターンに基づいて条件付きでそのテキストを他のログ行に追加できます。たとえば、この機能を使用して、欠落しているタイムスタンプをMySQLの一般クエリー・ログとスロー・クエリー・ログに追加できます。

検索/置換ファンクションには、次の属性があります:

• 捕捉正規表現: すべてのログ行に一致した正規表現と、一致した正規表現の名前付きグループ・テキストが、置換式で使用するためにメモリーに保存されます。

  • 捕捉式が行全体と一致する場合、置換式は後続のログ行に適用されません。これは、欠落している行を先頭に追加する場合に、同じ行を2回使用しないためです。

  • 捕捉式に一致した行は、検出式では処理されません。そのため、検索/置換操作は同じログ行では実行できません。

  • 名前が異なる複数のグループを指定できます。

• 検出正規表現: この正規表現は、ログ行の捕捉式の名前付きグループで一致するテキストに置き換えるテキストを指定します。

  • 一致パターンはグループ化する必要があります。

  • 検出式は、捕捉式に一致した行では実行されません。そのため、検索/置換操作は同じログ行では実行できません。

  • 検出式には複数のグループを指定できます。各グループの一致テキストは、置換式によって作成されたテキストに置き換えられます。

• 置換正規表現: このカスタム表記は、検出式で検出されたグループを置き換えるテキストを示します。グループ名はカッコで囲む必要があります。

  • グループ名はカッコで囲む必要があります。

  • 静的テキストを含めることができます。

  • 置換式によって作成されたテキストは、検出式のすべてのグループの一致テキストを置き換えます。

フィールド「捕捉正規表現」、「検出正規表現」および「置換正規表現」の横にある「ヘルプ」アイコンをクリックすると、フィールドの説明、サンプル式、サンプル・コンテンツ、および実行されるアクションが表示されます。別の捕捉式を追加するには、「捕捉正規表現」で「式の追加」をクリックします。

例:

• この例の目的は、テキスト# Time:を含むログ行からタイムスタンプを取得し、タイムスタンプのない# User@Hostから始まるログ行に追加することです。

  次のログ・データを考えます:

  # Time: 160201 1:55:58 
  # User@Host: root[root] @ localhost [] Id: 1
  # Query_time: 0.001320 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
  select @@version_comment limit 1;
  # User@Host: root[root] @ localhost [] Id: 2
  # Query_time: 0.000138 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 2
  SET timestamp=1454579783;
  SELECT DATABASE();

  「捕捉正規表現」、「検出正規表現」および「置換正規表現」属性の値は次のようになります:

  • 「捕捉正規表現」の値は、タイムスタンプのログ行と一致し、それをtimestrという名前でメモリーに保存するもので、^(?<timestr>^# Time:.*)です。

  • 「検出正規表現」の値は、タイムスタンプのログ行を先頭に追加する必要がある行を検索するもので、(^)# User@Host:.*です。

  • 「置換正規表現」の値は、タイムスタンプの欠落しているログ行の先頭を置き換えるもので、(timestr)です。

  検索/置換ファンクションを追加した後、ログ行が次のように変更されます:

  # Time: 160201 1:55:58 
  # User@Host: root[root] @ localhost [] Id: 1
  # Query_time: 0.001320 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
  select @@version_comment limit 1;
  # Time: 160201 1:55:58 
  # User@Host: root[root] @ localhost [] Id: 2
  # Query_time: 0.000138 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 2
  SET timestamp=1454579783;
  SELECT DATABASE();

  前述の例の結果で、検索/置換ファンクションによって、ログの前処理中に検出された各ログ行のUser@hostエントリの前にタイムスタンプが挿入されていることがわかります。

• この例の目的は、複数のパラメータを捕捉し、ログ・データの複数の場所で置換することです。

  次のログ・データを考えます:

  160203 21:23:54 Child process "proc1", owner foo, SUCCESS, parent init 
  160203 21:23:54 Child process "proc2" - 
  160203 21:23:54 Child process "proc3" -

  前述のログ行では、2行目と3行目にユーザー・データが含まれていません。そのため、検索/置換ファンクションでは、ログの1行目から値を取得し、2行目と3行目の値を置き換える必要があります。

  「捕捉正規表現」、「検出正規表現」および「置換正規表現」属性の値は次のようになります:

  • 「捕捉正規表現」の値は、最初のログ行からfooおよびinitユーザーの情報を取得し、それをパラメータuser1およびuser2を使用してメモリーに保存するもので、^.*?owner\s+(?<user1>\w+)\s*,\s*.*?parent\s+(?<user2>\w+).*です。

  • 「検出正規表現」の値は、ハイフン文字(-)を含む行を検索するもので、.*?(-).*です。

  • 「置換正規表現」の値は、, owner (user1), UNKNOWN, parent (user2)です。

  検索/置換ファンクションを追加した後、ログ行が次のように変更されます:

  160203 21:23:54 Child process "proc1", owner foo, SUCCESS, parent init 
  160203 21:23:54 Child process "proc2", owner foo, UNKNOWN, parent init 
  160203 21:23:54 Child process "proc3", owner foo, UNKNOWN, parent init

  前述の例の結果で、検索/置換ファンクションによって、ログの前処理中に検出された各ログ行のハイフン文字(-)エントリのかわりに、user1およびuser2の情報が挿入されていることがわかります。

一部のログ・レコードにはタイムスタンプがなく、一部には時間オフセットのみがあり、どちらもないものもあります。Oracle Logging Analyticsは、必要な情報を抽出し、各ログ・レコードにタイムスタンプを割り当てます。

次に、いくつかのシナリオと、時間オフセット・ファンクションを使用してタイムスタンプを割り当てるための対応する解決策を示します:

Process started May 5, 2020 12:34:53 AM
0.0 host1 debug services started
0.5 host1 debug cache populated 
1.4 host1 info connected to cluster
2.7 host1 error cache failure
Process started May 6, 2020 12:36:54 AM
0.1 host1 debug services started
0.4 host1 debug cache populated 
2.1 host1 info connected to cluster
3.4 host1 error cache failure

1 [Startup] Timestamp=0, 
   PName=USER_START, ProcessID=11961, 
   ClientIP=xx.xx.xx.xx, 
   Date=20-MAR-2020 03:35:17, ServerName=host2, 
   Tracegroup=debug    
10 [CLIENT_TIME] Timestamp=1370, Milliseconds=328   
100 [Local_PU.END,6] Timestamp=16000, 
   StartEvent=99, Duration=0

0.0 host1 debug services started
0.5 host1 debug cache populated
1.4 host1 info connected to cluster
2.7 host1 error cache failure 

ログ・エントリの時間オフセットは、前に一致したタイムスタンプが基準になります。このドキュメントでは、このタイムスタンプをベース・タイムスタンプと呼びます。

パーサーの時間オフセット・ファンクションを使用して、ログ・レコードからタイムスタンプおよびタイムスタンプ・オフセットを抽出します。「ファンクションの追加」ダイアログ・ボックスで:

1. タイムスタンプを検索する場所: タイムスタンプを取得する場所を指定するには、「ファイル名」、「ファイルの最終変更時間」および「ログ・エントリ」から選択します。デフォルトでは、「ファイル名」が選択されます。

   これを指定しない場合、タイムスタンプの検索は次の順序で実行されます:

   • ログ・レコード全体を横断し、タイムスタンプ・パーサーとの一致を検索します(次のステップで指定します)。
   • ファイルの最終変更時間をタイムスタンプとして取得します。
   • ファイルの最終変更時間が使用できない場合は、システム時間をタイムスタンプとして選択します。
   • ファイル名でタイムスタンプ式との一致を検索します(次のステップで指定します)。

2. タイムスタンプのソースの選択に基づいて、次の値を指定します:

   • ステップ1で「ファイル名」を選択した場合:

     タイムスタンプ式: 正規表現を指定して、ファイル名のタイムスタンプを検索します。デフォルトでは、{TIMEDATE}ディレクティブが使用されます。

     サンプル・ファイル名: 前述の設定のテストに使用できるサンプル・ログのファイル名を指定します。

   • ステップ1で「ファイルの最終変更時間」を選択した場合、「サンプル・ファイルの最終変更時間」を選択します。

   • ステップ1で「ログ・エントリ」を選択した場合、「タイムスタンプ・パーサー」メニューからパーサーを選択し、タイムスタンプ・フォーマットを指定します。

3. タイムスタンプ・オフセット式: 正規表現を指定して、秒およびミリ秒単位で時間オフセットを抽出し、タイムスタンプをログ・レコードに割り当てます。secおよびmsecグループのみがサポートされます。たとえば、(?<sec>\d+)\.(?<msec>\d+)。

   次のログ・レコードの例を考えます:

   15.225 hostA debug services started

   オフセット式の例では、ログ・レコードから15秒と225ミリ秒が時間オフセットとして取得されます。

4. 前のステップで選択が行われると、ログ・コンテンツが「サンプル・ログ」フィールドに表示されます。

   「テスト」をクリックして、設定をテストします。

   元のログ・コンテンツと、指定に基づいて計算された時間との比較が表示されます。

5. 前述の時間オフセット・ファンクションを保存するには、「追加」をクリックします。