このページでは、イベントサービス 4.5.x から 24.x 以降への移行中に発生するドットフィールドのエラーについて説明します。

移行ログを分析して、移行が失敗した理由を特定します。この問題のトラブルシュート中に部分的なデータ損失が発生する可能性がありますが、推奨されるトラブルシューティング手順に従えば、移行時に重要となるデータを選択できます。

問題

Elasticsearch 2.x と 8.x では、ドット付きのフィールドが含まれるインデックスのマッピングスタイルが異なります。マッピングスタイルは、Elasticsearch 5.x リリースから変更されています。詳細については、「Upgrading fields with dots to 5.x」を参照してください。したがって、移行ユーティリティでドットフィールドの再インデックス化に失敗します。

移行ユーティリティを実行すると、次のエラーで移行が失敗します。

サンプル エラー メッセージ

2024-04-18T19:51:00.177+05:30 ERROR 71165 --- [ main] c.a.a.o.m.m.t.DotFieldIndicesHandlerTask : Execution of DotFieldIndicesHandlerTask has failed. 2024-04-18T19:51:00.177+05:30 ERROR 71165 --- [ main] c.a.a.o.m.s.r.RemoteReindexerServiceImpl : Error while reindexing java.lang.IllegalStateException: Not all accounts & eventTypes have been resolved/rectified, Un-rectified accountEventTypes : [customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1] at com.appdynamics.analytics.onprem.migration.model.tasks.DotFieldIndicesHandlerTask.execute(DotFieldIndicesHandlerTask.java:88) ~[classes!/:24.4.0-18] at com.appdynamics.analytics.onprem.migration.service.reindex.RemoteReindexerServiceImpl.reindex(RemoteReindexerServiceImpl.java:116) ~[classes!/:24.4.0-18] at com.appdynamics.analytics.onprem.MigrationTool.run(MigrationTool.java:105) ~[classes!/:24.4.0-18] at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:771) ~[spring-boot-3.1.1.jar!/:3.1.1] at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:755) ~[spring-boot-3.1.1.jar!/:3.1.1] at org.springframework.boot.SpringApplication.run(SpringApplication.java:319) ~[spring-boot-3.1.1.jar!/:3.1.1] at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:150) ~[spring-boot-3.1.1.jar!/:3.1.1] at com.appdynamics.analytics.onprem.MigrationTool.main(MigrationTool.java:59) ~[classes!/:24.4.0-18] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na] at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na] at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49) ~[analytics-on-prem-es2-es8-migration-24.4.0-18-exec.jar:24.4.0-18] at org.springframework.boot.loader.Launcher.launch(Launcher.java:95) ~[analytics-on-prem-es2-es8-migration-24.4.0-18-exec.jar:24.4.0-18] at org.springframework.boot.loader.Launcher.launch(Launcher.java:58) ~[analytics-on-prem-es2-es8-migration-24.4.0-18-exec.jar:24.4.0-18] at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:65) ~[analytics-on-prem-es2-es8-migration-24.4.0-18-exec.jar:24.4.0-18]
JSON

このエラーは、一部のインデックスが Elasticsearch 2.x から 8.x に移行できないことを示します。

Cause

Elasticsearch 2.x のインデックスのマッピングは、Elasticsearch 8.x とは異なります。次に、Elasticsearch 2.x でのマッピングの例を示します。

例：Elasticsearch 2.x インデックスのマッピング

