衆所周知，storm 已經是業界主流的流時處理架構，Storm 被廣泛應用于實時分析，線上機器學習，持續計算、分布式遠端調用等領域。目前無論是内部還是外部論壇介紹原理的文檔都比較多，但主要都是從運作機制和原理方面的介紹，在 UI 方面的介紹甚少，今天我試着向大家介紹一下 storm ui，一方面可以讓大家了解一下 storm 的機制，另外也可以讓大家更好的使用好 storm ui 協助大家自助解決使用過程中的問題。
資料上報流程：worer/supervisor/nimbus 會定時上報統計資訊到 zk
資料展現流程：ui 調用 nimbus 的服務從 zk 中取出資料進行分類聚合彙總，然後展示到前端
通常我們要真正了解一個事物，通常都會從來龍去脈進行解剖；了解 storm ui 也是，想了解 storm 有什麼資料，那麼先去了解 storm 有哪些動作就事半功倍了，以下是 storm 中 worker/supervisor/nimbus 的基本操作及對應的資料類型，左邊為操作，右邊為資料。
spout：
emit：向下遊送出 tuple，對應的統計資料為 emit/transfer，emit=emit 執行數量，transfer=emit 執行數量 * 下遊 bolt 個數
ack： 成功流轉之後的操作，對應的統計資料為 ack/complete-lantency，ack=成功流轉次數 complete-lantency=成功流轉平均時間
fail：失敗流轉之後的操作 對應的統計資料為 fail，fail=失敗流轉次數
bolt：
execute：接收到上遊資料之後的執行操作 對應的統計資料為 execute/execute-lantency，execute=執行次數 execute-latency=平均執行時間
emit：與 spout.emit 相同
ack：bolt 完成 execute 主動發起的 ack 操作，對應的資料為 ack，ack=執行次數
通常資料的統計會對系統的性能造成一定的影響，那麼 storm 中為了平衡這種影響，采取了抽樣的方式進行上報資料； storm 中把此值預設為 0.05，即每執行 20 次則執行一次資料累加(value = 20)，當然我們也可以修改抽樣的配置值為 1，那麼就是逐條上報了。
node add：增加 supervisor 節點，對應的會向 zk 注冊一條 supervisorinfo 資訊，包含：host all-slots used-slots uptime version resource
node del：删除 supervisor 節點，那麼會從 zk 中删除一條 supervisorinfo 資訊
worker startup：啟動了一個 worker，那麼 supervisorinfo 的 used-slots( 1) resource 會發生變化
worker shutwodn：關閉一個 worker，那麼 supervisorinfo 的 used-slots(-1) resource 會發生變化
node add：增加一個 nimbus 節點，那麼會向 zk 注冊一條 nimbus-summary 資訊，包含：host port isleader uptime version
node del：删除一個 nimbus 節點，那麼會從 zk 中删除一條 nimbus-summary 資訊
leader change：leader 發生變更，那麼對應的 nimbus-summary 中的 isleader 發生變化
在上述的第二點中已經說明了基本操作及對應的資料類型，那麼在頁面中就可以很好的對應了，先從整體視圖來看看我們 storm ui 有什麼資訊，此 storm ui 為我們數平自己開發維護的 jstorm，一方面用 tab 頁把 topology summary/nimbus summary/supervisor summary/nimbus configuration 分類展示，另外加了很多快捷連結入口用于檢視到關注的内容，以及把常用的 kill topology 操作移動到首頁。
1、首頁-初始化
cluster summary： 展示叢集的整體資訊，包含版本、線上時間、啟動時間、管理的 supervisor 個數、總的節點數、已用節點數、空閑節點數、在運作的 executor/task 數
topology summary： 展示所有正在運作的 topology 資訊，包含名稱、id、狀态、線上時間、送出時間、占用的 worker 數、擁有的 executor 數、擁有的 task 數、快捷關閉按鈕
2、首頁-supervisor summary： 展示所有的 supervisor 節點，包含 id、主機名稱、線上時間、啟動時間、總的 worker 節點數、已經使用的 worker 節點數
3、首頁-nimbus summary： 展示所有的 nimbus 節點，包含主機名稱、端口号、是否 leader、版本号、線上時間、啟動時間
4、首頁-nimbus configuration： 把配置資訊以清單展現出來
5、topology 詳情頁
topology summary：與首頁對應的 topology summary 對應。
topology actions：用于 topology 的一些操作：激活、登出、重配置設定、debug/stop debug、修改日志級别。
topology stats：按時間視窗展現統計資料：十分鐘表示近十分鐘的統計，3 小時表示近 3 小時的統計等。
spouts：spout 元件的統計資料，資料含義在第二點的資料類型已有說明。
bolts：bolt 元件的統計資料，資料含義在第二點的資料類型已有說明。
topology visualization：展示 topology 的拓撲結構圖及資料傳輸情況。
topology configuration：展示 topology 的配置資訊。6、component 詳情頁
component summary：展示 component 的 id、executor 個數、task 個數、debug 日志。
component actions：提供 component 的 debug/stop debug 操作。
spout/bolt stats：按時間視窗展示資料，資料含義在第二點的資料類型已有說明。
input stats：輸入流資料，包含上遊 component、stream、執行時間、執行次數、bolt 正常流轉的處理時間、ack 數、失敗數。
output stats：輸出流資料，包含 stream、emit 個數、transfer 個數。
executors：executor 資料，包含 id，線上時間、所在主機及端口、emit 個數、transfer 個數、執行時間、執行個數、成功流轉直接、ack 個數、失敗個數。
profile and debugging：用于診斷 worker 的運作情況，執行 jstack/jmap 等操作對 jvm 進行檢測輸出到檔案，供使用者下載下傳打開檢視 jvm 的運作情況。
了解完上面的介紹，相信都會有大概的一些印象，但僅有那些資訊是否已經足夠呢？我們不妨從使用者的角度來思考一下：
1、 每次送出 topology 都要去登陸到背景去送出，很麻煩，是否可以在 UI 中提供頁面去送出呢？—增加送出 topology 頁面
2、一個 topology 的 worker 分布在哪些節點？每個 worker 都有哪些 executor？每個 worker 的 jvm 記憶體情況、程序記憶體情況？—增加 worker 詳情頁面
3、 一個 supervisor 有哪些啟動了的 worker？ 每個 worker 有哪些 executor？
我們在使用 storm 的過程中，會不定時的出現一些問題，熟練 storm ui 可以更好的協助自己分析解決問題。以下是常見的幾個例子：
1、 上遊發的次數與下遊接收執行的次數不一緻，怎麼辦？
首先了解 topology 的資料類型，可參照第二點的說明，然後進入 topology/component 詳情頁面進行對比。
2、好不容易寫了一個 topology，送出之後，發現一直沒有資料輸出，可能是啟動失敗了，怎麼辦？
點選 nimbus summary 的 port 連結檢視 nimbus 日志，檢視任務是否配置設定成功；
點選 supervisor summary 的 host 連結 supervisor 日志，檢視 supervisor 是否有啟動相應的 worker ；
點選 topology summary 的 num workers 連結到 worker 頁面，選擇對應的 component 檢視 worker.log，檢視 worker 是否有正常啟動。
3、下遊說發送的資料與預期不一樣，我想看看 topology 究竟傳輸的是什麼資料，有沒辦法看？
想檢視整個 topology 中各個 component 傳輸的 tuple 資料，那麼在 topology 詳情頁面啟動 debug，輸入百分比參數，那麼 topology 會按照比率把 tuple 資訊輸出到 events.log，然後在 component 詳情頁中點開 events.log 連結就可以看到傳輸的資料是什麼。當然也可以選擇指定的 component 進行 debug，那麼就隻對一個 component 進行日志輸出。
4、 寫的 topology 加了很多 debug 級别日志輸出，但是發現 storm 的日志級别是 error 級别的，自己想看的日志無法輸出啊，怎麼辦？好捉急啊！！
ui 中提供了修改日志級别的操作，隻需要點兩下修改一下日志級别為 debug，日志就源源不斷輸出到 worker.log 了，好歡喜。
5、 送出的 topology 在運作過程中，發現 worker 數不夠用了，某個元件積壓太多了，想加多幾個 worker 怎麼辦？
在 topology 詳情頁面點選 rebalance 輸入相應的參數就可以重新配置設定了。
6、 發現幾個 worker 的 CPU 占用好高啊，該怎麼辦？
進入 component 詳情頁面進行 profile 操作，執行 jstack 擷取 jvm 運作堆棧，打開 jstack 檔案進行分析。