LEP(LINUX EASY PROFILING) 是Linuxer之LEP項目組（Barry Song，Mac Xu，陳松等以及陳莉君老師）正在致力於打造的一個開源項目，這是LEP文檔《LEP是什麼,為什麼,怎麼辦》的第一部分。本部分目錄如下：
1.LEP是什麼？
1.1 LEP的架構
1.2 LEP的特點
2.LEP的License
3.為什麼要做LEP？
3.1 三類Linux開發者與LEP對他們各自的作用
3.2 第一類Linux開發者調試方法
3.3 第三類Linux開發者調試方法
4.LEP類似項目以及LEP的優勢
4.1 netdata
4.2 zabbix
4.3 munin
4.4 帶插件的Eclipse
5.LEP的當前狀態
5.1 代碼託管
5.2 支持平臺
5.3 目前功能
5.3.1 概況視角
5.3.2 CPU視角
5.3.3 內存視角
5.3.4 I/O視角
5.3.5 perf視角
5.4 目前缺陷
LEP項目組歡迎開源愛好者加入和參與。關於項目的最新演講：
【終南山.內核問道】Linux性能剖析的可視化
LEP的全稱是Linux Easy Profiling（Linux易用剖析器），核心特點在於Easy（簡單），主要功能在乎Profiling（剖析）。LEP的網址是http://www.linuxep.com，網站基於Docker部署，代碼倉庫位於：https://github.com/linuxep/linuxep
LEP的設計目標是：便利Linux的程式設計師，以最快最直接的方式，定位到系統裡面一些bug的源頭，以及一些性能瓶頸的原因。
Linux有很多現成的調試和剖析工具，比如top、vmstat、iotop、perf、valgrind、powertop、free、pmap、slabtop等，這些工具通過讀取/proc、/sys，分析硬體的PMU（Performance Monitor Unit）數據、監控內存的申請釋放以及讀寫等手段，獲知單一進程或者系統的運行狀態，以及進行故障分析。LEP除了在功能上是這些工具的超集以外，在可視、交互、深度分析、數據比對、場景貼合等角度對這些工具進行進一步的增強。
LEP實際上是一個all-in-one的調試工具，它的軟體架構如圖1。LEP與Linux現有工具重大不同的地方是：被監控的伺服器或者開發板只需要部署LEPD(LEP Daemon)，該程序完全用C語言，只需要完成基本的數據採集功能，因此它能最小化對被監控系統本身的影響。數據的分析和處理，都移動到了WEB服務LEPV（LEP Viewer）和瀏覽器一端。LEPD採集被監控目標的運行數據，這些數據被WEB服務端LEPV通過JSONRPC請求獲得，LEPV以Python對從LEPD獲得的原始數據進行有針對性的加工，再發送給瀏覽器，瀏覽器用Javascript等形式，把LEPV加工過的數據，以各種豐富的圖形進行顯示。
這種架構的主要好處是：LEPD和LEPV分離，這樣使得LEPD易於部署在資源貧乏的嵌入式電腦板上（當然更加可以運行在伺服器上），而LEPV一般則運行在比較強壯的X86 PC上。當然，LEPD和LEPV雖然分離，在實際部署的時候，也可以部署於同一個X86 PC。因此，LEP也可以用於非網絡環境下的單機自身監控。
值得一提的是，LEPV目前基於Docker進行部署，這對LEPV的安裝和使用提供了很大的幫助，避免了不同環境下、不同用戶要安裝各種依賴的底層工具的繁瑣動作。LEPV可運行於直接支持Docker的Linux平臺以及間接支持Docker的MAC OS和Windows平臺。
圖2演示了LEP的一個典型的數據流程。運行於被監控系統的LEPD讀取/proc/loadavg數據，這些數據沒有格式，是原始的，類似「2.58 2.25 2.31…」，而LEPV收到這些數據後，將其進行語義加工為last1、last5、last15這種過去1分鐘、5分鐘、15分鐘系統平均負載，瀏覽器獲取這些數據後，繪製為3條生動活潑的動感曲線。
圖2 LEP的數據流程
1.2 LEP的特點LEP在功能角度上，全面集成了Linux的多數常用工具，但是在調試和剖析能力上，更加「給力」，它進行了進一步的高強度增強，這些增強主要表現在6個方面：
1. LEP是all-in-one的。意味著有了LEP後，用戶不用再滿世界去尋找和集成眾多的工具。由於LEP本身的絕大多數工作並不集成在被監控的目標，被監控的目標僅僅需安裝一個最簡單的daemon LEPD做後臺數據採集，因此，這種all-in-one的集成本身也不會增加被監控者文件系統的footprint。
2. LEP是可視化的。當我們用top命令去觀察CPU利用率、平均負載等的時候，top進行周期性的刷新，它顯示的只是此一時刻的數據，因為沒有圖形，所以它無法顯示變化，而LEP則可以以時間為X軸，數據為Y軸，顯示系統一段時間的狀態變遷，如圖3。
圖3 LEP可顯示變化
3. LEP是可交互的。由於界面豐富，因此，用戶可在瀏覽器網頁上面，對監控本身的頻率、數據類型等進行設置，以及進行方便的數據過濾，譬如在Linux的眾多進程中，設置只關心某些進程。以圖4為例，在進程CPU利用率的監控窗口，我們可以通過簡單的輸入進程名load，過濾掉我們不關心的進程。
4. LEP帶預警和分析能力。目前的Linux命令，更多的只是顯示數據，本身分析和預警能力不足。比如free命令，它顯示系統的內存，但是當系統出現內存洩漏時，它徹底缺乏提示和預警能力。與之不同的是，LEP可持續跟蹤系統，因此，發現內存洩漏等異常狀況後，可給用戶預警，並進一步給出更深的提示，比如提示內存洩漏的源頭是slab、vmalloc還是用戶態應用程式。
5. LEP具備數據存儲能力。LEP可以將採集的歷史數據進行保存，並在保存後進行檔案調取。程式設計師經常會修改代碼，並進行修改代碼前和修改代碼後的運行性能比對。歷史數據與當前數據的比對，可便利程式設計師獲知代碼變更對系統真實的影響。我們姑且稱呼上述比對為時間比對，那麼，另外一種可能的比對就是空間比對，比如程式設計師會比對同樣的軟體，運行於不同的硬體平臺時性能差異的不同。LEP的此一能力，可幫助程式設計師摺疊時空。
6. LEP可深度貼合用戶場景。使用LEP工具，除了可以依據Linux CGroup（ ControlGroups ）進行監控外，用戶可依據應用場景，進行進程的人工幹涉分群，比如，對於多媒體播放場景，把播放相關的service和app歸於一個進程群，並觀察此一群的運行狀態和資源佔用。
LEP是基於GPL v2發布的，這意味著任何人都可以獲得其開源的原始碼，並部署使用之，但是對其本身的修復和提高，也必須再次開源。LEP也歡迎與廠商合作，並可能以功能插件的形式，對廠商的部分原始碼，使用商業license，從而對這部分代碼進行閉源。
主要的目標還是解決現實的問題，加快問題的調試和定位過程，減輕程式設計師的痛苦，從而提高生產力。
我們大體認為在Linux上從事開發的程式設計師，依據其與Linux平臺本身的親密度可分為3類：
1. Linux專家，類似遊泳健將。
2. 熟悉Linux的開發者，類似會遊泳的人。
3. 不熟悉Linux平臺本身知識的開發者，類似不會遊泳或者只會狗爬式遊泳的人。
LEP項目堅決反對程式設計師的鄙視鏈，提倡以平常心以公平心看待不同的技術領域。遊泳健將不能鄙視狗爬式，雖然別人遊泳不行，在體育界不好混，但是說不定人家戲演地好，在演藝圈成功了。技術上倡導百萬齊放，行行出狀元。
根據著名的二八定律，我們認為有20%的程式設計師，掌握了80%的Linux知識；而有80%的程式設計師，只掌握了20%的Linux知識。第二、三類Linux用戶數量遠大於第一類Linux用戶。
LEP的主要目的是給第二、三類Linux開發者扔一個救生圈防止他們淹死，同時這個救生圈，也可以給第一類Linux用戶節省體力，可以縮短他們的調試周期。所以，它對第二類和第三類，達到了救命或者續命的效果，對第一類，更多的是達到錦上添花的作用。
如圖5，一旦系統出現問題，Linux專家級開發者，由於心中有丘壑，他的需求很可能只是，敲一些命令，然後看看命令的結果，尋找調試方向，所以，他更多的需求是「我看看」；熟悉Linux的用戶，通過冰冷的命令輸出，可能很難窺探到系統的運行秘密，但是如果能以圖形顯示，他大概能夠知道個七七八八，所以他的訴求，更多的是「幫幫我」；而對於第三類Linux開發者而言，你可能就必須直接給他指出問題出在哪裡，他的訴求是「救救我」。
圖5 三類Linux用戶以及他們的訴求
下面我們以一個內存洩漏為例，看看第一類工程師和第三類工程師的區別。故事的背景是，某使用Linux做產品的公司A，從開發板的製造商買了一批開發板，而後在其提供的Linux之上，增加了一個Qt的應用程式。但是，不幸的是，此開發板的某內核驅動有極其緩慢的slab區域（以kmalloc進行申請）內存洩漏。下面第一類工程師和第三類工程師同時開始調試這個bug。
第一類開發者，理解進程內存消耗的VSS、RSS、PSS、USS概念，並理解內核空間的slab、vmalloc以及用戶空間的malloc都可能是堆內存的洩漏源頭。他的調試過程如下：
1. 以free命令跟蹤系統，發現系統free內存隨著時間遷移而持續減小，他確立內存洩漏存在；
2. 懷疑自己寫的Qt應用程式有內存洩漏，於是以類似smem工具，持續跟蹤自己寫的Qt應用的USS，經過一段時間的觀察，它發現Qt應用本身耗費的內存沒有變大，排除自身問題；
3. 持續觀察/proc/meminfo，跟蹤slab和vmalloc區域的變化，發現slab區域隨著時間遷移增大，確立內核空間kmalloc類似行為有洩漏；
4. 查看/proc/slabinfo，並使能內核kmemleak類似選項，最終定位到洩漏的那一行原始碼。
結果上述4個步驟，第一類開發者比較輕鬆地修復了這個內核空間內存洩漏的bug。
3.3 第三類Linux開發者調試方法第三類開發者沒有這麼幸運。他的調試步驟是：
1. 以free命令跟蹤系統，發現系統free內存睡著時間遷移而持續減小，他確立內存洩漏存在；
2. 懷疑自己寫的Qt應用程式有內存洩漏，懷疑Qt本身有內存洩漏；升級Qt的版本，反覆查看自己的代碼；
3. 懷疑自己寫的Qt應用程式有內存洩漏，懷疑Qt本身有內存洩漏；再次升級Qt的版本，反覆查看自己的代碼；
4. 懷疑自己寫的Qt應用程式有內存洩漏，懷疑Qt本身有內存洩漏；降級Qt的版本，反覆查看自己的代碼；
5. 懷疑自己寫的Qt應用程式有內存洩漏，懷疑Qt本身有內存洩漏；再次降級Qt的版本，反覆查看自己的代碼；
6. 懷疑自己寫的Qt應用程式有內存洩漏，懷疑Qt本身有內存洩漏；升級Qt的版本，反覆查看自己的代碼；
7. …
光陰似箭日月如梭，第三類程式設計師，在不斷地重複試錯中「鬼打牆」，耗盡了青春，也辜負了年華，一晃就過去了大半年。
第一類程式設計師這個時候就會鄙視第三類程式設計師，但是，殊不知，第三類程式設計師，也有鄙視第一類程式設計師的理由，因為「術業有專攻，聞道有先後」，彼此關注的領域並不一定一樣。
對於第三類程式設計師，如果他在調試的第一步就有了LEP，那麼，LEP的數據採集和深度分析能力，將可以直接提示它問題出在內核的slab，直接提示其進一步的調試方向。
netdata（如圖6）是一款 Linux 性能實時監測工具，提供web界面的界面視角，是github上的2016年度星標項目，項目網址：http://netdata.firehol.org/
圖6 netdata的用戶界面
netdata以5分鐘為單位，持續刷新系統的運行情況。netdata的web端部署於被監控的平臺。它目前的局限性有三：
1. 不具備歷史數據分析能力（只有5分鐘）
2. 不適合部署於嵌入式系統，web服務本身的開銷大
3. 更大地是面向運維，缺乏對開發人員的支持
LEP在具備比netdata更強大功能的前提下，也要解決netdata上述的3個問題，LEP也可更多的面向程式設計師。
zabbix（如圖7）是一個基於WEB界面的提供分布式系統監視以及網絡監視功能的企業級的開源解決方案。zabbix能監視各種網絡參數，保證伺服器系統的安全運營；並提供靈活的通知機制以讓系統管理員快速定位/解決存在的各種問題。項目網址：https://www.zabbix.com
圖7 zabbix的用戶界面
Zabbix仍然是面向運維的，缺乏調試和分析能力。但是，其「靈活的通知機制以讓系統管理員快速定位/解決存在的各種問題」特徵這部分值得LEP學習。
munin（如圖8）是用於Linux系統的監控軟體，munin可以監控系統的各項數值之外，最大的好處是可以自己編寫插件自定義監控需要的數值。munin除了可以監控結果，也可以設置報警。項目網址為：http://munin-monitoring.org/
圖8 munin的用戶界面
munin具備性能分析能力，」設置報警」和「自定義監控」數據等特徵都值得我們學習，但是它仍然缺乏面向程式設計師的深度分析能力，也不適合嵌入式系統。
4.4 帶插件的EclipseEclipse IDE（IntegratedDevelopment Environment，集成開發環境）提供了一個類似Visual Studio的集成開發環境。它可以集成一些插件，類似：
此方法的主要問題在於實施難度較大，Eclipse本身過於龐大，對嵌入式的支持也不太完善。安裝了插件的Eclipse更像是一個工具大熔爐，它仍然需要用戶知道每個工具以及每個工具的具體用法，另外IDE也缺乏持續監控和直接的預警能力。
就易用性角度，LEP直面狗爬式遊泳人員，可以進一步降低開發者對Linux本身知識的了解程度的要求。
目前LEP的代碼託管於github上面，地址：https://github.com/linuxep，代碼倉庫中LEPD和LEPV是分離的。分別位於：
https://github.com/linuxep/lepd
https://github.com/linuxep/lepv
下面演示在64位Ubuntu機器上，同時運行LEPD和LEPV，最後用瀏覽器監控本機或者ARM板的操作流程：
1.下載、編譯和運行LEPD
git clone https://github.com/linuxep/lepd.git
baohua@ubuntu:~/lep/lepd$ make
baohua@ubuntu:~/lep/lepd$ sudo ./lepd--debug
[sudo] password for baohua:
注意，如果要編譯LEPD的ARM版本，命令為：
baohua@ubuntu:~/lep/lepd$ make ARCH=arm
編譯後將LEPD拷貝入ARM電路板或者Android手機即可。
2.下載、編譯和運行LEPV
git clone https://github.com/linuxep/lepv.git
baohua@ubuntu:~/lep/lepv$ ./buildDockerImage.sh
baohua@ubuntu:~/lep/lepv$./runDockerContainer.sh
3. 開啟瀏覽器
訪問127.0.0.1:8889
在彈出的對話框設置監控本機：
如果是監控ARM電路板或Android手機，填寫它們的IP位址。
Enjoy：
我們已經在ARM 32電腦板、ARM 64位Android手機和雙核、四核X86上部署過LEPD，並以LEPV進行數據跟蹤和採集。
目前LEPV僅支持運行於X86 64位機器上，32位機器暫時不支持。
目前LEP具備概況、處理器、內存、磁碟（I/O）和Perf五個視角。
5.3.1 概況視角概況視角顯示CPU、內存、I/O總體的狀態：
5.3.2 CPU視角CPU視角顯示各個進程的CPU利用率，多核下負載均衡，IDLE，每個核的CPU佔用情況，IRQ+SoftIRQ的比例等：
上述IRQ+SoftIRQ視角，對指導中斷負載均衡、SoftIRQ負載均衡（網絡下RPS——ReceivePacket Steering等），有很強的指導意義。
5.3.3 內存視角內存視角顯示系統的內存消耗（used、free、page cache等），以及每個進程的內存佔用比例，進程的VSS、RSS、PSS和USS等信息：
5.3.4 I/O視角目前可顯示I/O隊列情況以及每個進程的I/O訪問流量：
5.3.5 perf視角目前可顯示系統運行時，基於symbol的時間分布，類似perf top命令的功能：
目前的缺陷及改造方向：
1. 監控是瀏覽器觸發的，如果瀏覽器不點擊開始，不會開始。改造目標：自動監控，無論瀏覽器連接不連接。所以LEPV需要後臺，後臺設置後就連續從LEPD採集數據。
2. 沒有資料庫，沒有歷史數據。未來考慮除了顯示最近五分鐘視圖以外，增加類似股市的日線圖、周線圖、月線圖。另外，需要增加採集數據和分析後數據的保存與讀取能力。
3. 功能性缺失，比如中斷、軟中斷、上下文切換次數，基於cgroups的CPU、內存、I/O分析。改造方向：增加中斷、軟中斷、上下文切換、swapin、swapout、slab、vmalloc等的視角，增加cgroups的分析視角。
4. 沒有系統的測試以及剖析LEPD本身對監控目標的消耗。改造方向：增加測試案例，執行Q/A，執行LEPD本身對監控目標性能影響的報告。
5. 深度分析能力仍然不夠。比如，我們只是單純的顯示負載，沒有辦法提示用戶目前負載重，沒有辦法監控到內存洩漏後進行提示。界面上也缺乏對用戶適當的提示，對於初級用戶來說，還是看不懂。
6. 缺乏中文英文的自動切換，目前暫時只有中文版。改造方向：默認根據瀏覽器語言，選擇英文、中文，提供用戶設置的能力。
7. 以監控為主，控制能力不足。理想上面，我們可以對目標監控系統進行一定的配置，比如設置某個進程的nice，可以在top裡面點右鍵來設置；比如，我只想監控某個進程，某個進程的所有線程等。
本文未完待續 >>>