YARNのFLINK（下）：よくある質問とトラブルシューティングのアイデアを求めて

著者：ヤンタオ（リスクはるか）

スタンドアロン展開と独立したFLINK YARN、Kubernetes、Mesosと中国でのアプリケーションYARNクラスタ展開モデルはますます広くある他のクラスタの展開モデルをサポートしています。YARNコミュニティのFLINK FLINKは、二つの上下に分かれて、一連の記事のアプリケーションの解釈を起動します。パートは、全体のプロセスを開始するためにYARNアプリケーションに再構築されたFLIP-6はじめFLINKに基づいてリソースのスケジューリングモデルを共有し、本論文では、コミュニティからのフィードバックを群衆に基づいて行われます、クライアントとFLINKクラスタ答えは頻繁に問題のトラブルシューティングに関連する質問、共有のアイデアを尋ねました。

クライアントのFAQとトラブルシューティングのアイデア

▼例外情報は、アプリケーションのコンソールを提出：JARファイルからプログラムを構築することができませんでした。

大型の問題を混乱させ、多くの場合、問題を実行しているJARファイルを指定しない原因が、提出の際の例外は、ログ情報に基づいて、さらなる調査の必要性を発生します。このための最も一般的な理由は、CLASSPATHにHadoopのJARファイルに依存しない、（：ClassNotFoundExceptionが：例えばorg.apache.hadoop.yarn.exceptions.YarnException）に依存するクラスを見つけることができない負荷クライアントエントリクラス（FlinkYarnSessionCli）が失敗した原因となります。

**▼FLINK糸糸が特定のクラスタにリンクされたときに申請書を提出する方法については？
**

YARNクライアント上FLINKは通常、クライアントがHadoopの構成と依存JARファイルにロードすることができようにするHADOOP_CONF_DIRとHADOOP_CLASSPATH 2つの環境変数を設定する必要があります。（既存のHadoop導入環境変数HADOOP_HOMEはディレクトリ指定）の例：

export HADOOP_CONF_DIR=${HADOOP_HOME}/etc/hadoop
export HADOOP_CLASSPATH=`${HADOOP_HOME}/bin/hadoop classpath`

設定するには、どのように、▼クライアントのログ？

$ {} FLINK_HOME /conf/log4j-cli.properties： - log4jの設定を使用して$ {USER} -client-.logに、$ {} FLINK_HOME /ログ/ FLINK：クライアントは通常、配備ディレクトリのフォルダでFLINKログファイルを記録します。

いくつかのクライアント環境は、ログの場所と構成を見つけることより、複雑で困難であり、次の環境変数を設定することができ、デバッグログのlog4j、log4jの初期化の追跡と詳細なロード処理を開く：輸出JVM_ARGS =「 - Dlog4j.debug =真」

▼クライアントの問題のトラブルシューティングのアイデア

クライアントログが正常に見つけることができないときは、DEBUG INFOが変更された後、ログレベルのlog4j設定ファイルがデバッグログは、問題のトラブルシューティングに役立つかどうかを確認するために、再実行されます変更することができます。いくつかの質問についてはログや不完全な情報何が存在しない、コードレベルのデバッグを実行するために必要になることがあり、あまりにも面倒な代替方法を再パッケージするために、ソースコードを変更し、JavaバイトコードインジェクションツールByteman使用することをお勧めします（構文の詳細な説明を参照してください：Byteman文書）を、使用例：

（1）例えばFLINKクライアントクラスは、実際に使用される印刷など、スクリプトデバッガを書き込み、次のスクリプト関数がCliFrontend＃getActiveCustomCommandLineが終了するとき、印刷は、その値が返されることを示しています。

RULE test
CLASS org.apache.flink.client.cli.CliFrontend
METHOD getActiveCustomCommandLine
AT EXIT
IF TRUE
DO traceln("------->CliFrontend#getActiveCustomCommandLine return: "+$!);
ENDRULE

（2）byteman javaagentを使用して、環境変数を設定します：

export BYTEMAN_HOME=/path/to/byte-home
export TRACE_SCRIPT=/path/to/script
export JVM_ARGS="-javaagent:${BYTEMAN_HOME}/lib/byteman.jar=script:${TRACE_SCRIPT}"

（3）テストコマンドビン/ FLINK実行-m糸クラスタ-p 1 ./examples/streaming/WordCount.jar、コンソール出力内容を実行します。