{ "customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05": { "mappings": { "customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1": { "properties": { "segments": { "type": "nested", "properties": { "userData": { "properties": { "RequestApplicationSecurityToken": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.ApplicationContext": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.AppliesTo": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.NameId": { "type": "string", "index": "not_analyzed" } } } } } } } } } }
JSON

この例で、Elasticsearch 2.x はマッピングをコンパイルし、次の各プロパティを独立したフィールドとして識別します。

  • RequestApplicationSecurityToken

  • RequestApplicationSecurityToken.ApplicationContext

  • RequestApplicationSecurityToken.AppliesTo

  • RequestApplicationSecurityToken.NameId

ただし、Elasticsearch 8.x バージョンでは、マッピングが同じ方法で考慮されません。このバージョンでは、RequestApplicationSecurityToken フィールドが親として識別されます。また、RequestApplicationSecurityToken.* フィールドが子として識別されます。この例では、RequestApplicationSecurityToken.ApplicationContext フィールド、RequestApplicationSecurityToken.AppliesTo フィールド、RequestApplicationSecurityToken.NameId フィールドが子フィールドと見なされます。したがって、移行中にこれらのフィールドのインデックスを再作成すると、失敗します。

Elasticsearch 8.x では、親フィールドに値を設定することができません。親フィールドは nested、object、または properties のいずれかとなります。ただし、Elasticsearch 2.x バージョンでは、同じフィールドに文字列を含めることができました。 

回避策

ドットフィールドのエラーをトラブルシュートするには、次の手順を実行します。

  1. out ディレクトリで問題のあるフィールドがリストされたファイルを特定します。

    ファイルの例

    - out/ProblematicFieldsReport_2024-04-18_19-51-00.json - out/customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05.json
    CODE
  2. /ProblemmaticFieldsReport_2024 ファイルで失敗したインデックスを確認します。

    ファイルの例

    { "customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1" : { "relatedIndices" : [ "customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05" ], "problematicFields" : [ "segments.userData.RequestApplicationSecurityToken", "segments.userData.RequestApplicationSecurityToken.ApplicationContext", "segments.userData.RequestApplicationSecurityToken.AppliesTo", "segments.userData.RequestApplicationSecurityToken.NameId" ] } }
    JSON

    この JSON ファイルには、accountName___eventType がリストされています。各リストには次のエントリがあります。
    • relatedIndices：Elasticsearch 2.x マッピングスタイルが使用されているインデックスのリスト。
    • problematicFields：インデックスに問題のあるフィールドのリスト。

      移行ユーティリティでは、すべての予約済みキーワードを網羅することはできません。そのため、ユーティリティで不明な予約済みキーワードの処理に失敗すると、問題が発生する可能性があります。この問題を解決するには、「Ignore the Reserved Keywords」を参照してください。

  3. Elasticsearch 8.x スタイルに一致するようにマッピングを更新します。

    Elasticsearch 8.x の更新例

    { "mappings" : { "properties" : { "segments" : { "type" : "nested", "properties" : { "userData" : { "properties" : { "RequestApplicationSecurityToken" : { "type" : "keyword", "index" : true }, "RequestApplicationSecurityToken.ApplicationContext" : { "type" : "keyword", "index" : true }, "RequestApplicationSecurityToken.AppliesTo" : { "type" : "keyword", "index" : true }, "RequestApplicationSecurityToken.NameId" : { "type" : "keyword", "index" : true } } } } } } } }
    JSON
  4. マッピングファイルを修正する方法を確認し、決定します。

    親フィールドまたは子フィールドのいずれかのみを保持するようにしてください。移行ユーティリティでは、親フィールドと子フィールドの組み合わせをサポートしていません。

    たとえば、Elasticsearch 2.x に次の構造のデータがあるとします。

    ソースファイルの例

    "_source": { "segments": [ { "userData": { "RequestApplicationSecurityToken": "example_token_value1", "RequestApplicationSecurityToken.ApplicationContext": "example_application_context1", "RequestApplicationSecurityToken.AppliesTo": "example_applies_to1", "RequestApplicationSecurityToken.NameId": "example_name_id1" } } ] }
    JSON
    Elasticsearch 8.x のデータは、ドットフィールドのエラーを修正した後に表示されます。

    親フィールドの削除を選択した場合、Elasticsearch 8.x のデータは次のように表示されます。

    出力例

    "_source": {     "segments": [         {             "userData": {                 "RequestApplicationSecurityToken.ApplicationContext": "example_application_context1",                 "RequestApplicationSecurityToken.AppliesTo": "example_applies_to1",                 "RequestApplicationSecurityToken.NameId": "example_name_id1"             }         }     ] }
    JSON

    子フィールドの削除を選択した場合、Elasticsearch 8.x のデータは次のように表示されます。

    出力例

    "_source": {     "segments": [         {             "userData": {                 "RequestApplicationSecurityToken": "example_token_value1"             }         }     ] }
    JSON



    マッピングファイルの修正方法を決定する前に、データを分析します。
  5. 親フィールドと子フィールドを分析し、ビジネス要件に基づいて復元します。

    業務における親フィールドと子フィールドの重要性を分析する際は、次の点を考慮してください。

    • 移行後に業務にとって重要となるのは、どのタイプのデータか？
    • 将来必要となるのは、どのタイプのデータか？
    • 親フィールドを含むドキュメントはいくつあるか？
    • 子フィールドを含むドキュメントはいくつあるか？

    分析に基づいて、移行後に保持するフィールドと手放すフィールドを決定します。



    GET /customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05/_search { "_source": ["segments.userData.RequestApplicationSecurityToken"] }
    CODE 


    GET /customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05/_search { "_source": ["segments.userData.RequestApplicationSecurityToken.ApplicationContext", "segments.userData.RequestApplicationSecurityToken.AppliesTo", "segments.userData.RequestApplicationSecurityToken.NameId"] }
    CODE


  6. migration config フォルダに excludeFieldsConfig.json ファイルを作成します。このファイルで、無視することに決めたフィールドを指定します。

    excludeFieldsConfig.json のサンプル

    { "customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1": [ "segments.userData.RequestApplicationSecurityToken" ], "accountName___eventType2": [ "excludefield1" ] }
    JSON
  7. migration config/application.yml ファイルで、migration セクションの下に次のプロパティを追加します。
    migration: search_hits: 5000 reindex_concurrency: 4 reindex_scroll_batch_size: 5000 reindex_requests_per_second: 8000 large_rollover_threshold_size_bytes: 60000000000 # 60 GB small_rollover_threshold_size_bytes: 20000000000 # 20 GB required_low_disk_size_watermark: 85 # Exclude Parent of Child fields during migration exclude_fields_config_file_path: "config/excludeFieldsConfig.json"
    CODE
  8. /out ディレクトリを空にして、移行ユーティリティツールを実行します。

予約済みキーワードの削除

移行ユーティリティでは、すべての予約済みキーワードを網羅することはできません。ユーティリティから欠落している予約済みキーワードがある場合は、問題のあるフィールドのレポートでフィールドを分析します。このように欠落しているキーワードを特定し、application.yml ファイルを更新して、移行中はそれらのキーワードをスキップします。

次に、移行ユーティリティで欠落している予約済みキーワードが含まれるファイルの例を示します。

マッピングファイルの例

"type": "nested", "properties": { "userData": { "properties": { "RequestApplicationSecurityToken": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.ApplicationContext": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.AppliesTo": { "type": "string", "index": "not_analyzed" }, "RequestApplicationSecurityToken.NameId": { "type": "string", "index": "not_analyzed" } } }
JSON


  1. 予約済みキーワードを除外するには、out ディレクトリで問題のあるフィールドのファイルを特定します。

    ファイルの例

    - out/ProblematicFieldsReport_2024-04-18_19-51-00.json - out/customer1_846e8755-1ace-4087-9c72-1ed30749ada6___biz_txn_v1___2023-12-09_09-50-05.json
    CODE
  2. /ProblemmaticFieldsReport_2024 ファイルで失敗したインデックスを確認します。
    このレポートには、次のフィールドが含まれます。

    欠落している予約済みキーワード

    RequestApplicationSecurityToken.type.ApplicationContext.type RequestApplicationSecurityToken.type.ApplicationContext.index RequestApplicationSecurityToken.type.ApplicationContext.norms
    JSON
    このレポートの例には、type、index、norms などの予約済みキーワードが含まれています。
  3. 予約済みキーワードをスキップするには、次の手順で application.yml ファイルを更新します。
    1. migration config フォルダに CSV ファイルを作成します。たとえば、skipFields.csv というファイルを作成します。
    2. 予約済みキーワードを CSV 形式で追加します。

      skipFields.csv

      type,index
      CODE
    3. migration config/application.yml ファイルで、migration セクションの下に次のプロパティを追加します。
      migration: search_hits: 5000 reindex_concurrency: 4 reindex_scroll_batch_size: 5000 reindex_requests_per_second: 8000 large_rollover_threshold_size_bytes: 60000000000 # 60 GB small_rollover_threshold_size_bytes: 20000000000 # 20 GB required_low_disk_size_watermark: 85 # Exclude Parent of Child fields during migration exclude_fields_config_file_path: "config/excludeFieldsConfig.json" skip_fields_config_file_path: "config/skipFields.csv"
      CODE

問題が解決しない場合は、excludeFieldsConfig.json に無効な設定が含まれています。次の手順を完了し、設定を更新してください。

  1. kill コマンドを使用して処理を停止します。
  2. マッピングファイルにエラーがないかどうかを調べます。
  3. excludeFieldsConfig.json ファイルを更新します。
  4. /out ディレクトリを空にして、移行ユーティリティツールを再度実行します。