作者 ｜ 劉浩楊
來源｜爾達 erda 公衆号
apm 的全稱是 application performance management（應用性能管理），早在 90 年代中期就有廠商提出性能管理的概念，到現在 apm 領域已經發展了近 25 年。
通常而言，apm 的技術已經發展了 3 個階段，在這裡我們可以通過前藍海訊通（oneapm）創始人何曉陽在 2014 年分享的《apm 應用性能管理的過去二十年》來回顧一下 apm 的發展曆史。
1995 年到 2000 年，正是第一代網際網路浪潮興起的年代。當時，雅虎作為網際網路公司的代表，引領一代潮流，美國人忙着鋪光纖架網線，一個一個的站點被建立了起來。如果說網站的響應速度決定了使用者體驗的話，那麼當時的網速就決定了網站的響應速度，是以，apm 1.0 時代的軟體功能就是這麼簡單：管理網絡系統的性能。
時間發展到 2000 年，看過《浪潮之巅》這本書的讀者應該會對那個時代有一些印象，當時的 sun 正處于巅峰時期，市值接近 2000 億美元，這些公司當時正在瘋狂的建設資料中心，購買各種各樣的硬體和軟體。在這裡，我們用一個專業名詞來稱呼他們，叫做基礎元件（infrastructure）。那麼，當時的 apm 系統已經到了第二代，作用是監控和管理各種基礎元件的性能。
2005 年以後，随着 facebook，twitter 這些應用提供商的興起，越來越多的 app 被用來服務全球客戶；對于使用者來說，他們通路的應用服務可能分布式 的部署在全球的多個資料中心上，尤其是 2010 年以後，新的移動通路方式的興起，讓每一個人的生活方式更加緊密的依賴于各種 application。在這個時候，應用本身的性能越來越成為制約使用者體驗提升的瓶頸。這就是第三代 apm 軟體的用武之地：第一是管理真實使用者的體驗，第二是進行端到端的業務交易性能分析。
可以看到，在過去很長一段時間，apm 的重心一直在關注使用者體驗性能和應用程式性能，随着近年來雲計算的興起，和雲原生所倡導的新範式，給傳統的研發和運維模式帶來了新的挑戰：微服務、devops 等理念讓研發變得更高效，但帶來的卻是海量微服務的問題排查、故障定位的難度變得更大；容器化、kubernetes 等容器編排技術的逐漸成熟讓規模化軟體傳遞變得容易，但帶來的挑戰是如何更精準地評估容量、排程資源，確定成本與穩定性的最好平衡。
apple 的工程師 cindy sridharan 的博文“監控與觀察”（monitoring and oberservability）首次将 oberservability 一詞帶入開發者的視野。然而，在谷歌，其著名的 sre 體系在此之前就已經奠定了可觀察性的理論基礎，也就是說在微服務、可觀測性等概念或者出現以前，前輩們将這套理論稱為監控，其中 google sre 特别強調白盒監控的重要性，而将當時技術圈常用的黑盒監控放在了相對次要的位置。而白盒監控正是應和了可觀察性中“主動”的概念。
這裡引用一下 baron schschwarz 大咖的一個定義：“監控告訴我們系統的哪些部分是不工作的。可觀察性告訴我們那裡為什麼不工作了。”
由此可見，可觀察性是雲原生系統中提供穩定性和性能監控、診斷分析的一套理念。和監控相比，可觀察性從單一的度量擴充為 metrics、tracing、logging 三大支柱：
logging，展現的是應用運作而産生的事件或者程式在執行的過程中間産生的一些日志，可以詳細解釋系統的運作狀态，但是存儲和查詢需要消耗大量的資源。是以往往使用過濾器減少資料量。
metrics，是一種聚合數值，存儲空間很小，可以觀察系統的狀态和趨勢，但對于問題定位缺乏細節展示。這個時候使用等高線名額等多元資料結構來增強對于細節的表現力。例如統計一個服務的 tbs 的正确率、成功率、流量等，這是常見的針對單個名額或者某一個資料庫的。
tracing，面向的是請求，可以輕松分析出請求中異常點，但與 logging 有相同的問題就是資源消耗較大。通常也需要通過采樣的方式減少資料量。比如一次請求的範圍，也就是從浏覽器或者手機端發起的任何一次調用，一個流程化的東西，我們需要軌迹去追蹤。
在上文中我們提到，可觀察性提供了一套理念來監控、診斷雲原生應用系統。是以，cncf 發起了 opentelemetry 項目，希望借此統一可觀察性三種資料的标準規範和統一的采集實作。但在現實世界中，我們更關心的是采集的資料如何被存儲和使用。由此，erda msp（microservice platform）中的應用監控子系統也在逐漸演進為以“可觀察性分析診斷_”_為核心的微服務觀測平台。
觀測：觀察服務自身的運作狀态和監控名額。
分析：對觀察資料進行關聯、統計、加工等。
診斷：基于觀察資料的分析結果，描述出系統異常的直接原因。
erda msp 目前覆寫從基礎設施、業務系統、到端應用的數百種名額和狀态采集：
我們也根據監控運維常見的場景和名額，在 erda 中提供了預設的觀測視圖：
多雲叢集狀态和資源使用率觀測
叢集節點名額觀測
服務請求和延遲觀測
針對于業務系統的慢請求和錯誤請求，我們內建了 log、trace 和 metric 的關聯，讓使用者可以在很容易的定位到請求的異常上下文資訊：
錯誤請求檢索
錯誤請求和慢請求 top
慢請求和錯誤請求下鑽分析
exception 分析
exception 下鑽關聯到 trace 和 log
erda msp 支援使用自定義 dashboard 定制使用者自己的分析場景，dashboard 詳細使用參考：《上手後才知道，這套儀表盤系統用起來是真的爽！》。
對日志資料的處理，erda 支援全文檢索和結構化标簽檢索兩種方式，并且實作一鍵關聯日志和調用鍊路的分析能力。
日志關聯鍊路追蹤分析
erda 作為開源的一站式雲原生 paas 平台，具備 devops、微服務觀測治理、多雲管理以及快資料治理等平台級能力。點選下方連結即可參與開源，和衆多開發者一起探讨、交流，共建開源社群。歡迎大家關注、貢獻代碼和 star！
erda github 位址：https://github.com/erda-project/erda
erda cloud 官網：https://www.erda.cloud/
《觀察之道：帶你走進可觀察性》
《萬字破解雲原生可觀測性》