為PaaS雲平臺提供整合的全棧式監控

作為一項日益受到歡迎的技術，平臺即服務（Platform-as-a-Service，PaaS）可以在雲端部署能夠通過Web訪問的應用。藉助PaaS，使用者不必關注詳細的執行資訊，例如作業系統、資源分配、網路配置以及業務生態系統管理。同時，PaaS可以實現負載均衡、資源伸縮和容錯功能的自動化。應用開發人員從而得以專注於程式設計和創新，無需考慮部署和系統問題。

PaaS技術的廣泛應用需要新的監控技術。這是因為有效的監控對於促進資源自動伸縮、維持高可用性、管理多租戶（多種應用共享資源），以及識別應用和PaaS系統中的效能缺陷是至關重要的。

為了從PaaS操作環境中提取充足的資訊，必須具備完整和全面的效能資料，並且進行有效率的資料收集——而且收集操作對系統效能不能有太多的影響。因此，應用效能監控（Application PerformanceMonitoring，APM）系統成功的關鍵之處就在於要能夠有效解決這些問題並且進行相關的權衡取捨。

本文提出了一個新的PaaS APM設計，該雲APM系統不是通常人們最為熟悉的外部系統，而是一個與PaaS雲平臺緊密整合的系統，我們充分利用並增加了現有的元件以提供全面和全棧式的監控、分析和視覺化管理。

該設計充分利用了目前PaaS平臺所具有的資源彈性伸縮、容錯性、安全性和控制特性，同時為雲應用提供了低開銷和端到端的監控和分析方法。

雲APM設計與PaaS整合

與大多數的系統監控解決方案一樣，新的雲APM具有資料採集、儲存、處理（包括資料分析）和視覺化等特點。

感測器和代理提供PaaS雲平臺的應用程式和核心元件，可以收集資料。感測器對於一個特定元件而言是靜態的，而軟體代理則更為複雜，可以智慧地適應不斷變化的情況，包括對資訊採集進行動態決策——採集什麼資訊？以及什麼時候、如何採集資訊？鑑於感測器和代理能夠影響行為和效能，它們必須重量小，並且支援非侵入式部署。為達到這些標準，確保準確性，我們將定期的、非窮盡抽樣與整個軟體堆疊的感測器和代理的智慧配置加以結合。

在效能資料的儲存和處理方面，我們充分利用PaaS自身提供的可擴充套件、長期、高度可用的分散式服務。具體而言，我們的系統使用可擴充套件的鍵值儲存、快取系統、關聯式資料庫系統、高效能搜尋系統，以及批量和串流分析框架，來構建PaaS業務生態系統。對於PaaS系統間的可移植性，各功能定義一個應用軟體程式設計介面（Application ProgrammingInterface，API）。通過這些介面，各功能可以與PaaS元件和業務進行互動。為了能夠與新的PaaS互動，API操作被重寫並與該PaaS的操作相關聯。

圖1展示了APM與一個典型PaaS堆疊的整合。左側深藍色的區域表示PaaS的架構。箭頭指示則針對響應應用請求的資料和命令的方向。PaaS雲平臺的最底層，即基礎設施層由必要的計算、儲存和網路資源組成。PaaS可以動態獲取並且釋放這些資源。

PaaS核心就是一組可管理、可擴充套件的業務。這些業務執行大多數雲應用程式所需的通用功能。應用開發人員將這些業務組合起來進行創新。這些業務通常包括資料儲存和緩衝、佇列服務、認證、使用者管理，以及眾多的其它業務。

PaaS雲平臺提供一個API（雲軟體開發工具包）管理集。開發人員利用這些API將PaaS功能連線到應用程式上。雲軟體開發工具包——類似PaaS代理機制——簡化、控制以及負載均衡針對應用程式和系統間PaaS業務的訪問。

應用伺服器執行應用程式的副本並且連線應用程式碼和下層的PaaS核心。同時，這些伺服器還將應用程式碼隔離起來以確保安全的多使用者操作，並提供業務控制和計費服務。負載均衡器（或者前端）作為應用程式的入口點，可以攔截應用請求，過濾併傳送給適當的伺服器例項。

回到圖1中，與PaaS元件相連的灰色小方框代表用於監控這個雲平臺元件的感測器和代理。它們可以收集事件和效能資料。APM收集來自PaaS堆疊（全棧式監控）各層的資料。測量速率是可配置的，並且在許多情況下具有自適應性。感測器和代理程式利用批量操作和非同步通訊來減少效能故障和費用開銷。

