今天這篇文章要跟大家介紹的是 kubectl 一個好用的 plguin, flame，這個名稱就是大家所熟悉的火焰圖，所以長話短多。 kubectl flame 用來幫助維運人員針對任何已經運行的 Container 透過不同的 proflier 來進行效能分析，並且畫出相對應的火焰圖供研究。
對於維運人員來，透過 profiling 分析程式碼中存在的效能瓶頸是個非常常見的行為，有效的工具能夠幫助開發人員更快速的找到效能瓶頸並加以修正，而火焰圖則是一個非常知名的視覺化方式，將這些 profiling 的結果透過 stack 的方式顯示出來，讓開發人員一目了然地找到痛點。
雖然 profiling 聽起來如此強大，但是要於 Kubernetes 中針對運行的應用程式進行效能分析並不是如此簡單，主要是 profiling 通常會伴隨兩個條件
1. 程式碼需要修改，加入相對應的參數或是函數才能夠正確地將 function symbol 給顯示出來
2. 針對正式生產環境的除錯同時也會帶來效能影響的取捨，為了分析應用程式的效能意味者 profiler 必須要針對應用程式進行取樣與分析，這些都會帶整體效能上的影響。
更重要的事，如果今天要對一個已經運行的應用程式加上 profiling 需要的修改與參數，代表整個 Pod 會需要重啟來部署新版本的 Container Image。這類型的重啟可能會導致效能問題消失，整個除錯過程變得非常困難。
Kubectl flame 透過部署一個全新的 Container 到目標 Container 所在的節點上，同時透過 PIDNamespace 與 MountFilesystem 等方式來達到透過外部應用程式來幫忙進行 profiling，不過要注意的是不同的 profilter 所支援的程式語言不同。
有興趣的可以參考下列文章，甚至可以使用 pyroscope 這套 continuous profiling platform 來達成長時間的效能分析。
https://medium.com/swlh/introducing-kubectl-flame-effortless-profiling-on-kubernetes-4b80fc181852
pyroscope 在 [心得] 使用pyroscope adhoc 加速找到效能瓶頸- 看板Soft_Job 的美食出口停車場
部落格: https://bit.ly/pyroscope-adhoc
Youtube: https://www.youtube.com/watch?v=3WfR46Q_9Kk
大家在開發軟體時，會快速迭代專案時程跟需求，功能越多，系統就會開始出現效能上的
瓶頸，而最快的解決方式就是先垂直擴展，把 CPU 跟記憶體先往上加，但是這是治標不
治本，所以之前有推薦大家一套如何在服務執行時，快速找到哪個地方執行較慢，請參考
之前的文章『即時效能分析工具 Pyroscope』，Pyroscope 目前支援了很多語言，像是
Go, Python, Java, Ruby, Rust, PHP 及 .Net，如果你想要快速在本地端找到效能瓶頸
，請繼續將本篇看完。底下會用 Go 語言實際範例教大家。
## 為什麼要用 adhoc profiling
Pyroscope 近期內推出 adhoc profiling 功能，大家想看看為什麼官方要推出此功能。
原本 Pyroscope 推出此開源平台可以讓開發者在平台上線時，快速從時間點找到效能瓶
頸的地方，但是移動到該時間點時，你會看到很多雜訊，而要持續檢測，開發者需要一直
進行測試，而這方式無法在本地端快速驗證出來。
所以 Pyroscope 目標是推出 adhoc profiling 功能，讓開發者可以在本地透過
Pyroscope 快速驗證及找到效能瓶頸，而不用運行一整個服務，只要將特定的流程抓出來
透過 Script 方式將效能數據產生出來，並且透過 Pyroscope CLI 直接讀取看數據。
(中間許多代碼，請直接上 Blog 文章)
## 線上 Profiling 服務
如果連本地端都不想安裝任何環境，可以透過底下兩個線上服務來完成。
* Upload and Share Interactive Flamegraphs[1]
* Playground[2]
可以將有效能問題的程式碼放到 Playground 上，並分享給團隊其他同仁，直接線上修改
測試即可，其實跟 Go 提供的 Playground 差不多意思。
[1]: https://flamegraph.com/
[2]: https://playground.flamegraph.com/playground
## 心得
有了這個功能幫助挺大的，尤其是想在本機端做一些效能上分析，雖然有 pprof 可以使
用，但是沒有好的 UI 介面，還是很難縮短除錯時間，而有了 adhoc 功能，還可以將數
據分享給其他同事一起來幫忙。畢竟服務正式上線後，不會將 pyroscope 功能啟動，免
得服務受到效能上的影響，而在測試站就會隨時監控，搭配 Prometheus + Grafana 找出
特定時間點效能變化。
上面第一段有提到，目前支援多種不同語言，大家在本地端就可以快速測試不同寫法帶來
不同的效能，而不是要將代碼推上機器後才可以驗證，真的縮短蠻多時間的。也可以在找
到問題同時，先將 HTML 檔案附件在 Issue Tracking 系統上。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.110.136.13 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1647004264.A.600.html
... <看更多>