微服務系統監控三要素
現在系統基本都是微服務架構，對于複雜微服務鍊路調用出現問題如何解決？
- 一個請求經過了這些服務後其中出現了一個調用失敗的問題，如何定位問題發生的地方？
- 如何計算每個節點通路流量？
- 流量波動的時候，增加哪些節點叢集服務？
為了解決分布式應用、微服務系統面臨的這些挑戰，APM系統（Application Performance Management，即應用性能管理，簡單來說就是應用監控）為之誕生，核心滿足微服務系統監控的三要素如下：
- Logging ：就是記錄系統行為的離散事件，例如，服務在處理某個請求時列印的錯誤日志，我們可以将這些日志資訊記錄到 ElasticSearch 或是其他存儲中，然後通過 Kibana 或是其他工具來分析這些日志了解服務的行為和狀态。大多數情況下，日志記錄的資料很分散，并且互相獨立，比如錯誤日志、請求處理過程中關鍵步驟的日志等等
- Metrics ：是系統在一段時間内某一方面的某個度量，例如，電商系統在一分鐘内的請求次數。我們常見的監控系統中記錄的資料都屬于這個範疇，例如 Promethus、Open-Falcon 等，這些監控系統最終給運維人員展示的是一張張二維的折線圖。Metrics 是可以聚合的，例如，為電商系統中每個 HTTP 接口添加一個計數器，計算每個接口的 QPS，之後我們就可以通過簡單的加和計算得到系統的總負載情況。
- Tracing ：即我們常說的分布式鍊路追蹤。在微服務架構系統中一個請求會經過很多服務處理，調用鍊路會非常長，要确定中間哪個服務出現異常是非常麻煩的一件事。通過分布式鍊路追蹤，運維人員就可以建構一個請求的視圖，這個視圖上展示了一個請求從進入系統開始到傳回響應的整個流程。這樣，就可以從中了解到所有服務的異常情況、網絡調用，以及系統的性能瓶頸等。
OpenTracing
早在在 2010 年 4 月谷歌發表了一篇論文《Dapper, a Large-Scale Distributed Systems TracingInfrastructure》闡述分布式追蹤的概念，OpenTracing用于分布式跟蹤和上下文傳播的一緻的、表達的、提供了一個标準的與供應商無關的api架構，這意味着如果開發者想要嘗試一種不同的分布式追蹤系統，開發者隻需要簡單地修改Tracer配置即可，而不需要替換整個分布式追蹤系統；OpenTracing API目前也支援衆多語言。了解OpenTracing API可以有利于更好學習本篇的主角SkyWalking。
開源APM系統
目前市面上開源的APM系統主要有CAT、Zipkin、Pinpoint，大都是參考Google的Dapper實作的
- CAT：是由國内美團點評開源的，基于Java語言開發，目前提供Java、C/C++、Node.js、Python、Go等語言的用戶端，監控資料會全量統計，國内很多公司在用，例如美團點評、攜程、拼多多等，CAT跟下邊要介紹的Zipkin都需要在應用程式中埋點，對代碼侵入性強，我們傾向于選擇對代碼無侵入的産品，是以淘汰了CAT.
- Zipkin：由Twitter公司開發并開源，Java語言實作，侵入性相對于CAT要低一點，需要對web.xml之類的配置檔案做修改，但依然對代碼有侵入，也沒有選擇.
- Pinpoint：一個南韓團隊開源的産品，運用了位元組碼增強技術，隻需要在啟動時添加啟動參數即可，對代碼無侵入，目前支援Java和PHP語言，底層采用HBase來存儲資料，探針收集的資料粒度非常細，但性能損耗大，因其出現的時間較長，完成度也很高，應用的公司較多。
SkyWalking架構
SkyWalking基本可以滿足對于分布式系統APM的所有需要的功能，功能非常強大、性能表現優秀、對業務代碼無侵入，增長勢頭強勁，社群活躍，中文文檔齊全，支援多語言探針， SkyWalking 支援Dubbo、gRPC、SOFARPC 等很多架構，包含了雲原生架構下的分布式系統的監控、跟蹤、診斷、日志記錄和告警功能，可以在浏覽器上觀察分布式系統應用程式發生的一切。使用skywalk，使用者可以了解服務和端點之間的拓撲關系，檢視每個服務/服務執行個體/端點的名額，設定告警規則。
SkyWalking邏輯上分為四個部分:探針agent、平台後端OAP、存儲和UI。
- Agent（探針）：探針收集資料并根據SkyWalking的要求對資料進行重新格式化(不同的探測器支援不同的來源)；Agent 運作在各個服務執行個體中，負責采集服務執行個體的 Trace 、Metrics 等資料，然後通過 gRPC 方式上報給 SkyWalking 後端。
- OAP：SkyWalking 的後端服務，支援資料聚合、分析和流處理，包括跟蹤、名額和日志。接收 Agent 上報上來的 Trace、Metrics 等資料，交給 Analysis Core （涉及SkyWalking OAP 中的多個子產品）進行流式分析，最終将分析得到的結果寫入持久化存儲中。響應 SkyWalking UI 界面發送來的查詢請求，将前面持久化的資料查詢出來，組成正确的響應結果傳回給 UI 界面進行展示。
- 存儲：SkyWalking資料可以選擇存儲在已實作的ElasticSearch, H2, MySQL, TiDB, InfluxDB的持久化系統，一般線上使用ElasticSearch 叢集作為其後端存儲。
- UI:可視化和管理SkyWalking 資料，前後端分離，該 UI 界面負責将使用者的查詢操作封裝為 GraphQL 請求送出給 OAP 後端觸發後續的查詢操作，待拿到查詢結果之後會在前端負責展示。
使用
Apache SkyWalking的UI界面主要分為以下幾個區域： 功能選擇區：這裡列出了主要的UI功能，包括儀表盤、拓撲圖、追蹤、性能刨析、告警等功能重新加載區：控制重新加載機制，包括定期重新加載或手動重新加載。時間選擇器：控制時區和時間範圍。這裡有一個中文/英文切換按鈕，預設，UI使用浏覽器語言設定。下面逐一介紹功能選擇區的各個功能。
Apache SkyWalking的UI界面主要分為以下幾個區域：
- 功能選擇區：這裡列出了主要的UI功能，包括儀表盤、拓撲圖、追蹤、性能刨析、告警等功能
- 重新加載區：控制重新加載機制，包括定期重新加載或手動重新加載。
- 時間選擇器：控制時區和時間範圍。這裡有一個中文/英文切換按鈕，預設，UI使用浏覽器語言設定。
- 下面逐一介紹功能選擇區的各個功能。
儀表盤
儀表盤又分為以下幾個功能：
- APM：以全局（Global）、服務（Service）、服務執行個體（Instance）、端點（Endpoint）的次元展示各項名額。
- Database：展示資料庫的各項名額。
- SelfObservability：展示OAP服務端的各項名額。
- Web Browser：以服務和頁面的次元展示Web浏覽器端的各項名額。
相關概念解釋：
- 服務（Service）：表示對請求提供相同行為的一組工作負載，比如：一個的 Web API系統。
- 服務執行個體（Instance）：上述的一組工作負載中的每一個工作負載稱為一個執行個體，比如：一個的 Web API 系統叢集中的一個執行個體。
- 端點（Endpoint）：對于特定服務所接收的請求路徑，如 HTTP 的 URI 路徑和 gRPC 服務的類名 + 方法簽名。
APM - 全局（Global）
全局（Global）展示的是所有服務的各項名額，包括：
- 吞吐量排名，機關為CPM（calls per minute，每分鐘的調用次數）。
- 服務響應時間排名，機關為毫秒。
- 不健康服務排名，機關為Apdex（Application Performance Index，應用性能指數）。
- 端點響應時間排名，機關為毫秒。
- 響應時間百分位，包括 p99, p95, p90, p75, p50，機關為毫秒。
- 響應時間熱力圖，機關為毫秒。
相關概念解釋：
Apdex：Application Performance Index，應用性能指數， Apdex = (滿意樣本數 + 可容忍樣本數 * 0.5) / 樣本總數，滿意樣本為響應時間小等于Apdex門檻值，可容忍樣本為響應時間大于Apdex門檻值并小等于4倍的Apdex門檻值。目前Apdex門檻值為0.5秒。
APM - 服務（Service）
服務（Service）是以服務的次元展示各項名額，包括：
- 服務Apdex（Application Performance Index，應用性能指數）。
- 服務平均響應時間，機關為毫秒。
- 服務成功率。
- 服務吞吐量，機關為CPM（calls per minute，每分鐘的調用次數）。
- 服務Apdex曲線圖。
- 服務百分位，包括 p99, p95, p90, p75, p50，機關為毫秒。
- 服務成功率曲線圖。
- 服務吞吐量曲線圖，機關為CPM（calls per minute，每分鐘的調用次數）。
- 端點吞吐量排名，機關為CPM（calls per minute，每分鐘的調用次數）。
- 端點響應時間排名，機關為毫秒。
- 端點成功率排名。
APM - 服務執行個體（Instance）
服務執行個體（Instance）是以執行個體的次元展示各項名額，包括：
- 執行個體吞吐量，機關為CPM（calls per minute，每分鐘的調用次數）。
- 執行個體成功率。
- 執行個體平均響應時間，機關為毫秒。
- JVM的CPU使用百分比。
- JVM的記憶體使用情況。
- JVM的GC時間。
- JVM的GC次數。
APM - 端點（Endpoint）
端點（Endpoint）是以端點的次元展示各項名額，包括：
- 端點吞吐量排名，機關為CPM（calls per minute，每分鐘的調用次數）。
- 端點平均響應時間排名，機關為毫秒。
- 端點成功率排名。
- 端點吞吐量曲線圖，機關為CPM（calls per minute，每分鐘的調用次數）。
- 端點平均響應時間曲線圖，機關為毫秒。
- 端點百分位，包括 p99, p95, p90, p75, p50，機關為毫秒。
- 端點成功率曲線圖。
Database
展示資料庫（Database）相關的各項名額，包括：
- 資料庫平均響應時間，機關為毫秒。
- 資料庫通路成功率。
- 資料庫吞吐量，機關為CPM（calls per minute，每分鐘的調用次數）。
- 資料庫通路百分位，包括 p99, p95, p90, p75, p50，機關為毫秒。
- 慢查詢清單，機關為毫秒。
- 所有資料庫吞吐量排名，機關為CPM（calls per minute，每分鐘的調用次數）。
- 所有資料庫成功率排名。
拓撲圖
拓撲圖可以顯示服務之間的拓撲關系，如下圖：
- 服務選擇器，可以選擇某個服務，顯示其直接關系，包括上遊和下遊。
- 自定義組，可以建立自定義的任意一組服務，用于顯示其一組服務的拓撲圖。
點選某些服務的圖示，可檢視該服務的類型、Apdex、成功率、響應時間、吞吐量、百分位等資訊，如下圖：
點選服務之間的連線，可檢視兩個服務之間的響應時間、吞吐量、成功率、百分位等資訊，如下圖：
點選上圖中的展示執行個體依賴按鈕，可檢視各個執行個體之間的響應時間、吞吐量、成功率、百分位等資訊，如下圖：
追蹤
追蹤頁面可以查詢到某個分布式鍊路的整體情況，如下圖：
- 搜尋條件設定，支援按服務、執行個體、端點名稱、追蹤ID、時間範圍等條件進行查詢。
- 片段（Segment）清單，點選某個片段（Segment），在右側展示與片段（Segment）相關的整個追蹤（Trace）。
- 服務清單，是這個追蹤（Trace）涉及的所有服務，每個服務用不同的顔色展示。
- 跨度（Span）清單，是這個追蹤（Trace）涉及的所有跨度（Span），還可以看到每個跨度（Span）耗時和層級關系。點選某個跨度（Span），可以看到它的等服務名稱、端點名稱資訊。
- 追蹤（Trace）視圖設定，提供3種視圖展示追蹤（Trace）：清單、樹結構、表格。
- 相關概念解釋：
- 追蹤（Trace）：一個追蹤（Trace）表示一個事務或者流程在分布式系統中的執行過程，是一條完整的分布式調用鍊。
- 跨度（Span）：一個跨度（Span）表示系統中具有開始時間和執行時長的邏輯運作單元。跨度（Span）之間通過嵌套或者順序排列建立邏輯因果關系，最終形成一個追蹤（Trace）。
- 片段（Segment）：一個片段（Segment）表示同一端點内的一組跨度（Span）的集合。
常見的錯誤可能是由代碼異常或網絡故障引起的，通過追蹤（Trace）視圖提供的跨度（Span）細節，可以快速找到錯誤發生在哪個環節。
性能刨析
性能剖析是利用方法棧快照，并對方法執行情況進行分析和彙總，對代碼執行速度進行估算。
性能剖析激活時，會對指定線程周期性的進行線程棧快照，并将所有的快照進行彙總分析，如果兩個連續的快照含有同樣的方法棧，則說明此棧中的方法大機率在這個時間間隔内都處于執行狀态。進而，通過這種連續快照的時間間隔累加成為估算的方法執行時間。
建立任務
想要進行性能刨析，我們必須建立一個任務，如下圖：
- 選擇指定的服務。
- 輸入端點名稱，這裡的端點名稱通常是第一個片段（Segment）的操作名，在追蹤頁面的追蹤（Trace）視圖裡可以找到。
- 選擇監控時間，可以從現在開始，也可以從未來的任何時間開始。
- 選擇監視持續時間，可以設定監視的時間視窗，以查找到合适的請求進行性能刨析。
- 監控間隔，提供了一個過濾器機制，如果給定端點響應的請求很快，它就不會性能刨析，可以確定性能刨析的資料是預期的資料。
- 最大采樣數，表示探針收集的最大資料集，它有助于減少記憶體和網絡負載。
- 即使性能刨析對目标系統的性能影響非常有限，但它仍然是一個額外的負載，以上設定可以使性能影響可控。另外，在任何時刻，每個服務隻能執行一個性能刨析任務。
分析結果
等待性能刨析的任務完成後，對應的片段（Segment）就會在右側展示出來。點選某個片段（Segment），可以更詳細地看到各個片段（Segment）的耗時，如下圖：
從上圖可以看到最慢的片段（Segment）。點選分析按鈕，可以看到基于方法棧的分析結果，包括對應的類名、方法名、代碼行數、耗時等資訊，最慢的方法棧被高亮顯示，如下圖：
性能剖析的優勢
- 精确的問題定位，直接找到代碼方法和代碼行；
- 無需反複的增删埋點，大大減少了人力開發成本；
- 不用承擔過多埋點對目标系統和監控系統的壓力和性能風險；
- 按需使用，平時對系統無消耗，使用時的消耗穩定可控。
告警
在告警頁面可以檢視所有觸發的告警，如下圖：
過濾範圍的設定包括：服務、服務執行個體、端點、服務關系、服務執行個體關系、端點關系等。