APM收集來自前端和負載均衡層的資訊，這些資訊與後續的應用請求相關。監控代理分析HTTP伺服器日誌以提取時間戳、源/目標地址、響應時間和其它引數。通常這些資訊隨時通過目前使用的大部分前端技術，例如Apache HTTPD和Nginx來進行採集。另外，代理還收集活動連線、無效訪問嘗試和HTTP錯誤資訊。

在應用伺服器層內部，感測器收集應用和執行時間/容器日誌資料。這些資料一般包括表明單個應用例項的資源使用情況的流程級指標。針對日誌檔案進行分析可以避免因為構建應用程式和應用伺服器而產生的高開銷。當然，如果收益能夠衝抵開銷的話，還是可以增加額外的應用程式和應用伺服器的。

在PaaS核心中，我們在所有PaaS業務的入口點都做了如下部署：

·        收集主叫人和被叫人資訊；

·        時間戳；

·        各操作呼叫的執行時間；

·        請求細節，包括引數長度和雜湊。

這有助於區別PaaS的不同執行階段，彙總和描述操作呼叫例項。同時也可以實現低開銷和準確的全棧式監控。

可以通過雲基礎設施收集來自虛擬機器、作業系統容器，以及各物理主機與程式和資源使用相關的資訊。這一層的大多數感測器可以分析日誌、查詢Linux proc檔案系統、收集網路/CPU/記憶體/資源配置的相關指標，以及管理和編排框架做出的回收決定。

收集到的資訊支援叢集活動和全系統事件。由於PaaS系統通常承載Web應用和服務，因而我們的APM設計將Web請求看作事件。每個HTTP請求頭都附有一個請求識別碼，對所有元件均可見。然後適當的APM代理經過配置來記錄這些識別碼。資料處理層隨後利用請求識別碼進行叢集測量，用於單個Web請求的端到端系統分析。

資料處理層儲存並提供可擴充套件的效能資料訪問。該資料處理層還支援例行的外掛分析，可以用來描述隨時間變化的應用與系統行為、檢測行為和效能的異常與工作量變化，並且識別出能夠實現更有效的資源利用，以及資源、業務和應用例項的自動縮放的機遇。

這些分析程式可以進行推理和預測，並且利用統計分析庫批量處理業務和搜尋查詢系統。

APM的基礎：彈性棧

經過全方位評估，我們選擇Elastic Stack作為APM的基礎。Elastic Stack是一種開源分散式系統，建立在Linux KVM（Kernel-based Virtual Machine）基礎之上，用於資料儲存和處理。

ElasticStack包括3大組成部分，即ElasticSearch、Logstash和Kibana。

·        ElasticSearch：支援通過自動分庫和複製實現結構化和半結構化資料的可擴充套件、高可用性管理；同時，其還提供全面的資料索引、過濾、彙總和查詢支援，可以簡化上層資料處理演算法的實施過程。ElasticSearch在諸如Spark和MapReduce等大資料工作流中易於整合，實現高階分析。

·        Logstash：有利於將資料從廣泛的標準日誌格式中提取出來。通過簡單配置可以支援自定義日誌格式。

·        Kibana：提供強大的基於Web的儀表盤，支援大量的圖表、表格和時間序列。另外，自定義資料處理與分析元件及其擴充套件可以根據對度量系統的研究實現對視覺化資料的優化，從而更加便於提取有價值的資訊。

APM應用案例

以下的應用案例利用APM收集的PaaS效能資料來提供新的PaaS特性。其中有兩個特別令人感興趣的問題：第一，APM系統如何幫助預測部署在PaaS雲平臺端的Web應用的基於效能的服務等級目標（Service Level Objective，SLO）？第二，效能異常是如何在PaaS堆疊中被偵測出來的？

應用響應時間預測

該AMP應用案例提供可擴充套件和精確的響應時間預測，能夠在雲供應商和PaaS使用者間充當各應用程式SLO的角色。為實現這一目標，我們將託管Web應用的靜態程式分析和PaaS雲平臺的APM監控結合起來。因為我們希望在PaaS使用者安裝這些應用的時候為其提供預測，所以在PaaS雲平臺上安裝或執行一個應用之前會進行這一靜態分析。

對於每個功能路徑，我們的靜態分析通過傳統技術提取PaaS核心呼叫清單以進行基於抽象解釋的迴圈邊界分析、分支預測和最壞情況下的執行時間分析。為節省開銷，我們禁止應用程式收集執行時的效能指標。相反地，這些清單被記錄在APM系統中，業務也在該系統中獨立於應用程式的執行之外受到監控。

