Hadoopフルリンク監視ソリューション
前言
私は最近のいくつかの文章の中で多かれ少なかれ重要な言葉「監視」に言及した.なぜこの言葉に言及するのかというと、もしあなたが私と同じビッグデータエンジニアであれば、あなたの手の下で大量のクラスタマシンを管理していて、同時にこのクラスタの規模は不定期に拡大して、マシンが多くなると、問題が発生する頻度とタイプが多くなるので、これは、あるマシンのログを人肉で分析して、OK、1台のマシン、2台のマシン、まだ解決方法がありますが、100台、1000台です.もちろんエンジニアがそうすれば、彼は狂うと思います.だからどのようにインテリジェント化をやり遂げて問題を発見して、位置決めの問題、とても肝心なように見えて、最も理想的な結果は、あなたはあなたのクラスタの機械の中で毎日走るjobの各種の指標のデータを持って、それからあなたはマウスを動かして、展示した図形のインターフェースを通じて、急速に問題を発見しました.これもちょうど私が最近やっていることで、効果はまあまあです.以下は私がこの1ヶ月間、私たちの部門のHadoopクラスタに対して行ったいくつかの監視の方面の事で、高大な構造とは言えなくて、私たちはどのように最も簡単な方法で最大化の効果を達成して、みんなに助けをもたらすことを望みます.
2つのトピックを監視
モニタリングの大きな方向は考えましたが、私たちはどのような指標をモニタリングする必要があります.モニタリングを行うには、まずHadoopというシステムロジックを理解し、大体理解すればいいのです.では、私たちはどのようにしていますか.2大方向、マクロレベルとミクロレベルに分けられる.マクロ角度の理解はNodeレベル、トポロジーレベル、DataNode、NameNode、JournalNode、ResourceManager、NodeManager、主にこの5つのコンポーネントであり、これらのノード上の監視データを分析することによって、一般的には遅いノードに位置決めすることができ、あるマシンのネットワークに問題が発生した可能性があり、あるいはあるマシンの実行時間が通常のマシンより大きいなどの類似の問題がある.さっき言ったのは1つの監視方向で、もう1つはミクロレベルで、細粒度化の監視で、userユーザーレベルに基づいて、単一jobに基づいて、単一taskレベルの監視で、このような監視指標は別の大きな方向で、このような監視指標は実際の使用シーンの中で特に重要で、いったんあなたのクラスタ資源が外のユーザーに開放されて使用されると、ユーザー自身はあなたのこのメカニズムの原理を理解していないで、むやみに資源を申請しやすくて、このようなモニタリングの指標は、クラスタ全体の稼働効率を深刻に低下ことを防止するためである.
マクロレベルモニタリング
OK、2つのテーマのモニタリングの方向が確定して、次に具体的な実践案を話して、きっとこれもみんなの関心のあることに違いない.まず、RPCインタフェースなど、最も簡単な方法でデータを直接入手できるかどうかを考えてみましょう.このような方法は確かにあります.私たちはYarnClientのnodeReportの取得方法を使って、このような取得ツールを作りました.次はコアコードです.
総じて言えば、オフラインの統計方式は基本的にこのような方式を採用することができて、lo 4 jを配合して単独であるクラスのログを打ち出して、単一のクラスのファイルは解析を行います.
ミクロレベルモニタリング
ミクロレベルのモニタリングはマクロレベルのモニタリングよりも複雑で、まず同じように一定の理論を理解しなければならない.ただ、Hadoopでは、jobがどのように実行され、どのように転化され、最後の任務が終わるのか.もちろんここで一度にはっきり言うわけにはいかない.今知っている限り、このようないくつかの順位、Application、Job、Task、Container、私たちが言った細粒度モニタリングとは、これらの変数をモニタリングすることを指す.もちろんこれらの指標の量級はとても大きくて、Application応用数とJob数も1日で万を超えることができて、これらのjobが生成したtaskは小さい十数個で、多くは千個以上のtaskで、総じて1日で百万個のtaskが走っている可能性があります.ミクロレベルのモニタリングについては、ログを分析する方法を採用すると、必ずしも適切ではありません.taskの起動情報を大全する場所はないはずです.だから、Hadoop自身のjobのモニタリングを借りる必要があります.JobHistoryです.このクラスには歴史的に実行されたjobの実行情報が保存されています.1つのjobにはtaskの実行されたすべての情報が保存されています.taskにはtask attemptの情報もたくさん含まれています.JobHistory解析jHistoryFile形式のjob情報ファイルをシミュレートして情報の解析を行うことができます.もちろん、jobのPathを自分で見つけて、純粋なテキストの解読をすることができます.この方面の内容は私のこの文章を読むことができて、JobHistoryのjob情報の取得と分析.taskレベルでは、counterを増やしたり、カスタムcounterを増やしたりすることができます.counterの指標は、task Gc回数、full Gc総回数、reduceプロセスの最後に生成されたファイル数など、より多様化することができます.これらの指標は、このtaskの実行の良し悪しを細かく反映し、カスタムcounterをどのように追加するか、私のこの文章を読んでCounter追加をカスタマイズすることができます.もう1つのミクロレベルのモニタリングは、ユーザーのモニタリングに基づいて、取得したtask、jobなどをユーザーによって集約し、ソートし、二次分析を行うことで、問題のユーザーを見つけ、資源を使用する大戸を見つけることができます.
Hadoopソースコードに基づく改造監視アップグレード
このモニタリングの改造は1つのアップグレードで、前者のモニタリングの不足を補充しました.前の2つはすべてオフライン分析に属しているので、事後分析、私たちはもちろんリアルタイムの結果データが必要です.もちろん、私たちはもう1つの類似のリアルタイムデータ収集展示プラットフォームをしません.私たちはJobHistoryインタフェースを直接変更し、ResourceManagerのバックグラウンドにインタフェースを表示し、より多くのページ情報をインタフェースに表示します.正直に言って、現在のHadoopバージョンのいくつかのGangliaモニタリング指標とJobHistotyの表示情報は、本当に限られていて、2つの状況に分けられています.Gangliaには私たちが望んでいるモニタリング目標の上にはありません.だから、私たちは自分で追加するしかありません.JobHistoryには指標が多すぎて、上には共通の情報しか表示されていません.多くはページにクリックしてから見ることができます.そのため、私たちが改善したのは中の情報を出すことです.もちろんこれらの改造は私たちの内部でHadoopのソースコードを改造したものです.
足りないところ
1.この不足点は、hdfs-auditログファイルを通じて、アクセスヒット回数に応じて、対応するコピー数を動的に調整し、読み書き効率を向上させることができる点です.
2.クラスタのすべてのファイルの構造分析、例えばすべてのファイルのサイズ範囲の分布状況、小さいファイルがクラスタの中で大きな割合を占めているかどうか、これはfsimageファイルを分析する必要があります.これは私たちも前にやったことがありますが、ツールを作っていません.ただ、一時的な解析をしました.
3.containerデータの取得、ContainerのデータはJobHistoryにはなく、上にはcontainerIdが1つしかありません.containerの情報も役に立ち、優先度がたくさんあり、追加の情報で機械資源の使用状況などを知ることができます.
ツール共有リンク
次は、分析ツールのコアコードの一部です.
JobHistoryファイル手動分析ツール:https://github.com/linyiqun/yarn-jobhistory-crawler/tree/master/jobHiveSqlAnalyse
NodeManagerタイミングステータス情報取得ツール:https://github.com/linyiqun/yarn-jobhistory-crawler/tree/master/NMTool
JobHistoryファイルプログラム分析ツール:https://github.com/linyiqun/yarn-jobhistory-crawler
HDFS RPCユーザー、IP要求分析ツール:https://github.com/linyiqun/yarn-auditlog-parser
私は最近のいくつかの文章の中で多かれ少なかれ重要な言葉「監視」に言及した.なぜこの言葉に言及するのかというと、もしあなたが私と同じビッグデータエンジニアであれば、あなたの手の下で大量のクラスタマシンを管理していて、同時にこのクラスタの規模は不定期に拡大して、マシンが多くなると、問題が発生する頻度とタイプが多くなるので、これは、あるマシンのログを人肉で分析して、OK、1台のマシン、2台のマシン、まだ解決方法がありますが、100台、1000台です.もちろんエンジニアがそうすれば、彼は狂うと思います.だからどのようにインテリジェント化をやり遂げて問題を発見して、位置決めの問題、とても肝心なように見えて、最も理想的な結果は、あなたはあなたのクラスタの機械の中で毎日走るjobの各種の指標のデータを持って、それからあなたはマウスを動かして、展示した図形のインターフェースを通じて、急速に問題を発見しました.これもちょうど私が最近やっていることで、効果はまあまあです.以下は私がこの1ヶ月間、私たちの部門のHadoopクラスタに対して行ったいくつかの監視の方面の事で、高大な構造とは言えなくて、私たちはどのように最も簡単な方法で最大化の効果を達成して、みんなに助けをもたらすことを望みます.
2つのトピックを監視
モニタリングの大きな方向は考えましたが、私たちはどのような指標をモニタリングする必要があります.モニタリングを行うには、まずHadoopというシステムロジックを理解し、大体理解すればいいのです.では、私たちはどのようにしていますか.2大方向、マクロレベルとミクロレベルに分けられる.マクロ角度の理解はNodeレベル、トポロジーレベル、DataNode、NameNode、JournalNode、ResourceManager、NodeManager、主にこの5つのコンポーネントであり、これらのノード上の監視データを分析することによって、一般的には遅いノードに位置決めすることができ、あるマシンのネットワークに問題が発生した可能性があり、あるいはあるマシンの実行時間が通常のマシンより大きいなどの類似の問題がある.さっき言ったのは1つの監視方向で、もう1つはミクロレベルで、細粒度化の監視で、userユーザーレベルに基づいて、単一jobに基づいて、単一taskレベルの監視で、このような監視指標は別の大きな方向で、このような監視指標は実際の使用シーンの中で特に重要で、いったんあなたのクラスタ資源が外のユーザーに開放されて使用されると、ユーザー自身はあなたのこのメカニズムの原理を理解していないで、むやみに資源を申請しやすくて、このようなモニタリングの指標は、クラスタ全体の稼働効率を深刻に低下ことを防止するためである.
マクロレベルモニタリング
OK、2つのテーマのモニタリングの方向が確定して、次に具体的な実践案を話して、きっとこれもみんなの関心のあることに違いない.まず、RPCインタフェースなど、最も簡単な方法でデータを直接入手できるかどうかを考えてみましょう.このような方法は確かにあります.私たちはYarnClientのnodeReportの取得方法を使って、このような取得ツールを作りました.次はコアコードです.
YarnClient client;
client = YarnClient.createYarnClient();
client.init(new Configuration());
client.start();
List nodesReport = client.getNodeReports();
... /**
* Default AuditLogger implementation; used when no access logger is
* defined in the config file. It can also be explicitly listed in the
* config file.
*/
private static class DefaultAuditLogger extends HdfsAuditLogger {
....
@Override
public void logAuditEvent(boolean succeeded, String userName,
InetAddress addr, String cmd, String src, String dst,
FileStatus status, UserGroupInformation ugi,
DelegationTokenSecretManager dtSecretManager) {
if (auditLog.isInfoEnabled()) {
final StringBuilder sb = auditBuffer.get();
sb.setLength(0);
sb.append("allowed=").append(succeeded).append("\t");
sb.append("ugi=").append(userName).append("\t");
sb.append("ip=").append(addr).append("\t");
sb.append("cmd=").append(cmd).append("\t");
sb.append("src=").append(src).append("\t");
sb.append("dst=").append(dst).append("\t");
if (null == status) {
sb.append("perm=null");
} else {
sb.append("perm=");
sb.append(status.getOwner()).append(":");
sb.append(status.getGroup()).append(":");
sb.append(status.getPermission());
}
if (logTokenTrackingId) {
sb.append("\t").append("trackingId=");
String trackingId = null;
if (ugi != null && dtSecretManager != null
&& ugi.getAuthenticationMethod() == AuthenticationMethod.TOKEN) {
for (TokenIdentifier tid: ugi.getTokenIdentifiers()) {
if (tid instanceof DelegationTokenIdentifier) {
DelegationTokenIdentifier dtid =
(DelegationTokenIdentifier)tid;
trackingId = dtSecretManager.getTokenTrackingId(dtid);
break;
}
}
}
sb.append(trackingId);
}
sb.append("\t").append("proto=");
sb.append(NamenodeWebHdfsMethods.isWebHdfsInvocation() ? "webhdfs" : "rpc");
logAuditMessage(sb.toString());
}
}
#
# hdfs audit logging
#
hdfs.audit.logger=INFO,RFAAUDIT
hdfs.audit.log.maxfilesize=256MB
hdfs.audit.log.maxbackupindex=100
log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=${hdfs.audit.logger}
log4j.additivity.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=false
log4j.appender.RFAAUDIT=org.apache.log4j.RollingFileAppender
log4j.appender.RFAAUDIT.File=${hadoop.log.dir}/hdfs-audit.log
log4j.appender.RFAAUDIT.layout=org.apache.log4j.PatternLayout
log4j.appender.RFAAUDIT.layout.ConversionPattern=%d{ISO8601} %p %c{2}: %m%n
log4j.appender.RFAAUDIT.MaxFileSize=${hdfs.audit.log.maxfilesize}
log4j.appender.RFAAUDIT.MaxBackupIndex=${hdfs.audit.log.maxbackupindex}総じて言えば、オフラインの統計方式は基本的にこのような方式を採用することができて、lo 4 jを配合して単独であるクラスのログを打ち出して、単一のクラスのファイルは解析を行います.
ミクロレベルモニタリング
ミクロレベルのモニタリングはマクロレベルのモニタリングよりも複雑で、まず同じように一定の理論を理解しなければならない.ただ、Hadoopでは、jobがどのように実行され、どのように転化され、最後の任務が終わるのか.もちろんここで一度にはっきり言うわけにはいかない.今知っている限り、このようないくつかの順位、Application、Job、Task、Container、私たちが言った細粒度モニタリングとは、これらの変数をモニタリングすることを指す.もちろんこれらの指標の量級はとても大きくて、Application応用数とJob数も1日で万を超えることができて、これらのjobが生成したtaskは小さい十数個で、多くは千個以上のtaskで、総じて1日で百万個のtaskが走っている可能性があります.ミクロレベルのモニタリングについては、ログを分析する方法を採用すると、必ずしも適切ではありません.taskの起動情報を大全する場所はないはずです.だから、Hadoop自身のjobのモニタリングを借りる必要があります.JobHistoryです.このクラスには歴史的に実行されたjobの実行情報が保存されています.1つのjobにはtaskの実行されたすべての情報が保存されています.taskにはtask attemptの情報もたくさん含まれています.JobHistory解析jHistoryFile形式のjob情報ファイルをシミュレートして情報の解析を行うことができます.もちろん、jobのPathを自分で見つけて、純粋なテキストの解読をすることができます.この方面の内容は私のこの文章を読むことができて、JobHistoryのjob情報の取得と分析.taskレベルでは、counterを増やしたり、カスタムcounterを増やしたりすることができます.counterの指標は、task Gc回数、full Gc総回数、reduceプロセスの最後に生成されたファイル数など、より多様化することができます.これらの指標は、このtaskの実行の良し悪しを細かく反映し、カスタムcounterをどのように追加するか、私のこの文章を読んでCounter追加をカスタマイズすることができます.もう1つのミクロレベルのモニタリングは、ユーザーのモニタリングに基づいて、取得したtask、jobなどをユーザーによって集約し、ソートし、二次分析を行うことで、問題のユーザーを見つけ、資源を使用する大戸を見つけることができます.
Hadoopソースコードに基づく改造監視アップグレード
このモニタリングの改造は1つのアップグレードで、前者のモニタリングの不足を補充しました.前の2つはすべてオフライン分析に属しているので、事後分析、私たちはもちろんリアルタイムの結果データが必要です.もちろん、私たちはもう1つの類似のリアルタイムデータ収集展示プラットフォームをしません.私たちはJobHistoryインタフェースを直接変更し、ResourceManagerのバックグラウンドにインタフェースを表示し、より多くのページ情報をインタフェースに表示します.正直に言って、現在のHadoopバージョンのいくつかのGangliaモニタリング指標とJobHistotyの表示情報は、本当に限られていて、2つの状況に分けられています.Gangliaには私たちが望んでいるモニタリング目標の上にはありません.だから、私たちは自分で追加するしかありません.JobHistoryには指標が多すぎて、上には共通の情報しか表示されていません.多くはページにクリックしてから見ることができます.そのため、私たちが改善したのは中の情報を出すことです.もちろんこれらの改造は私たちの内部でHadoopのソースコードを改造したものです.
足りないところ
1.この不足点は、hdfs-auditログファイルを通じて、アクセスヒット回数に応じて、対応するコピー数を動的に調整し、読み書き効率を向上させることができる点です.
2.クラスタのすべてのファイルの構造分析、例えばすべてのファイルのサイズ範囲の分布状況、小さいファイルがクラスタの中で大きな割合を占めているかどうか、これはfsimageファイルを分析する必要があります.これは私たちも前にやったことがありますが、ツールを作っていません.ただ、一時的な解析をしました.
3.containerデータの取得、ContainerのデータはJobHistoryにはなく、上にはcontainerIdが1つしかありません.containerの情報も役に立ち、優先度がたくさんあり、追加の情報で機械資源の使用状況などを知ることができます.
ツール共有リンク
次は、分析ツールのコアコードの一部です.
JobHistoryファイル手動分析ツール:https://github.com/linyiqun/yarn-jobhistory-crawler/tree/master/jobHiveSqlAnalyse
NodeManagerタイミングステータス情報取得ツール:https://github.com/linyiqun/yarn-jobhistory-crawler/tree/master/NMTool
JobHistoryファイルプログラム分析ツール:https://github.com/linyiqun/yarn-jobhistory-crawler
HDFS RPCユーザー、IP要求分析ツール:https://github.com/linyiqun/yarn-auditlog-parser