翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
トラブルシューティング AWS Application Discovery Service
このセクションでは、 AWS Application Discovery Serviceの一般的な問題の修正方法について説明します。
トピック
データ探索によるデータ収集の停止
データ探索を停止するには、Migration Hub コンソールの Discover > Data Collectors > Agents タブでトグルスイッチをオフにするか、 StopContinuousExport
API を呼び出します。データ収集の停止には最大 30 分かかることがあります。この段階では、コンソールのトグルスイッチと DescribeContinuousExport
API 呼び出しで、データ探索の状態が「停止中」と表示されます。
注記
コンソールページをリフレッシュした後、切り替えのスイッチがオフにならずエラーメッセージがスローされるか、DescribeContinuousExport
API が、「Stop_Failed」を返す場合は、再度コンソールでトグルスイッチをオフにするか StopContinuousExport
API を呼び出します。「データ探索」にエラーが表示され、正常に停止できない場合は、 AWS サポートにお問い合わせください。
または、次の手順で説明されているようにデータ収集を手動で停止できます。
オプション 1: エージェントデータ収集の停止
ADS エージェントを使用した検出がすでに完了していて、ADS データベースリポジトリで追加データをさらに収集しない場合:
-
Migration Hub コンソールから、[Discover] (検出) > [Data Collectors] (データコレクタ) > [Agents] (エージェント) タブの順に選択します。
-
実行中の既存のすべてのエージェントを選択して、[Stop Data Collection (データ収集の停止)] を選択します。
これにより、ADS データリポジトリおよび S3 バケットの両方で、エージェントにより、新しいデータが収集されていないことを確認できます。既存のデータには引き続きアクセスできます。
オプション 2: データ探索の Amazon Kinesis Data Streams を削除する
ADS データリポジトリ内のエージェントによるデータ収集を継続したいが、データ探索を使用して Amazon S3 バケット内のデータを収集しない場合は、データ探索によって作成された Amazon Data Firehose ストリームを手動で削除できます。
-
AWS コンソールから Amazon Kinesis にログインし、ナビゲーションペインから Data Firehose を選択します。
-
データ探索機能によって作成された次のストリームを削除します。
-
aws-application-discovery-service-id_mapping_agent
-
aws-application-discovery-service-inbound_connection_agent
-
aws-application-discovery-service-network_interface_agent
-
aws-application-discovery-service-os_info_agent
-
aws-application-discovery-service-outbound_connection_agent
-
aws-application-discovery-service-processes_agent
-
aws-application-discovery-service-sys_performance_agent
-
データ探索によって収集されたデータを削除する
データ探索によって収集されたデータを削除するには
-
Amazon S3 に保存されている Discovery Agent データを削除します。
AWS Application Discovery Service (ADS) によって収集されたデータは、 という名前の S3 バケットに保存されます
aws-application-discover-discovery-service-
。uniqueid
注記
Amazon Athena でのデータ探索が有効になっている間に Amazon S3 バケットまたはその中のオブジェクトを削除すると、エラーが発生します。 Amazon Athena 新しい検出エージェントデータを S3 に送信し続けます。削除されたデータには、Athena でもアクセスできなくなります。
-
削除します AWS Glue Data Catalog。
Amazon Athena でデータ探索を有効にすると、アカウントに Amazon S3 バケットが作成され、ADS エージェントによって定期的に収集されたデータが保存されます。さらに、Amazon Athena から Amazon S3 バケットに保存されているデータをクエリ AWS Glue Data Catalog できる も作成します。Amazon Athena でデータ探索をオフにすると、Amazon S3 バケットに新しいデータは保存されませんが、以前に収集されたデータは保持されます。このデータが不要になり、Amazon Athena でのデータ探索がオンになる前にアカウントを 状態に戻す場合。
-
AWS コンソールから Amazon S3 にアクセスし、aws-application-discover-discovery-service-uniqueid」という名前のバケットを手動で削除します。
-
application-discovery-service-database データベースとこれらのすべてのテーブルを削除することで、データ探索 AWS Glue データカタログを手動で削除できます。
-
os_info_agent
-
network_interface_agent
-
sys_performance_agent
-
processes_agent
-
inbound_connection_agent
-
outbound_connection_agent
-
id_mapping_agent
-
-
からのデータの削除 AWS Application Discovery Service
Application Discovery Service からすべてのデータを削除するには、 AWS サポート
Amazon Athena でのデータ探索に関する一般的な問題を修正
このセクションでは、Amazon Athena でのデータ探索に関する一般的な問題の修正方法について説明します。
トピック
サービスにリンクされたロールと必要な AWS リソースを作成できないため、Amazon Athena のデータ探索が開始されない
Amazon Athena でデータ探索を有効にすると、Amazon S3 バケットAWSServiceRoleForApplicationDiscoveryServiceContinuousExport
、Amazon Kinesis ストリーム、 など、エージェントが収集したデータを Amazon Athena でアクセス可能にするために必要な AWS リソースを作成できるサービスにリンクされたロール がアカウントに作成されます AWS Glue Data Catalog。アカウントに、このロールを作成するための Amazon Athena でのデータ探索のための適切なアクセス許可がない場合、初期化は失敗します。「AWS の マネージドポリシー AWS Application Discovery Service」を参照してください。
Amazon Athena に新しいエージェントデータが表示されない
新しいデータが Athena に流れず、エージェントが開始してから 30 分以上が経過しており、データ探索のステータスがアクティブである場合は、以下に示すソリューションを確認してください。
-
AWS 検出エージェント
エージェントの [Collection] (収集) ステータスが [Started] (開始済み) になっており、[Health]] (ヘルス) ステータスが [Running] (実行中) になっていることを確認します。
-
Kinesis ロール
アカウントに
AWSApplicationDiscoveryServiceFirehose
ロールがあることを確認します。
-
Firehose のステータス
次の Firehose 配信ストリームが正しく動作していることを確認します。
-
aws-application-discovery-service/os_info_agent
-
aws-application-discovery-service-network_interface_agent
-
aws-application-discovery-service-sys_performance_agent
-
aws-application-discovery-service-processes_agent
-
aws-application-discovery-service-inbound_connection_agent
-
aws-application-discovery-service-outbound_connection_agent
-
aws-application-discovery-service-id_mapping_agent
-
-
AWS Glue Data Catalog
application-discovery-service-database
データベースが にあることを確認します AWS Glue。 AWS Glueに以下のテーブルが存在することを確認します。-
os_info_agent
-
network_interface_agent
-
sys_performance_agent
-
processes_agent
-
inbound_connection_agent
-
outbound_connection_agent
-
id_mapping_agent
-
-
Amazon S3 バケット
アカウントに
aws-application-discovery-service-
という名前の Amazon S3 バケットがあることを確認します。バケット内のオブジェクトが移動または削除された場合、それらは Athena で適切に表示されません。uniqueid
-
オンプレミスサーバー
サーバーが実行されていて、エージェントが AWS Application Discovery Serviceにデータを収集して送信できることを確認します。
Amazon S3、Amazon Data Firehose、または にアクセスするための十分なアクセス許可がない AWS Glue
を使用していて AWS Organizations、Amazon Athena でのデータ探索の初期化が失敗した場合、Amazon S3、Amazon Data Firehose、Athena、または にアクセスするアクセス許可がないためである可能性があります AWS Glue。
これらのサービスに対するアクセス権を付与するには、管理者権限を持つ IAM ユーザーが必要です。管理者は、このアクセス権限を付与するために、ユーザーのアカウントを使用できます。「AWS の マネージドポリシー AWS Application Discovery Service」を参照してください。
Amazon Athena でのデータ探索が正しく機能するようにするには、Amazon S3 バケット、Amazon Data Firehose Streams、 など、Amazon Athena でデータ探索によって作成された AWS リソースを変更または削除しないでください AWS Glue Data Catalog。これらのリソースを誤って削除または変更してしまった場合は、データ探索を停止して起動すると、これらのリソースが自動的に再作成されます。データ探索によって作成された Amazon S3 バケットを削除すると、バケットで収集されたデータが失われる可能性があります。
失敗したインポートレコードのトラブルシューティング
Migration Hub のインポートを使用すると、Discovery Connector または Discovery Agent を使用せずに、オンプレミス環境の詳細情報を Migration Hub に直接インポートできます。そのため、インポートデータを使用して、直接、移行の評価および計画を行うこともできます。デバイスをアプリケーションとしてグループ化し、それらの移行ステータスを追跡することもできます。
データをインポートする際、エラーが発生する可能性があります。通常、これらのエラーは、次のいずれかの原因により発生します。
-
インポート関連のクォータに到達した – インポートタスクに関連付けられたクォータがあります。そのクォータを超えるインポートタスクリクエストを行った場合、そのリクエストは失敗し、エラーが返されます。詳細については、「AWS Application Discovery Service のクォータ」を参照してください。
-
余分なカンマ (,) がインポートファイルに挿入されている – .CSV ファイル内のカンマは、フィールドと後続のフィールドを区別するために使用されます。フィールド内にカンマを入れることはサポートされていません。カンマを入れるとフィールドが分割されます。これが原因で、フォーマットエラーのカスケードが生じることがあります。カンマはフィールド間でのみ使用され、インポートファイルで使用することはできません。
-
フィールドにサポート範囲外の値が含まれている –
CPU.NumberOfCores
など、一部のフィールドにはサポートする値の範囲が必要です。サポートされている範囲よりも多い、または少ない場合、レコードはインポートされません。
インポートリクエストでエラーが発生した場合は、インポートタスクの失敗したレコードをダウンロードしてそれらを解決し、失敗したエントリの CSV ファイルでエラーを解決してから再度インポートします。
失敗したレコードのアーカイブがダウンロードされました。次に、中の 2 つのファイルを抽出してエラーを修正します。エラーがサービスベースの制限に関連付けられている場合は、制限の引き上げをリクエストするか、アカウントを制限以下にするのに十分な関連リソースを削除する必要があります。アーカイブには次のファイルがあります。
-
errors-file.csv – このファイルはエラーログで、失敗した各エントリの失敗した各レコードに関する行、列名、
ExternalId
、および説明的なエラーメッセージを追跡します。 -
failed-entries-file.csv – このファイルには、元のインポートファイルからの失敗したエントリのみが含まれています。
発生した非制限ベースのエラーを修正するには、errors-file.csv
を使用して、failed-entries-file.csv
ファイルの問題を修正してから、そのファイルをインポートします。ファイルのインポート手順については、「 データのインポート」を参照してください。