該系統利用APM收集的PaaS核心業務效能資料，隨後分析程式提取清單中每個業務操作執行時間的時間序列，預測方法計算應用響應時間的統計邊界，然後雲供應商再把這些值作為效能SLO的基礎。

為了預測SLO，我們採用基於時間序列的佇列邊界估演算法（Queue Bounds Estimation fromTime Series，QBETS），這是我們設計用來預測在高效能運算環境中批量佇列系統的排程延遲的一種非引數的時間序列分析方法。我們對這一方法進行優化，使其可以在PaaS APM系統中用來支援“X即服務”以便估算安裝應用所需的響應時間。

由於PaaS業務和平臺行為負載隨時間而變化，預測出的SLO可能隨時間的推移而失效。我們的系統可以檢測SLO違規，因此雲供應商可以進行重新協商。當此類失效情況出現時，PaaS會觸發APM的SLO分析程式以建立新的SLO。

目前，我們的雲APM已整合在谷歌應用程式引擎內，以及開源PaaS AppScale的完整的堆疊中，以使用這些平臺對執行在其上的開源Java Web應用進行廣泛的測試和實證評估。我們發現我們的系統在任何情況下都可以生成準確的SLO。

效能異常檢測

人們開發了無數的統計模型用於動態檢測效能異常，然而之前的大部分工作只關注簡單、獨立的應用程式。我們的目標是為基於PaaS（分散式）的Web應用提供異常檢測。為此，我們部署了大量名為異常檢測器的APM分析外掛，這些裝置可以定期分析PaaS中安裝的每個應用的效能資料。

每個檢測器使用不同的檢測統計方法。應用級的檢測器支援不同的應用使用一個或多個不同的異常檢測器。每個檢測器配有執行時間表和單個已處理資料的滑動視窗，例如，從10分鐘前直到現在。

除此之外，路徑異常檢測器利用PaaS核心呼叫清單檢測每個應用請求處理路徑。在這種情況下，來自PaaS核心（PaaS核心呼叫資料）的資料用於推測單個應用的執行路徑。檢測器計算不同路徑的頻率分佈，檢測該分佈隨時間的變化情況，識別新路徑、最頻繁的執行路徑以及路徑頻率分佈中的重要變化。

一旦檢測到異常情況，檢測器會傳送事件給一組異常處理器。該事件包括與異常情況對應的唯一的異常識別碼、時間戳、應用識別碼和源檢測器的滑動視窗。異常處理器支援全域性配置，也可以設定為忽略特定的事件類別。與檢測器一樣，APM支援大量的異常處理器，用於處理日誌異常、傳送告警郵件，以及更新儀表盤等等。

此外，我們還提供兩種特殊的異常處理器：一種是工作量變化分析器，另外一種是根因分析器。

·        工作量變化分析器利用一套變化點檢測演算法分析歷史工作量趨勢。

·        根因分析器評估PaaS核心呼叫歷史趨勢，試圖決定最有可能導致異常雲（在PaaS核心中）的元件。

異常檢測器和異常處理器與固定大小的滑動視窗協同工作，在滑動視窗隨時間線移動的同時丟棄舊資料。由於這些實體必須儲存的狀態資訊的數量有嚴格的上限，因而程式都是輕量級的。如有必要，歷史資料能夠被儲存在APM中進行線下批量處理。

指導新的PaaS業務

由於PaaS的應用日益受到歡迎，利用技術進行監控、分析已安裝應用的效能和行為變得十分重要。然而，大多數PaaS雲平臺無法為輕量級、全棧式的效能、資料收集和分析提供足夠的支援。

人們已經設計了許多監控框架來支援收集和分析效能資料以獲取系統行為、效能、可用性和故障資訊。不幸的是，雖然許多框架都不同程度地支援資料蒐集、儲存、分析和視覺化，但沒有一個能夠作為雲平臺的一部分而執行。資料儲存機制、API和配置模型作為獨立實體，旨在監控伺服器或應用程式，無法在更大的系統中支援端到端的請求流跟蹤。並且，它們不易擴充套件，僅支援基本的度量計算，不支援相關性或根因分析。

我們提出了新的易於整合的APM系統作為一個解決方案，該系統可以利用PaaS雲平臺的特點進行全面、全棧式監控和分析。通過定義一套API呼叫，該APM可以整合到PaaS系統中，促進推理和預測。這一功能可以用來指導新的PaaS業務，包括應用安裝時的響應時間SLO、全系統的效能異常和工作量變化點檢測，以及應用效能異常的根因分析。

Chandra Krintz和Rich Wolski/文

加利福尼亞大學聖芭芭拉分校電腦科學系適應性計算環境研究實驗室主任