對于使用Hadoop進行日志分析等工作的開發者來說，相信一直都面臨著一個非常頭疼的問題。那就是：對hadoop的mapreduce作業，在分布式集群上進行單個task的單步debug跟蹤調試無法辦到。只能在本地進行調試，然后提交到集群中運行，但是集群中如果某個task總是失敗，要對這一個task進行單步跟蹤就非常困難。其實原因很簡單，因為當把作業提交到hadoop 集群進行運行的時候，你事先根本就不知道那個map或者reduce的task會被分配到哪個tasktracker上執行。所以過去的兩年里，寫 mapreduce應用的工程師們一直面臨著這個懸而未決的問題。只能通過在程序中加日志，并在作業完成或者失敗后追蹤日志來進行問題定位。無法達到對程序象調試單機程序一樣的進行調試。

其實在hadoop中，有一個好東西，利用這個好東西，就可以實現在集群中對某個task進行單步調試的需求。這個東西就是 IsolationRunner。IsolationRunner是一個小工具，能夠在tasktracker機器上，重新單獨運行失敗的task，這樣對于某些大作業(比如job的輸入有100TB)，如果因為某一個task重復失敗而導致整個job失敗，就不用連續不斷的提交job，進行復現，然后定位某個task失敗的原因，這樣做的代價就會非常的大。如果能夠對失敗的task進行單獨執行，那么要定位問題的原因代價就變得很小，對工程師來說也非常的方便。

要想對失敗的task進行單獨重跑，肯定是有前提的，大家知道，對于map而言，其輸入數據是來自分布式文件系統(通常是HDFS)中輸入數據的某個 split，所以如果想要重跑map task，其輸入數據就需要被保留下來。同樣對于reduce而言，其輸入是從所有map的中間結果shuffle到該reduce的數據，如果想要重跑 reduce task，這些數據也就需要保留下來。所以為了提供對失敗的task進行單獨重跑的功能，作業執行過程中的中間結果，或者每個map的輸入數據對應的 split數據，就需要被保留下來。為此hadoop提供了一個作業的配置選項：keep.failed.task.files，該選項默認為 false，表示對于失敗的task，其運行的臨時數據和目錄是不會被保存的，這也是hadoop在支持這項功能前默認的做法，因為如果失敗的task的臨時文件和目錄被保留的過多，會占據tasktracker上過多的磁盤空間和文件數，造成磁盤浪費。而當將 keep.failed.task.files選項設置為true(注意：該配置選項是一個per job的配置)，那么hadoop在執行該job時，當發生map fail或者reduce fail時，就會將task能夠單獨重跑的所有環境都保留下來，比如task運行時對應的job.xml，map input對應的split.dta文件，或者reduce的輸入file.out文件。這樣，要重跑一個map或者reduce task的環境就已經具備。

如何重跑：

當fail的task環境具備以后，就可以對單獨的task進行重跑了。重跑的方式為:

上到task出錯的tasktracker機器上

在該tasktracker上找到fail的task運行時的目錄環境

在 tasktracker中，對于每一個task都會有一個單獨的執行環境，其中包括其work目錄，其對應的中間文件，以及其運行時需要用到的配置文件等

這些目錄是由tasktracker的配置決定，配置選項為:mapred.local.dir. 該選項可能是一個逗號分隔的路徑list，每個 list都是tasktracker對在其上執行的task建立工作目錄的根目錄。比如如果mapred.local.dir=/disk1 /mapred/local,/disk2/mapred/local，那么task的執行環境就是mapred.local.dir /taskTracker/jobcache/job-ID/task-attempt-ID

找到該task的執行工作目錄后，就可以進入到該目錄下，然后其中就會有該task的運行環境，通常包括一個work目錄，一個job.xml文件，以及一個task要進行操作的數據文件(對map來說是split.dta，對reduce來說是file.out)。

找到環境以后，就可以重跑task了。

cd work

hadoop org.apache.hadoop.mapred.IsolationRunner ../job.xml

這樣，IsolationRunner就會讀取job.xml的配置(這里的job.xml相當于提交客戶端的hadoop-site.xml配置文件與命令行-D配置的接合)，然后對該map或者reduce進行重新運行。

到這里為止，已經實現了task單獨重跑，但是還是沒有解決對其進行單步斷點debug。這里利用到的其實是jvm的遠程 debug的功能。方式如下：

在重跑task之前，export一個環境變量：export HADOOP_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8888"

這樣，hadoop的指令就會通過8888端口將debug信息發送出去

然后在自己本地的開發環境IDE中(比如 eclipse)，launch一個遠程調試，并在代碼中打一個斷點，就可以對在tasktracker上運行的獨立map或者reduce task進行遠程單步調試了。

以下是圖解示意，這里采用最簡單的wordcount來進行示例。在wordcount的輸入文件中，加入一行數據，如“guaishushu”，然后修改wordcount的Mapper實現，如下：

這樣修改以后，由于數據中有 “guaishushu”的字符串，并且該行一定會被落到某個map的輸入中去，然后代碼中當讀到”guaishushu”的時候會拋出 IOException異常，所以該job在運行過程中就肯定會有一個task失敗。然后，在提交作業時，將 keep.failed.task.files設置為true，并按如下程序提交，job就開始運行：

在jobtracker監控web頁面上找到 task失敗的機器，并確保keep.failed.task.files為true

上到該tasktracker，并找到該 task運行環境

進到該task運行環境的work目錄(如果沒有，可以自己創建

export jvm遠程調試環境變量

運行IsolationRunner

在自己的開發機IDE環境中launch一個遠程調試進程

單步跟蹤示意

總結

以上是生活随笔為你收集整理的linux task进程跟踪,如何对Hadoop作业的某个task进行debug单步跟踪的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。