PaaS技術(shù)的廣泛應用需要新的監控技術(shù)。這是因為有效的監控對于促進(jìn)資源自動(dòng)伸縮、維持高可用性、管理多租戶(hù)（多種應用共享資源），以及識別應用和PaaS系統中的性能缺陷是至關(guān)重要的。
為了從PaaS操作環(huán)境中提取充足的信息，必須具備完整和全面的性能數據，并且進(jìn)行有效率的數據收集——而且收集操作對系統性能不能有太多的影響。因此，應用性能監控（Application Performance Monitoring，APM）系統成功的關(guān)鍵之處就在于要能夠有效解決這些問(wèn)題并且進(jìn)行相關(guān)的權衡取舍。
本文提出了一個(gè)新的PaaS APM設計，該云APM系統不是通常人們最為熟悉的外部系統，而是一個(gè)與PaaS云平臺緊密集成的系統，我們充分利用并增加了現有的組件以提供全面和全棧式的監控、分析和可視化管理。
該設計充分利用了目前PaaS平臺所具有的資源彈性伸縮、容錯性、安全性和控制特性，同時(shí)為云應用提供了低開(kāi)銷(xiāo)和端到端的監控和分析方法。
云APM設計與PaaS集成
與大多數的系統監控解決方案一樣，新的云APM具有數據采集、存儲、處理（包括數據分析）和可視化等特點(diǎn)。
傳感器和代理提供PaaS云平臺的應用程序和核心組件，可以收集數據。傳感器對于一個(gè)特定組件而言是靜態(tài)的，而軟件代理則更為復雜，可以智能地適應不斷變化的情況，包括對信息采集進(jìn)行動(dòng)態(tài)決策——采集什么信息？以及什么時(shí)候、如何采集信息？鑒于傳感器和代理能夠影響行為和性能，它們必須重量小，并且支持非侵入式部署。為達到這些標準，確保準確性，我們將定期的、非窮盡抽樣與整個(gè)軟件堆棧的傳感器和代理的智能配置加以結合。
在性能數據的存儲和處理方面，我們充分利用PaaS自身提供的可擴展、長(cháng)期、高度可用的分布式服務(wù)。具體而言，我們的系統使用可擴展的鍵值存儲、緩存系統、關(guān)系數據庫系統、高性能搜索系統，以及批量和串流分析框架，來(lái)構建PaaS業(yè)務(wù)生態(tài)系統。對于PaaS系統間的可移植性，各功能定義一個(gè)應用軟件編程接口（Application Programming Interface，API）。通過(guò)這些接口，各功能可以與PaaS組件和業(yè)務(wù)進(jìn)行互動(dòng)。為了能夠與新的PaaS交互，API操作被重寫(xiě)并與該PaaS的操作相關(guān)聯(lián)。
圖1展示了APM與一個(gè)典型PaaS堆棧的集成。左側深藍色的區域表示PaaS的架構。箭頭指示則針對響應應用請求的數據和命令的方向。PaaS云平臺的最底層，即基礎設施層由必要的計算、存儲和網(wǎng)絡(luò )資源組成。PaaS可以動(dòng)態(tài)獲取并且釋放這些資源。
PaaS內核就是一組可管理、可擴展的業(yè)務(wù)。這些業(yè)務(wù)執行大多數云應用程序所需的通用功能。應用開(kāi)發(fā)人員將這些業(yè)務(wù)組合起來(lái)進(jìn)行創(chuàng )新。這些業(yè)務(wù)通常包括數據存儲和緩沖、隊列服務(wù)、認證、用戶(hù)管理，以及眾多的其它業(yè)務(wù)。
APM架構
PaaS云平臺提供一個(gè)API（云軟件開(kāi)發(fā)工具包）管理集。開(kāi)發(fā)人員利用這些API將PaaS功能連接到應用程序上。云軟件開(kāi)發(fā)工具包——類(lèi)似PaaS代理機制——簡(jiǎn)化、控制以及負載均衡針對應用程序和系統間PaaS業(yè)務(wù)的訪(fǎng)問(wèn)。
應用服務(wù)器執行應用程序的副本并且連接應用代碼和下層的PaaS內核。同時(shí)，這些服務(wù)器還將應用代碼隔離起來(lái)以確保安全的多用戶(hù)操作，并提供業(yè)務(wù)控制和計費服務(wù)。負載均衡器（或者前端）作為應用程序的入口點(diǎn)，可以攔截應用請求，過(guò)濾并發(fā)送給適當的服務(wù)器實(shí)例。
回到圖1中，與PaaS組件相連的灰色小方框代表用于監控這個(gè)云平臺組件的傳感器和代理。它們可以收集事件和性能數據。APM收集來(lái)自PaaS堆棧（全棧式監控）各層的數據。測量速率是可配置的，并且在許多情況下具有自適應性。傳感器和代理程序利用批量操作和異步通信來(lái)減少性能故障和費用開(kāi)銷(xiāo)。
APM收集來(lái)自前端和負載均衡層的信息，這些信息與后續的應用請求相關(guān)。監控代理分析HTTP服務(wù)器日志以提取時(shí)間戳、源/目標地址、響應時(shí)間和其它參數。通常這些信息隨時(shí)通過(guò)目前使用的大部分前端技術(shù)，例如Apache HTTPD和Nginx來(lái)進(jìn)行采集。另外，代理還收集活動(dòng)連接、無(wú)效訪(fǎng)問(wèn)嘗試和HTTP錯誤信息。
在應用服務(wù)器層內部，傳感器收集應用和運行時(shí)間/容器日志數據。這些數據一般包括表明單個(gè)應用實(shí)例的資源使用情況的流程級指標。針對日志文件進(jìn)行分析可以避免因為構建應用程序和應用服務(wù)器而產(chǎn)生的高開(kāi)銷(xiāo)。當然，如果收益能夠沖抵開(kāi)銷(xiāo)的話(huà)，還是可以增加額外的應用程序和應用服務(wù)器的。
在PaaS內核中，我們在所有PaaS業(yè)務(wù)的入口點(diǎn)都做了如下部署：
- 收集主叫人和被叫人信息；
- 時(shí)間戳；
- 各操作調用的執行時(shí)間；
- 請求細節，包括參數長(cháng)度和哈希。
這有助于區別PaaS的不同執行階段，匯總和描述操作調用實(shí)例。同時(shí)也可以實(shí)現低開(kāi)銷(xiāo)和準確的全棧式監控。
可以通過(guò)云基礎設施收集來(lái)自虛擬機、操作系統容器，以及各物理主機與進(jìn)程和資源使用相關(guān)的信息。這一層的大多數傳感器可以分析日志、查詢(xún)Linux proc文件系統、收集網(wǎng)絡(luò )/CPU/內存/資源配置的相關(guān)指標，以及管理和編排框架做出的回收決定。
收集到的信息支持集群活動(dòng)和全系統事件。由于PaaS系統通常承載Web應用和服務(wù)，因而我們的APM設計將Web請求看作事件。每個(gè)HTTP請求頭都附有一個(gè)請求識別碼，對所有組件均可見(jiàn)。然后適當的APM代理經(jīng)過(guò)配置來(lái)記錄這些識別碼。數據處理層隨后利用請求識別碼進(jìn)行集群測量，用于單個(gè)Web請求的端到端系統分析。
數據處理層存儲并提供可擴展的性能數據訪(fǎng)問(wèn)。該數據處理層還支持例行的插件分析，可以用來(lái)描述隨時(shí)間變化的應用與系統行為、檢測行為和性能的異常與工作量變化，并且識別出能夠實(shí)現更有效的資源利用，以及資源、業(yè)務(wù)和應用實(shí)例的自動(dòng)縮放的機遇。
這些分析程序可以進(jìn)行推理和預測，并且利用統計分析庫批量處理業(yè)務(wù)和搜索查詢(xún)系統。
APM的基礎：彈性棧
經(jīng)過(guò)全方位評估，我們選擇Elastic Stack作為APM的基礎。Elastic Stack是一種開(kāi)源分布式系統，建立在Linux KVM（Kernel-based Virtual Machine）基礎之上，用于數據存儲和處理。
Elastic Stack包括3大組成部分，即ElasticSearch、Logstash和Kibana。
- ElasticSearch：支持通過(guò)自動(dòng)分庫和復制實(shí)現結構化和半結構化數據的可擴展、高可用性管理；同時(shí)，其還提供全面的數據索引、過(guò)濾、匯總和查詢(xún)支持，可以簡(jiǎn)化上層數據處理算法的實(shí)施過(guò)程。ElasticSearch在諸如Spark和MapReduce等大數據工作流中易于整合，實(shí)現高級分析。
- Logstash：有利于將數據從廣泛的標準日志格式中提取出來(lái)。通過(guò)簡(jiǎn)單配置可以支持自定義日志格式。
- Kibana：提供強大的基于Web的儀表盤(pán)，支持大量的圖表、表格和時(shí)間序列。另外，自定義數據處理與分析組件及其擴展可以根據對度量系統的研究實(shí)現對可視化數據的優(yōu)化，從而更加便于提取有價(jià)值的信息。
APM應用案例
以下的應用案例利用APM收集的PaaS性能數據來(lái)提供新的PaaS特性。其中有兩個(gè)特別令人感興趣的問(wèn)題：第一，APM系統如何幫助預測部署在PaaS云平臺端的Web應用的基于性能的服務(wù)等級目標（Service Level Objective，SLO）？第二，性能異常是如何在PaaS堆棧中被偵測出來(lái)的？
應用響應時(shí)間預測
該AMP應用案例提供可擴展和精確的響應時(shí)間預測，能夠在云供應商和PaaS用戶(hù)間充當各應用程序SLO的角色。為實(shí)現這一目標，我們將托管Web應用的靜態(tài)程序分析和PaaS云平臺的APM監控結合起來(lái)。因為我們希望在PaaS用戶(hù)安裝這些應用的時(shí)候為其提供預測，所以在PaaS云平臺上安裝或運行一個(gè)應用之前會(huì )進(jìn)行這一靜態(tài)分析。
對于每個(gè)功能路徑，我們的靜態(tài)分析通過(guò)傳統技術(shù)提取PaaS內核呼叫清單以進(jìn)行基于抽象解釋的循環(huán)邊界分析、分支預測和最壞情況下的執行時(shí)間分析。為節省開(kāi)銷(xiāo)，我們禁止應用程序收集運行時(shí)的性能指標。相反地，這些清單被記錄在A(yíng)PM系統中，業(yè)務(wù)也在該系統中獨立于應用程序的執行之外受到監控。
該系統利用APM收集的PaaS內核業(yè)務(wù)性能數據，隨后分析程序提取清單中每個(gè)業(yè)務(wù)操作執行時(shí)間的時(shí)間序列，預測方法計算應用響應時(shí)間的統計邊界，然后云供應商再把這些值作為性能SLO的基礎。
為了預測SLO，我們采用基于時(shí)間序列的隊列邊界估算法（Queue Bounds Estimation from Time Series，QBETS），這是我們設計用來(lái)預測在高性能計算環(huán)境中批量隊列系統的調度延遲的一種非參數的時(shí)間序列分析方法。我們對這一方法進(jìn)行優(yōu)化，使其可以在PaaS APM系統中用來(lái)支持“X即服務(wù)”以便估算安裝應用所需的響應時(shí)間。
由于PaaS業(yè)務(wù)和平臺行為負載隨時(shí)間而變化，預測出的SLO可能隨時(shí)間的推移而失效。我們的系統可以檢測SLO違規，因此云供應商可以進(jìn)行重新協(xié)商。當此類(lèi)失效情況出現時(shí)，PaaS會(huì )觸發(fā)APM的SLO分析程序以建立新的SLO。
目前，我們的云APM已整合在谷歌應用程序引擎內，以及開(kāi)源PaaS AppScale的完整的堆棧中，以使用這些平臺對運行在其上的開(kāi)源Java Web應用進(jìn)行廣泛的測試和實(shí)證評估。我們發(fā)現我們的系統在任何情況下都可以生成準確的SLO。
性能異常檢測
人們開(kāi)發(fā)了無(wú)數的統計模型用于動(dòng)態(tài)檢測性能異常，然而之前的大部分工作只關(guān)注簡(jiǎn)單、獨立的應用程序。我們的目標是為基于PaaS（分布式）的Web應用提供異常檢測。為此，我們部署了大量名為異常檢測器的APM分析插件，這些設備可以定期分析PaaS中安裝的每個(gè)應用的性能數據。
每個(gè)檢測器使用不同的檢測統計方法。應用級的檢測器支持不同的應用使用一個(gè)或多個(gè)不同的異常檢測器。每個(gè)檢測器配有執行時(shí)間表和單個(gè)已處理數據的滑動(dòng)窗口，例如，從10分鐘前直到現在。
除此之外，路徑異常檢測器利用PaaS內核呼叫清單檢測每個(gè)應用請求處理路徑。在這種情況下，來(lái)自PaaS內核（PaaS內核調用數據）的數據用于推測單個(gè)應用的執行路徑。檢測器計算不同路徑的頻率分布，檢測該分布隨時(shí)間的變化情況，識別新路徑、最頻繁的執行路徑以及路徑頻率分布中的重要變化。
一旦檢測到異常情況，檢測器會(huì )發(fā)送事件給一組異常處理器。該事件包括與異常情況對應的唯一的異常識別碼、時(shí)間戳、應用識別碼和源檢測器的滑動(dòng)窗口。異常處理器支持全局配置，也可以設置為忽略特定的事件類(lèi)別。與檢測器一樣，APM支持大量的異常處理器，用于處理日志異常、發(fā)送告警郵件，以及更新儀表盤(pán)等等。
此外，我們還提供兩種特殊的異常處理器：一種是工作量變化分析器，另外一種是根因分析器。
工作量變化分析器利用一套變化點(diǎn)檢測算法分析歷史工作量趨勢。
根因分析器評估PaaS內核呼叫歷史趨勢，試圖決定最有可能導致異常云（在PaaS內核中）的組件。
異常檢測器和異常處理器與固定大小的滑動(dòng)窗口協(xié)同工作，在滑動(dòng)窗口隨時(shí)間線(xiàn)移動(dòng)的同時(shí)丟棄舊數據。由于這些實(shí)體必須儲存的狀態(tài)信息的數量有嚴格的上限，因而程序都是輕量級的。如有必要，歷史數據能夠被保存在A(yíng)PM中進(jìn)行線(xiàn)下批量處理。
指導新的PaaS業(yè)務(wù)
由于PaaS的應用日益受到歡迎，利用技術(shù)進(jìn)行監控、分析已安裝應用的性能和行為變得十分重要。然而，大多數PaaS云平臺無(wú)法為輕量級、全棧式的性能、數據收集和分析提供足夠的支持。
人們已經(jīng)設計了許多監控框架來(lái)支持收集和分析性能數據以獲取系統行為、性能、可用性和故障信息。不幸的是，雖然許多框架都不同程度地支持數據搜集、存儲、分析和可視化，但沒(méi)有一個(gè)能夠作為云平臺的一部分而運行。數據存儲機制、API和配置模型作為獨立實(shí)體，旨在監控服務(wù)器或應用程序，無(wú)法在更大的系統中支持端到端的請求流跟蹤。并且，它們不易擴展，僅支持基本的度量計算，不支持相關(guān)性或根因分析。
我們提出了新的易于整合的APM系統作為一個(gè)解決方案，該系統可以利用PaaS云平臺的特點(diǎn)進(jìn)行全面、全棧式監控和分析。通過(guò)定義一套API呼叫，該APM可以整合到PaaS系統中，促進(jìn)推理和預測。這一功能可以用來(lái)指導新的PaaS業(yè)務(wù)，包括應用安裝時(shí)的響應時(shí)間SLO、全系統的性能異常和工作量變化點(diǎn)檢測，以及應用性能異常的根因分析。
Chandra Krintz和Rich Wolski/文
加利福尼亞大學(xué)圣芭芭拉分校計算機科學(xué)系適應性計算環(huán)境研究實(shí)驗室主任