-------> CliFrontend＃getActiveCustomCommandLine戻る：org.apache.flink.yarn.cli.FlinkYarnSessionCli@25ce9dc4を

FLINKクラスタFAQとトラブルシューティングのアイデア

▼ユーザーのアプリケーションフレームワークのJARパッケージとバージョン競合

問題は、通常、この問題を解決するために、NoSuchMethodError / ClassNotFoundExceptionが/でIncompatibleClassChangeErrorやその他の異常がスローされます。

**
頼る1.まず必要ライブラリ例外クラス*を見つけるためによると、その後、あなたはプロジェクト内のMVN依存実行することができます。すべての依存チェーンを示すツリー構造でツリーを、その後、依存ライブラリから競合を見つけ、あなたも-Dincludesを表示するパラメータを増やすことができますパケットフォーマット【のgroupId]：[たartifactId]： [タイプ]：[バージョン]、マッチング支援、例えば、コンマで区切られた複数の：MVN依存：ツリー-Dincludes =力、javaassist。

2.どのように競合する行のパッケージを検討するために必要なパッケージを見つけて、簡単な解決策は、プロジェクト上の彼の依存からの信頼のパスを除外するための除外を使用することですが、いくつかのシナリオは、複数のバージョンの共存を必要とし、それに応じて、別のコンポーネントの別のバージョン解決するために、Mavenのシェードプラグインの使用を考慮することが、Mavenのシェードプラグインを参照してください。

▼パッケージの特定の種類が共存する場合に、特定のソースを決定する方法の依存ライブラリJAR複数のバージョンは？

実際の使用に関連するロード順序付きバージョンを結果として、CLASSPATHのJARパッケージの複数のバージョンを実行するために、多くのアプリケーションの同じ依存関係があり、多くの場合、クラスJARのソースを決定する必要がある場合、トラブルシューティング、JM / TMプロセスJVMの設定パラメータへのFLINKのサポート、印刷は、このように一つを選択することができる応じてその上に次の三つのクラスとそのソース構成項目（出力ログ.OUT）によってロードすることができます。

env.java.opts=-verbose:class   //配置JobManager&TaskManager
env.java.opts.jobmanager=-verbose:class //配置JobManager env.java.opts.taskmanager=-verbose:class //配置TaskManager

ログ閲覧アプリケーション▼FLINKを完了するためにどのように？

JM / TMログを実行しているFLINKアプリケーションは、WebUIの上で見ていますが、程度とアプリケーションの状態を保存するために、コンテナの場所に、機構YARNのログを保存するために知ってYARNログを必要とするので、通常は、トラブルシューティング時に問題に見て、完全なログ分析の組み合わせを必要とすることができます。

1.アプリケーションが終わっていない場合は、コンテナのログは、操作がコンテナがまだディレクトリ構成ノードで見つけることができます完了している場合でも、それが実行されているノード上に残ります：$ {yarn.nodemanager.log-dirsに} // 、：あなたはまた、WebUIのから直接アクセスすることができますHTTP：///ノード/ containerlogs //

2.アプリケーションが（=真yarn.log集約有効）が完成し、クラスタ対応のログ収集されている場合、それは通常、アプリケーションの終了である（あなたはまた、インクリメンタル・アップロードを設定することができます）NMすべてのログは通常、その分散ストレージ（にアップロードされますHDFSである）とローカルファイルを削除して、私たちは糸の糸ログ-applicationId -appOwnerにより、すべてのログコマンドアプリケーションを参照してくださいすることができ、あなたもまた、直接分散ストレージディレクトリにアクセスすることができ、コンテナのログを表示するパラメータ項目-containerId -nodeAddressを追加することができます。 $ {yarn.nodemanager.remote-APP-ログDIR} / $ {ユーザ} / $ {yarn.nodemanager.remote-APP-ログDIR-サフィックス} /

▼FLINKアプリケーションリソース割り当てのトラブルシューティングのアイデア

FLINKを起動できないアプリケーションは、通常のRUNNING状態に達した場合は、次の手順で、それを分離することができます：

1.アプリケーションの現在の状態を確認する必要がある、起動プロセスの説明によると、私たちは知っています：

