翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon EMR クラスターのログ記録とデバッグを設定する クラスターの計画時に決定すべき事項の 1 つは、どの程度のデバッグサポートを必要とするかです。データ処理アプリケーションを初めて導入するお客様に対しては、小規模で典型的なデータサブセットを処理するアプリケーションをクラスターでテストすることをお勧めします。これを行う場合は、Amazon EMR が提供するあらゆるデバッグツール (Simple Storage Service (Amazon S3) へのログファイルのアーカイブなど) を利用する可能性があります。 導入を終了し、データ処理アプリケーションをフル稼働状態に移行させたら、デバッグの規模を縮小してもかまいません。デバッグの規模を縮小すると、Simple Storage Service (Amazon S3) にログファイルアーカイブを格納するのにかかるコストを節約できるほか、Simple Storage Service (Amazon S3) への状態の書き込みが必要でなくなるので、クラスターでの処理負荷を軽減することができます。もちろん、その反面、何かうまくいかないことがあっても問題を調査するのに使用できるツールは少なくなります。 ## デフォルトログファイル デフォルトでは、各クラスターはすべてのノードにログファイルを書き込みます。その書き込み先は、`/mnt/var/log/` ディレクトリです。「」で説明されているように、SSH を使用して任意のノードに接続することでアクセスできます[SSH を使用して Amazon EMR クラスタープライマリノードに接続する](emr-connect-master-node-ssh.md)。Amazon EMR は、Amazon EMR デーモンやその他の Amazon EMR プロセスによって生成された特定のシステムログとアプリケーションログを収集して、効果的なサービスオペレーションを確保します。 **注記** Amazon EMR リリース 6.8.0 以前を使用している場合、クラスターの終了時にログファイルは Amazon S3 に保存されないため、ノードの終了時にログファイルにアクセスすることはできません。Amazon EMR リリース 6.9.0 以降は、クラスターのスケールダウン中にログを Amazon S3 にアーカイブするため、クラスターで生成されたログファイルは、ノードが終了した後も保持されます。 すべてのノードでログファイルを書き込むために、何も有効にする必要はありません。これは、Amazon EMR および Hadoop のデフォルト動作です。 Amazon EMR は、S3 ログ記録の 3 つのカテゴリのログをキャプチャします。 + **システムログ**: EMR デーモンログ + **アプリケーションログ**: Hadoop、Spark、Hive、およびクラスターで実行されているその他のアプリケーションからのフレームワークログ + **永続 UI ログ**: Spark History Server や Tez UIs などの永続アプリケーション UI に必要なログ ローカルファイルシステムでは、クラスターは `/mnt/var/log`に次のような複数のタイプのログファイルを生成します。 + **ステップログ** — これは Amazon EMR サービスによって生成されるログファイルであり、クラスターに関する情報と各ステップの結果を含みます。このログファイルは、プライマリノードの `/mnt/var/log/hadoop/steps/` ディレクトリに格納されます。各ステップは個別に番号が振られたサブディレクトリにそれぞれの結果を記録します。すなわち、1 番目のステップの場合は `/mnt/var/log/hadoop/steps/s-stepId1/` に記録され、2 番目のステップの場合は `/mnt/var/log/hadoop/steps/s-stepId2/` に記録される、といった具合です。13 文字のステップ識別子（stepId1、stepId2 など）は、クラスターに固有です。 + **Hadoop および YARN コンポーネントログ** — たとえば、Apache YARN と MapReduce の両方に関連付けられているコンポーネントのログは、すべてのノード`/mnt/var/log`の の個別のフォルダに含まれています。`/mnt/var/log` にある Hadoop コンポーネントのログファイルの場所は、hadoop-hdfs、hadoop-mapreduce、hadoop-httpfs、hadoop-yarn です。hadoop-state-pusher ディレクトリは、Hadoop の状態プッシャープロセスの出力に使用されます。 + **ブートストラップアクションログ** — ブートストラップアクションがジョブで使用された場合に、そのアクションの結果がログに記録されます。ログファイルは、すべてのノードの /mnt/var/log/bootstrap-actions/ に保存されます。各ブートストラップアクションは個別に番号が振られたサブディレクトリにそれぞれの結果を記録します。すなわち、1 番目のブートストラップアクションの場合は `/mnt/var/log/bootstrap-actions/1/` に記録され、2 番目のブートストラップアクションの場合は ` /mnt/var/log/bootstrap-actions/2/` に記録される、といった具合です。 + **インスタンス状態ログ** — このログは、CPU に関する情報、メモリの状態、およびノードのガベージコレクタースレッドです。ログファイルはすべてのノード`/mnt/var/log/instance-state/`の に保存されます。 ## Simple Storage Service (Amazon S3) にログファイルをアーカイブする **注記** 現在、`yarn logs` ユーティリティを使って Simple Storage Service (Amazon S3) にログを集計することはできません。 Amazon EMR リリース 6.9.0 以降は、クラスターのスケールダウン中にログを Amazon S3 にアーカイブするため、クラスターで生成されたログファイルは、ノードが終了した後も保持されます。この動作は自動的に有効になるため、有効にするために何もする必要はありません。Amazon EMR リリース 6.8.0 以前では、すべてのノードに保存されているログファイルを定期的に Amazon S3 にアーカイブするようにクラスターを設定できます。こうすれば、クラスターの終了の理由が通常のシャットダウンかエラーのいずれであっても、クラスターの終了後にログファイルを確実に利用できます。Amazon EMR は、5 分間隔でログファイルを Simple Storage Service (Amazon S3) にアーカイブします。 Amazon EMR リリース 6.8.0 以前でログファイルが Simple Storage Service (Amazon S3) にアーカイブされるようにするには、クラスターの起動時に、この機能を有効にする必要があります。これは、コンソール、CLI または API を使用すれば可能です。デフォルトでは、コンソールを使用して起動したクラスターは、ログのアーカイブが有効になってます。CLI または API を使用して起動したクラスターは、Simple Storage Service (Amazon S3) へのログ記録を手動で有効にする必要があります。 ------ #### [ Console ] **新しいコンソールを使用して Simple Storage Service (Amazon S3) にログファイルをアーカイブするには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。 1. 左側のナビゲーションペインの **[EMR on EC2]** で、**[クラスター]** を選択し、**[クラスターの作成]** を選択します 1. **[クラスターログ]** で、**[クラスター固有のログを Amazon S3 に公開]** チェックボックスを選択します。 1. **[Amazon S3 のロケーション]** フィールドに、ログを格納する Simple Storage Service (Amazon S3) のパスを入力 (または参照) します。バケットに存在しないフォルダの名前を入力した場合、Amazon S3 によりそのフォルダが作成されます。 この値が設定されると、Amazon EMR はクラスターの EC2 インスタンスからのログファイルを Simple Storage Service (Amazon S3) にコピーします。これにより、クラスターの終了時およびクラスターをホストしているインスタンスを EC2 が終了してもログファイルが失われるのを回避できます。これらのログは、トラブルシューティングに役立ちます。詳細については、「[ログファイルを表示する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view-web-log-files.html)」を参照してください。 1. オプションで、**[クラスター固有のログを暗号化]** チェックボックスを選択します。次に、リストから AWS KMS キーを選択し、キー ARN を入力するか、新しいキーを作成します。このオプションは、Amazon EMR バージョン 5.30.0 以降 (バージョン 6.0.0 は除く) でのみ使用できます。このオプションを使用するには、EC2 インスタンスプロファイルと Amazon EMR ロール AWS KMS の アクセス許可を に追加します。詳細については、「[Amazon S3 に保存されているログファイルを KMS AWS カスタマーマネージドキーで暗号化するには](#emr-log-encryption)」を参照してください。 1. クラスターに適用するその他のオプションを選択します。 1. クラスターを起動するには、**[クラスターの作成]** を選択します。 ------ #### [ CLI ] **を使用してログファイルを Amazon S3 にアーカイブするには AWS CLI** を使用してログファイルを Amazon S3 にアーカイブするには AWS CLI、 `create-cluster` コマンドを入力し、 `--log-uri`パラメータを使用して Amazon S3 ログパスを指定します。 1. Simple Storage Service (Amazon S3) にログファイルをアーカイブするには、次のコマンドを入力し、*myKey* を EC2 キーペアの名前に置き換えます。 ``` aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 --log-uri s3://DOC-EXAMPLE-BUCKET/logs --applications Name=Hadoop Name=Hive Name=Pig --use-default-roles --ec2-attributes KeyName=myKey --instance-type m5.xlarge --instance-count 3 ``` 1. `--instance-groups` パラメータを使用せずにインスタンス数を指定すると、1 つのプライマリノードが起動され、残りのインスタンスはコアノードとして起動されます。すべてのノードで、コマンドで指定したインスタンスタイプが使用されます。 **注記** 以前にデフォルトの Amazon EMR サービスロールと EC2 インスタンスプロファイルを作成していない場合は、「`aws emr create-default-roles`」と入力してそれらを作成してから、`create-cluster` サブコマンドを入力します。 ------ ### Amazon S3 に保存されているログファイルを KMS AWS カスタマーマネージドキーで暗号化するには Amazon EMR バージョン 5.30.0 以降 (Amazon EMR 6.0.0 を除く) では、Amazon S3 に保存されているログファイルを AWS KMS カスタマーマネージドキーで暗号化できます。コンソールでこのオプションを有効にするには、「[Simple Storage Service (Amazon S3) にログファイルをアーカイブする](#emr-plan-debugging-logs-archive)」の手順に従います。Amazon EC2 インスタンスプロファイルと Amazon EMR ロールは、以下の前提条件を満たしている必要があります。 + クラスターで使用する Amazon EC2 インスタンスプロファイルには、`kms:GenerateDataKey` を使用するアクセス許可が必要です。 + クラスターで使用する Amazon EMR ロールには、`kms:DescribeKey` を使用するアクセス許可が必要です。 + 次の手順で示すように、Amazon EC2 インスタンスプロファイルと Amazon EMR ロールを、指定された KMS AWS カスタマーマネージドキーのキーユーザーのリストに追加する必要があります。 1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) で AWS Key Management Service (AWS KMS) コンソールを開きます。 1. AWS リージョンを変更するには、ページの右上隅にあるリージョンセレクターを使用します。 1. 変更する KMS キーのエイリアスを選択します。 1. [**Key Users**] のキーの詳細ページで、[**Add**] を選択します。 1. **[キーユーザーの追加]** ダイアログボックスで、Amazon EC2 インスタンスプロファイルと Amazon EMR ロールを選択します。 1. **[Add]** (追加) を選択します。 + また、`persistentappui.elasticmapreduce.amazonaws.com` および `elasticmapreduce.amazonaws.com` サービスプリンシパルを `kms:GenerateDataKey`、`kms:GenerateDataKeyWithoutPlaintext` および `kms:Decrypt` に許可するように KMS キーを設定する必要があります。これにより、EMR は KMS キーで暗号化されたログをマネージドストレージに読み書きできます。ユーザー IAM ロールには、`kms:GenerateDataKey` と `kms:Decrypt` を使用するアクセス許可が必要です。 ``` { "Sid": "Allow User Role to use KMS key", "Effect": "Allow", "Principal": { "AWS": "User Role" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringLike": { "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*", "kms:ViaService": "elasticmapreduce.region.amazonaws.com" } } }, { "Sid": "Allow Persistent APP UI to validate KMS key for write", "Effect": "Allow", "Principal":{ "Service": [ "elasticmapreduce.amazonaws.com" ] }, "Action": [ "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*", "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*" } } }, { "Sid": "Allow Persistent APP UI to Write/Read Logs", "Effect": "Allow", "Principal":{ "Service": [ "persistentappui.elasticmapreduce.amazonaws.com", "elasticmapreduce.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*", "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*", "kms:ViaService": "s3.region.amazonaws.com" } } } ``` セキュリティのベストプラクティスとして、KMS キーポリシーに `kms:EncryptionContext` および `aws:SourceArn` 条件を追加することをお勧めします。これらの条件は、キーが EC2 上の Amazon EMR でのみ使用され、特定のクラスターで実行されているジョブから生成されたログにのみ使用されるようにするのに役立ちます。 詳細については、「 Key Management Service デベロッパーガイド」の[「Amazon EMR で使用される IAM サービスロール](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-service-roles.html)」および AWS 「キー[ポリシーの使用](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users)」を参照してください。 ### を使用して Amazon S3 のログを集約するには AWS CLI **注記** 現在、`yarn logs` ユーティリティを使ってログを集計することはできません。この手順でサポートされる集計のみ使用できます。 ログ集計（Hadoop 2.x）では、個々のアプリケーションのすべてのコンテナのログが 1 つのファイルにコンパイルされます。を使用して Amazon S3 へのログ集約を有効にするには AWS CLI、クラスター起動時にブートストラップアクションを使用してログ集約を有効にし、ログを保存するバケットを指定します。 + ログ集計を有効にするには、次の内容が含まれる `myConfig.json` と呼ばれる設定ファイルを作成します。 ``` [ { "Classification": "yarn-site", "Properties": { "yarn.log-aggregation-enable": "true", "yarn.log-aggregation.retain-seconds": "-1", "yarn.nodemanager.remote-app-log-dir": "s3:\/\/DOC-EXAMPLE-BUCKET\/logs" } } ] ``` 次のコマンドを入力し、*`myKey`* を EC2 キーペアの名前に置き換えます。さらに、赤色のテキストはいずれも独自の設定に置き換えることができます。 ``` aws emr create-cluster --name "Test cluster" \ --release-label emr-7.12.0 \ --applications Name=Hadoop \ --use-default-roles \ --ec2-attributes KeyName=myKey \ --instance-type m5.xlarge \ --instance-count 3 \ --configurations file://./myConfig.json ``` `--instance-groups` パラメータを使用せずにインスタンス数を指定すると、1 つのプライマリノードが起動され、残りのインスタンスはコアノードとして起動されます。すべてのノードで、コマンドで指定したインスタンスタイプが使用されます。 **注記** 以前にデフォルトの EMR サービスロールと EC2 インスタンスプロファイルを作成していない場合は、「`aws emr create-default-roles`」を実行してそれらを作成してから、`create-cluster` サブコマンドを入力します。 での Amazon EMR コマンドの使用の詳細については AWS CLI、[AWS CLI 「 コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/emr)」を参照してください。 ### Amazon EMR 自己診断およびトラブルシューティングツール このランブックは、Amazon EMR クラスターでジョブを実行しているときのエラーを特定するのに役立ちます。このランブックは、ファイルシステム上の定義済みログのリストを分析し、定義済みのキーワードのリストを探します。これらのログエントリは Amazon CloudWatch Events イベントの作成に使用されるため、イベントに基づいて必要なアクションを実行できます。オプションで、ランブックは、選択した Amazon CloudWatch Logs ロググループにログエントリを公開します。[AWSSupport-AnalyzeEMRLogs](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-analyzeemrlogs.html)。 このランブックは、 Glue Data Catalog との統合で Amazon Athena を使用して S3 の Amazon EMR AWS ログを診断するのに役立ちます。 Amazon Athena Amazon Athena は、コンテナ、ノードログ、またはその両方について Amazon EMR ログファイルをクエリするために使用されます。特定の日付範囲またはキーワードベースの検索のオプションパラメータを使用します。このランブックは、Amazon EMR クラスターログで見つかったすべてのエラーと頻繁に発生する例外のリストと、対応する S3 ログの場所を提供します。また、Amazon EMR ログで一致した一意の既知の例外の概要と、[AWSSupport-DiagnoseEMRLogsWithAthena](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-diagnose-emr-logs-with-athena.html) のトラブルシューティングに役立つ推奨解決策とナレッジセンター/再投稿記事も提供します。 ## ログの場所 次のリストに、Amazon S3 のすべてのログタイプとそれらの場所を示します。Amazon EMR の問題のトラブルシューティングにこれらを使用できます。 **ステップログ** `s3://DOC-EXAMPLE-LOG-BUCKET//steps//` **アプリケーションログ** `s3://DOC-EXAMPLE-LOG-BUCKET//containers/` この場所には、`stderr` コンテナと `stdout`、`directory.info`、`prelaunch.out`、および `launch_container.sh` ログが含まれます。 **リソースマネージャーログ** `s3://DOC-EXAMPLE-LOG-BUCKET//node//applications/hadoop-yarn/` **Hadoop HDFS** `s3://DOC-EXAMPLE-LOG-BUCKET//node//applications/hadoop-hdfs/` この場所には、NameNode、DataNode、および YARN TimelineServer のログが含まれます。 **ノードマネージャーログ** `s3://DOC-EXAMPLE-LOG-BUCKET//node//applications/hadoop-yarn/` **インスタンス状態ログ** `s3://DOC-EXAMPLE-LOG-BUCKET//node//daemons/instance-state/` **Amazon EMR プロビジョニングログ** `s3://DOC-EXAMPLE-LOG-BUCKET//node//provision-node/*` **Hive ログ** `s3://DOC-EXAMPLE-LOG-BUCKET//node//applications/hive/*` + クラスター上の Hive ログを見つけるには、アスタリスク (`*`) を削除して、`/var/log/hive/` を上記のリンクに追加します。 + HiveServer2 ログを見つけるには、アスタリスク (`*`) を削除して、`var/log/hive/hiveserver2.log` を上記のリンクに追加します。 + HiveCLI ログを見つけるには、アスタリスク (`*`) を削除して、`/var/log/hive/user/hadoop/hive.log` を上記のリンクに追加します。 + Hive メタストアサーバーログを見つけるには、アスタリスク (`*`) を削除して、`/var/log/hive/user/hive/hive.log` を上記のリンクに追加します。 Tez アプリケーションのプライマリノードまたはタスクノードで障害が発生している場合は、適切な Hadoop コンテナのログを提供してください。 ## S3 ログ記録の動作を制御する (Amazon EMR 7.13.0 以降) Amazon EMR 7.13.0 以降では、S3LoggingConfiguration 機能を使用してアップロード動作を制御できます。これにより、システムログ、アプリケーションログ、永続 UI ログなど、ログタイプごとに異なるアップロードポリシーを指定できます。 ### アップロードポリシー ログタイプごとに、次のいずれかのアップロードポリシーを指定できます。指定されていないログタイプは、デフォルトで標準動作 (emr マネージド) になります。 **emr-managed (デフォルト)** 標準動作。ログは LogUri で設定されたとおりに Amazon S3 にアップロードされ、運用上のサポートとトラブルシューティングの目的で、特定のログがサービスによって保持されます。 LogUri **on-customer-s3 のみ** カスタマーマネージドストレージのみ。ログは、お客様が指定した S3 バケットにのみアップロードされます。そのためには、クラスターの作成時に LogUri を指定する必要があります。Persistent-ui-logs には、顧客専用ポリシーを含めることはできません。persistent-ui-logs で許可されているポリシーは、emr 管理され、無効になっています。 **無効** このログタイプの S3 アップロードはありません。 ### 設定例 AWS CLI、、または AWS SDKs を使用して新しい Amazon EMR クラスターを作成するときに S3 ログ記録を設定できます。設定は MonitoringConfiguration パラメータで指定します。 **例: デフォルトの動作** S3LoggingConfiguration を指定しない場合、すべてのログタイプはデフォルトで emr マネージド動作になります。 ``` aws emr create-cluster \ --name "MyCluster" \ --release-label emr-7.13.0 \ --instance-type m5.xlarge \ --instance-count 3 \ --log-uri s3://my-bucket/logs/ \ --use-default-roles ``` **例: カスタム S3 ログ記録設定** この例では、ログタイプごとに異なるアップロードポリシーを設定する方法を示します。 ``` aws emr create-cluster \ --name "MyCluster" \ --release-label emr-7.13.0 \ --instance-type m5.xlarge \ --instance-count 3 \ --log-uri s3://my-bucket/logs/ \ --use-default-roles \ --monitoring-configuration '{ "S3LoggingConfiguration": { "LogTypeUploadPolicy": { "application-logs": "on-customer-s3only", "persistent-ui-logs": "disabled" } } }' ``` この設定では、お客様の S3 バケットにのみアプリケーションログをアップロードし、永続的な UI ログのアップロードを完全に無効にします。指定されていないログタイプ (システムログ) は、デフォルトの (emr マネージド) 動作に従います。 ### 考慮事項 + S3 ログ記録設定はクラスターの作成時にのみ設定でき、実行中のクラスターに対して変更することはできません。 + Persistent-ui-logs には、顧客専用ポリシーを含めることはできません。persistent-ui-logs で許可されているポリシーは、emr 管理され、無効になっています。 + **LogUri 要件**: system-logs または application-logs に on-customer-s3only ポリシーを使用する場合は、LogUri パラメータを指定する必要があります。LogUri を使用しないと、クラスターの作成は失敗します。 + **デフォルトの動作**: S3LoggingConfiguration が指定されていない場合、すべてのログタイプはデフォルトで emr マネージド動作になります。