elasticsearch APM功能全解 一

elastic stack在6.3版本開始推出了APM功能，但當時只支援nodejs，python和ruby，尚不支援java和go，而公司裡面大部分系統還是java，因此只是關注，還沒有去解讀。但在6.4.0版本，終於推出了java和go的beta版本，而在6.5.0版本，終於變為GA版本。這使得在生產環境上部署APM服務變為可能，下面讓我們一起來看看elastic stack的這個APM服務吧

elastic APM的前世今生

首先，不要以為這個APM功能是一個不務正業、心血來潮的新功能。其實今天elastic的APM來源於之前的opbeat。而Opbeat是由一個丹麥初創團隊於2013年成立的老公司了，專門運維軟體的開發，而其主打產品即是APM運維軟體。
被elastic收購之後，opbeat已經於2018年5月份，正式關閉網站和社群，轉到了elastic APM上：

基本元件

Elastic APM 由四個基本元件構成：

• APM agents
• APM Server
• Elasticsearch
• Kibana APM UI

基本架構如下圖：

APM agent是一系列開源庫，使用與伺服器端相同的語言編寫，目前支援node、python、ruby、js，java和golang。您可以像安裝任何其他庫一樣將它們安裝到伺服器端中。apm agent會檢測程式碼並在執行時收集效能資料和錯誤。此資料可 緩衝一小段時間併傳送到APM伺服器。

APM Server是一個用Go編寫的開源應用程式，通常在專用伺服器上執行。它預設偵聽埠8200，並通過JSON HTTP API從代理接收資料。然後，它根據該資料建立文件並將其儲存在Elasticsearch中。

Elasticsearch是一個高度可擴充套件的開源全文搜尋和分析引擎。它允許你快速，近實時地儲存，搜尋和分析大量資料。Elasticsearch用於儲存APM效能指標並利用其聚合。

Kibana是一個開源分析和視覺化平臺，旨在與Elasticsearch協同工作。你可使用Kibana搜尋，檢視Elasticsearch中儲存的資料並與之進行互動。你還可以使用Kibana中的專用APM UI或可以通過 APM Kibana UI直接載入的預構建的開源Kibana dashboard來視覺化APM資料。（basic license就授權了APM功能）

APM

事件（event）

APM agent從其已監測的應用程式中捕獲不同型別的資訊，稱為事件。事件可以是Errors，Spans或Transactions。然後將這些事件流式傳輸到APM server，由server驗證並處理事件。

• Errors 包含捕獲的錯誤或異常的相關資訊。
• Spans包含已執行的特定程式碼路徑的相關資訊。它們從活動的開始到結束進行測量，並且可以與其他跨度建立父/子關係。
• Transactions是一種特殊的跨度，具有與之關聯的額外後設資料。您可以將Transactions視為您在服務中衡量的最高階別的工作。例如，提供HTTP請求或執行特定的後臺作業。

元件通訊

APM server是一個單獨的元件 - 它有助於保持agent的輕量化，防止某些安全風險，並提高整個elastic stack和APM stack的相容性。

Intake API是的APM agent和APM server進行通訊的內部協議。在APM server驗證並處理來自APM agent的事件（通過Intake API）後，server將資料轉換為Elasticsearch文件並將其儲存在相應的Elasticsearch索引中。只需幾秒鐘，您就可以開始在Kibana中檢視應用程式效能資料。

真實使用者監控（RUM）

Real User Monitoring捕獲使用者與Web瀏覽器等客戶端的互動。javascript agent是Elastic的RUM agent。要使用它，您需要在APM server中啟用RUM支援。

與監視請求和響應的Elastic APM後端agent不同，RUM JavaScript agent監視客戶端應用程式中的真實使用者體驗和互動。RUM JavaScript agent也與框架無關，這意味著它可以與任何前端JavaScript應用程式一起使用。

您將能夠測量諸如time to first byte之類的指標。而domInteractive，domComplete這類指標可以幫助你發現客戶端應用程式中的效能問題以及與伺服器端應用程式通訊延遲的相關問題。

分散式跟蹤（Distributed trace）

我們所有的APM agent都支援開箱即用的分散式跟蹤。通過分散式跟蹤，你可以在一個檢視中分析整個微服務架構的效能。

現代應用程式效能監視的一個關鍵特性是分散式跟蹤。隨著軟體應用程式架構從單一架構轉變為更加分散的，基於服務的架構，能夠跟蹤請求如何流經系統至關重要。

通過分散式跟蹤，request和transactions將連結在一起形成trace，即transactions和spans共同構成了一個Trace。trace不是事件，而是將具有公共根的事件組合在一起。從中，我們可以端到端的檢測request的效能，以及哪些service是該request服務的一部分。

分散式追蹤可以監控整個呼叫鏈，使開發人員和運營人員能夠將各個事務的效能進行上下文分析，從而快速查明最終影響使用者體驗的瓶頸。

需要注意的是，目前Distributed trace還只是一個Beta版本

我們可以從下圖學習分散式跟蹤。
其中，Rack是一個request。因為是一個微服務系統，整個request是由多個service共同完成的。示例中，參與服務的bean由ruby, python, java, node。可見，整個Distributed trace與技術無關，只要由一個公共的根（trace id），則在服務下所有的transactions均可在UI上顯示。