我々はRMストレージサービス（通常のZooKeeperクラスタ）の状態を確認する必要があり、この状態で続けば、情報の応用の進展状態をNEW_SAVINGとき持続は、正常です。
提出状態で、それができるならば、時間のかかる操作は、RM-書き込みロック内で発生し、さらに位置決めYARNクラスタログの必要性に応じて、蓄積につながるイベントの一部を保持します。
状態が受け入れられる場合、AMは、ステップ2に進み、正常かどうかをチェックする必要があります。
あなたが適切に機能することはできませんJOBでの結果を得るためにすべてのリソースをRUNNING状態を持っていますが、ない場合は、ステップ3に進みます。

2. YARNからアプリケーションインターフェイスを表示することができ、AMが正常で確認してください（：HTTP ///クラスタ/アプリケーションは/（）YARNアプリケーションやAPIのREST ：/// WS / V1 /クラスタ/アプリ/ HTTPビュー診断情報）、キーに基づいて問題の原因ワード明確な情報とソリューション：

- 。QueueのAMのリソース制限は、AMがリソースを使用して、新しいアプリケーション・リソースの合計AMキューがリソースキューのAM上限を超えている。すなわち、あなたが利用可能なリソースのキューAMのCIの割合を調整することができ、キューAM利用可能なリソースの上限に到達するため、超過しました：yarn.scheduler.capacity..maximum-AM-資源パーセント。

- ユーザーのAMのリソース制限はつまり、アプリケーションは、ユーザーがリソースを使用してアプリケーションを越えた新しいアプリケーションのリソースの合計がAMでユーザーキューでキューに属するAMき属し、アプリケーションはAMで利用可能なリソースの天井のユーザーキューに属して到達することによる超えました。 yarn.scheduler.capacity..user制限因子とyarn.scheduler.capacity..minimumユーザ制限パーセント：ユーザに利用可能なリソースの上限は、関連する構成要素をこの問題を解決するためのAM資源の割合で適切に増加することができるAM。

- AMコンテナがRMに登録するAMコンテナを待って、起動されたAMが開始しますが、内部の初期化を完了していない大まかので、接続タイムアウトやその他の問題があっZKあり、具体的な理由が解決する特定の問題に応じて、AMの調査をログに記録する必要があります。

- アプリケーションがチェックをスケジューラが割り当てを待って、経過を示すAMをAMアプリケーションについて割り当てられるリソースを待って、活性化され、次いで、リソーススケジューラが必要なレベルをチェックし、ステップ4に進みます。

3.アプリケーションが満たされていないリソース要求糸を持っていることを確認してください：アプリケーションページを入力するためにアプリケーションリストページのアプリケーションIDの問題をクリックして、そこ発行済リソースが保留リソースリストを要求するかどうかを確認するには、アプリケーションの例のページを入力するには、以下のインスタンスIDのリストを適用]をクリックしますそうでない場合、糸説明が割り当てられている、プロセスは終了をチェックし、AMをチェックするために回し、その場合、割り当てられたスケジューラが完了していないことを、ステップ4に進みます。

4.スケジューラは、トラブルシューティングは、YARN-9050は、REST APIをサポートし、自動診断アプリケーションの問題を通じて、WebUIの上Hadoop3.3.0にリリースされる、調査の以前のバージョンを手動で行う必要が残って割り当てます。

クラスタまたはキューリソースをチェックし、スケジューラキューは、ページのツリービュー展開ビューリソース情報を残し：効果的な最大リソース、使用したリソースを：（1）リソースまたはリソースまたはその親キューキューは、リソースが足りなくなった場合は、クラスタをチェックし、（2）の葉を確認します寸法リソースキュー・アプローチかどうかの上限に達します。
リソース・フラグメンテーションを確認：との比は、（1）資源との総リソース予約済みクラスタリソースをチェックするために使用され、（例えば、90％以上）の完全なクラスタリソースに近づいたときに、アプリケーションの速度にデブリリソース割当が存在してもよいです低速のマシンのほとんどは、リソースを持っていないので、影響を受けた、とマシンはマシンのほとんどがロックされているとリソースの一定量がフォローアップの割り当てが遅くなるかもしれない、つながることの後に準備金を達成するために利用できるリソース不足、予約されたリソースになります。（2）検査利用可能なリソースのNM分布は、クラスタリソースの使用率が高くない場合であっても、それはまた、より多くのCPUリソースがノード上で1/2 CPUの残りとの完全な1/2に近いノードに、例えば、によるメモリリソースが発生したため、各資源配分の異なる寸法のものであってもよいです完全なメモリリソースとの密接な残りのリソースもリソースには適用されない可能性があり大きすぎるアプリケーション構成リソースの寸法のより多くのリソース値です。
優先度の高いアプリケーションのためのリソースの頻繁なアプリケーションの問題や課題の即時解放を確認し、この状況は、スケジューラがビジー状態のリソースがアプリケーションを要求し満足して他のアプリケーションに出席する原因となります。
コンテナの確認が開始または念を撤回自動的に起動することができなかった、あなたは、（など、ログをローカライズログを起動含む）のログコンテナを表示YARNのNMログや糸RM調査をログに記録することができます。

▼タスクマネージャ启动异常：
org.apache.hadoop.yarn.exceptions.YarnException：コンテナを起動への不正な要求。このトークンの有効期限が切れています。現在の時刻が...発見されました...

例外FLINK AMアプリケーションの起動は、このコンテナ糸RMを受信してから長い時間が経過した後、通常FLINK AMので、スローするようにコンテナYARN NMのトークンを計時したとき（コンテナの有効時間よりも、デフォルトの10分、コンテナがリリースされました）内部シリアルFLINKは、糸RMが返されたコンテナのリソースを受け取った後に開始するので、先に進む前にそれを開始します。

多数のコンテナが起動し、簡単コンテナ開始要求（タスクマネージャをアップロードするコンフィギュレーションを開始する前に）そのようなHDFS遅い性能としてファイルストレージを配布するときFLINK-13184この問題には、最適化された開始1つ前にされた、内部に蓄積これは、第二の、無意味な設定のアップロードプロセスを回避するために、小切手の有効性を高める非同期マルチスレッド最適化、高速化ブーツです。

▼フェイルオーバ异常1：
java.util.concurrent.TimeoutException：スロット割り当て要求がためにタイムアウトになりました...

異常は、あなたはアイデアが問題を解決するために4段階のトラブルシューティングFLINKアプリケーションリソース割り当ての問題を押すことができ、リソースのタスクマネージャのアプリケーションが適切に割り当てることができないです。

▼フェイルオーバー异常2：
java.util.concurrent.TimeoutException：IDを持つタスクマネージャのハートビートがタイムアウトしました。

タスクマネージャは、さらに上の理由があるかもしれない、異常なハートビートタイムアウトの直接の原因であります：

プロセスは、それ自体がエラーであってもよいし、終了、または糸RMまたはNMにつかむためのメカニズムの影響により、さらにタスクマネージャログまたは糸RM / NMログを追跡する必要がありました。
プロセスはまだ、接続がタイムアウトする、独自の終了時に、JobManagerは例外フェイルオーバー自己修復後（リソースを再適用して、新しいタスクマネージャを起動します）、失われた接触によるクラスタネットワークの問題を実行しています。
GCプロセスは時間がかかりすぎる、さらに、ログ分析またはメモリに基づいた具体的な理由を局在化するために必要なリソースの不合理な割り当てによって引き起こされるメモリリークやメモリであってもよいです。

▼フェイルオーバー异常3：
のjava.lang.Exception：コンテナが失われたノードにリリース

異常なコンテナは、ノード上のすべてのコンテナが糸RMアクティブリリースになるとAMを通知します実行がYARNクラスタが失われたとマークされているノードで、この例外の後に新しいリソースを、JobManagerフェールオーバーが（自分の回復を受け取ることになります再適用して開始しますタスクマネージャ）、左のタスクマネージャのプロセスがタイムアウト後、自分で終了することがあります。

▼FLINKクラスタ困難なトラブルシューティングのアイデア

まず、ログ分析のJobManager /タスクマネージャの位置に応じて、完全なログを使用すると、デバッグ情報を取得したい場合は、あなたが変更する必要があり、「どのようにログFLINKのアプリケーションビューを完了するには」を参照してくださいlog4j構成JobManager /のタスクマネージャ（$ {FLINK_HOME} /conf/log4j.properties）プロセスの実行がまだ実行されている再送信した後、内部プロセスの状態を垣間見るためにByteman関連するJavaバイトコードツールを使用することが推奨され、詳細な説明はを参照してください：どのように私は、実行中のプログラムにエージェントをインストールしますか？