?

?

你在演講中曾提及AWS CloudWatch會有5分鐘的時延。

Kevin: 誠然，AWS為監控提供了很多基礎技術。CloudWatch十分出眾，它提供了一些基本的警告和通知，并幫你監測一些基礎屬性，像CPU和網絡流入/流出。CPU是我很關注的一點。

CloudWatch的問題在于, 借助Amazon提供的基礎監控技術，你無從獲取應用相關的更深入細節。它只能讓你查看諸如服務器狀態、網絡流入/流出等基礎屬性。

這是一個好的開端，但實用價值不大。試問，CPU0%代表什么？一切運轉正常，還是應用服務器崩潰？可能為較好情況，也可能是最壞結果，而你，對實際情形一無所知。

CloudWatch本身存在不足。試著對其中的部分加以完善，你確實很想監測特定服務及其運轉性能，對么？Yammer Metrics是我力薦的一種工具。它可以為你提供定時器，表和直方圖，更重要的是，它能讓你注釋代碼，讓你監測任何API的運轉性能及調用頻率（每分或 每秒的調用次數），這些信息唾手可得。

這在一定程度上邁出了提供服務相關信息的第一步。但問題在于，你真正想了解的是運行趨勢。知道服務運行了400毫秒意義并不大。昨天是僅僅用了20毫秒，還是800毫秒？是服務已步入困境，還是性能有了飛躍？誠然，你無從知曉。

因此，我在just.me借助Graphite獲得所有執行信息相關的圖表，并與昨天、上月的情況進行比對，進而分析其運行趨勢。這樣，在軟件版本 大更新時，我就能從商業運作和系統運維兩個維度出發，分析更新是否會影響性能和訪問人數。Graphite帶有一項十分便捷的設置服務，用于幫你迅速上手 并熟悉Graphite。我們對這項服務非常滿意。

其后的挑戰在于監測各服務性能，并在故障發生時推送電子郵件或SMS以示提醒、通知。我用一款名為Nagios的工具，它非常出眾，你可以通過對配置文件的簡單修改來定義什么情況下你愿意得到“嘿，問題將至”的警告，什么情況下真正遇到了問題。

挑戰的關鍵在于，你想在問題發生前未卜先知。先知往往會讓分析變得簡單。但毫無疑問，對顧客而言，故障永不發生更值得期待。

關于just.me的預測分析和全面監測，我所做的最后一件事是，Graphite向你提供了每次監測一項服務的一系列工具。也許你能一次觀測五個服務，或是一次觀測所有服務，但我更希望看到行為和趨勢展望。

Square團隊開發了開源軟件Cubism。它能在屏幕上實時顯示大量數據并推斷出運行性能。它最吸引我的地方在于，很多情況下單個服務帶來的問 題會蔓延至整個應用?？赡苣銜仁盏侥稠椃粘掷m10分鐘低效運轉的警告，再一段時間后，整個系統非正常運轉。警告能幫你剝離出問題根源，關注最初發現問 題的服務并在某種程度上引導你更快地接近問題根源。而盡快找到根源才能盡快恢復運轉。

?

在那么多的監測量度中，你如何選定適合你的量度？

Kevin: 的確有很多重要量度值得關注。你想監測CPU，若要同時關注成千上萬事件，可以考慮創建儀表盤，有了它，各類狀態一目了然。有CPU運轉狀態，也有實例運行情況。

監控中最難實現卻又必須完成的功能是主動請求。獲取哪些API發起主動請求和請求的確切數目的相關信息是最具挑戰性也最具價值的事之一。若是訪問量 很大，當某項服務開始出現問題時，完成相關任務會更耗時，從而帶來主動請求數量的上升?？傮w看，這非常非常有趣，特別是使用Java時，線程池大小固定且 每項服務獨占線程，一次API調用掛起就能引起整個服務崩潰。避免單個線程帶來的服務崩潰十分重要。

很多服務并不關注性能。其中，主要區別在于信息取送時機。當你向服務器傳送信息時，幾乎可以肯定，后臺進程是異步的。如果用戶對究竟發生了什么一無所知，那么勢必無從得知服務時耗。獲取信息或是下載時，用戶等待幾乎是必然。下行量度中，用戶性能體驗更重要。

上傳，發布信息，就商業角度而言更重要。我們監測各類社交行為，他們何時發布信息，發布多少信息，贊、評論和其他行為，關注人群。我們對這些事件的數目感興趣，而商家并不關心用戶刷過多少次屏。這就像一種博弈。你要了解獲取時性能，而商家更關注提交。

Cubism很有用。決定哪些量度應一目了然時，它會是一個好的選擇。通過展示頂部緊緊相靠的三色標注，Cubism在最小空間內讓一切一目了然。我能以此在屏幕上監測盡可能多的量度并使之在更遠處可見。

這更多是從操控角度而非商業角度。從商業的角度講，你只需緊盯著你想要達成的核心目標就好。

我的儀表盤比起登錄時約有30%的變動。我們將那些以往認為會發生問題但實際并未發生的量度移除。而另一些預料之外的量度被排放在辦公儀表盤顯眼的位置。

?

儀表盤保留了哪些量度?

Kevin: 我會關注CPU。CPU信息與監控密切相關，我把所有MySQL CPU，EC2 服務器CPU，Lucene CPU以及Neo4j CPU放在一起。它們都顯示一個0到100間的數值，超過75%到80%時，會發生災難。當我一眼看去，發現沒有超過50%的，就會很放心。我并不關心每 個CPU的具體數值，這種壓縮可以使屏幕容納更多信息。

我關注負載均衡器，確定順利運轉的實例數量不為0。我也關注主動請求并確定沒有出現API峰值。

我關注DynamoDB，對于它，我想談兩點，我并不喜歡為DynamoDB讀單元設定的收費方式。在我看，這種方式是非云的。它不會自動調整?；?本上，你說，“我愿為100讀單元支付”。一旦這100讀單元用掉了，系統就開始拒絕返回結果，拋出異常。即便只需要10個，你也要為100單元支付。若 是有一個白天活躍但夜晚清靜的網站，你會面對不間斷的重新配置。我常會惴惴不安于是否有任何一個服務達到了讀單元的閾值，屆時它將停止顯示數據，而你將陷 入大麻煩。這真的非常糟糕。

他們為Dynamo配置了CloudWatch，但使用不便。在just.me我們有很多很多量度，要立即打開瀏覽器監測CloudWatch的所 有數據幾乎不現實。這也是為什么我要在Graphite的基礎上構建自己的工具來集成信息——那些需要上百瀏覽器方能顯示的信息，我像對待CPU一樣把他 們整合在一張表中。監測讀寫單元時，我會劃定一條基線作為閾值，超出閾值的就是有問題的。

儀表盤中還有什么？我曾排放過很多安全層相關的東西。每次請求都需要通過JAAS安全機制并確認是否授權，而早期的授權機制有過一些問題，那些曾被 排放在儀表盤的頂部、前部還有中心，若通過安全驗證耗費了10s，那其余部分的網站性能將不再重要，你必須先修正這一部分，不過現在這些都已解決。那些量 度已經過時，并從儀表盤中銷聲匿跡。

我還把公開的工單數目加入報告中，如果被公開的工單數目很大，也許意味著你在這方面的監控是有漏洞的，所以我在儀表盤中安排了監測公開的工單數目的地方。

為了激發職員的士氣，我也放入了一些市場量度。我能監測到系統新注冊了多少設備以及這些設備發送了多少消息又收到了多少回復。這些信息主要是出于激 勵團隊的目的。我希望儀表盤能吸引他們的目光，讓他們對此好奇進而注意到更多其他方面。我們將儀表盤安置在辦公室，放在一塊很大的屏幕上，所有開發者都能 看到。休息時，人們站在監視器下方，好奇而興奮地談論這些信息。

?

就iOS和Android應用的性能而言，你會重點監測哪些量度？

Kevin: 當開發者同時開發維護Android, iOS或是移動HTML5三個版本時。作為一款響應式應用，移動HTML5常常是我們的選擇，HTML版在最初向用戶介紹應用時可以避免安裝。也許有人會 和他們分享信息，而他們會得到一種很棒的本地化體驗，并宣布“哇，我想安裝完全版并繼續使用”。

得到高度關注的三種客戶端后，你會希望找出其間的差別，從商業維度觀測其運行，并確定哪一版本帶來更多的流量。較大的挑戰之一是找到安裝來源。那些 來到應用商店并開始安裝的用戶，是從哪來？又如何得知？也許我們做過大范圍的廣告推動，為廣告投入了很多資金，但這真的有效？投資回報又如何？或許是我們 博客上的文章帶來了很多訪問量，又或許我們應該更貼近那些潛在商機者，以期達成目標。

在just.me，我們并不直接將引導用戶去應用商店，我們會向用戶展示HTML5繪制的網頁，即just.me/gettheapp。讓他們去 gettheapp，那兒Google Analytics會告訴我們用戶如何得知該產品。我們常在尾部添加查詢字 段，just.me/gettheapp?src=TechCrunchArticle或是just.me /gettheapp?src=emailcampaign。從而根據量度確定最成功的推廣途徑。HTTP頭部中的URL引用也非常管用。我們試圖盡量平 衡應用商店和gettheapp間的訪問。毫無疑問這很有效。

至于其他移動監控的用具，最初我們選了Flurry。這種工具天生適合移動領域。我們把它用于iPhone和Android。它能告訴我們人們的手 持設備型號。如果馬上關注Android版just.me，你會發現，我們支持1500多種設備。我不可能命令QA，“去測試1500種設備”或是“隨機 挑選一種進行測試”。我們希望發現并購置用戶真正用到的那種設備。

我們支持1500種設備，但公司里只有10到15種獨立設備。我確實對開發者施加過不少壓力來讓他們購置和市場使用者接軌的個人手機。是否流行對我們而言很重要，因為，只有這樣QA才能側重關注人們真正在用的設備。

幾周前索尼設備上出過問題，應用上架后我們發現索尼用戶無法發布信息。之前我們從未購置過索尼設備。我們曾在百余人中做過beta測試，有意思的 是，他們中沒有人用索尼。反正就是沒有人報告問題。不過，產品發布的第一天，我撥通了索尼熱線，讓他們盡快送來一臺Xperia。我們拿到了機器，并在 20分鐘內做出了修正，然后上架應用商店。

Android的碎片化問題著實煩心，但能在一個小時內修正并上架，這很神奇。蘋果應用商店上架前經常需要近五天來審核新版本。

Android帶來的另一好處是風險轉移。Google Play在今年的I/O大會上宣稱有alpha和beta版本面市。在just.me應用發布經歷三階段：alpha，beta和成品。Alpha版本面 向那些我很熟悉的人，比如我的酒友們，他們也能在手機上調試應用。如果我想上市新產品，并覺得存在風險，我會在alpha階段停留幾日。讓熟悉的人試用， 看看運行狀況。這樣，即便發生了可怕的錯誤，也沒什么可擔心的。

接下來是beta。這一版本面向那些登錄過網址，并稱“嘿，我對你的產品很有興趣，我很期待上市的那天”的參與者，也許會有幾百人，我們通過 Google+小組進行管理。我把應用分發給他們，這一階段發生錯誤也許不太好，但并非災難。由于產品尚處于beta階段，應用商店中無法評分。你肯定不 想因為發布過早而獲得1星評論。這一階段Android已經做出很多真正值得開發者關注的工作。

就前面提到的索尼案例而言，我們采取的措施是馬上登錄應用商店使其不支持所有索尼設備。若是有手持索尼設備的人進入商店，它會被告之“你的設備還未 被支持。稍后再來”。我們將索尼設備下線了四天來等官方承諾的送貨日期。然后，我們完成修復，并將索尼設備重設為支持態。應用商店當真帶給你很多便利。

在Apple平臺上進行發布時很有意思的一件事在于如何進入編輯推薦區。Apple希望推薦時能看到你為產品引入很多特色。他們并不提倡每星期提交代碼。不被推薦的較好方法是每周都向顧客推出新功能。而理想情況是一年發布三到四次。

當你完成一項特性的開發，你會很想立刻將其發布出去，認為這會挽救你的公司，帶來商機，閉合下行困境而使相關指數上揚。但我們需要忍，因為要多攢點新特性一起發布才能上編輯推薦區。這很痛苦，卻無疑是移動領域成功的關鍵。

回到Flurry的使用。最近Google Analytics發布了新更新Universal Access。Universal Access回歸到Android和iPhone的本質, 讓你能做移動分析。此前，他們為JavaScript提供API。

我們用Google Analytics替代Flurry來獲取量度, 但獲取數據前你必須真正理解Google Analytics。一般職員并不會去獲取Google Analytics的各類數據。市場上只有真正想找到數據的人才能得到這些，而普通開發者并不會閑逛并宣布“噢，我洞察到了”。這不會發生，沒有人會愿意 讓他們耗費那么久，因為標簽，動作或是值集的獲取并不容易，甚至看上去設計得非常不人性化。

我們開始使用另一樣工具Mixpanel。這是一家初創企業發布的付費工具，我在JavaOne講演中并未提到。它相當友好。API有點像 Flurry，但更擅長同期群分析和路徑分析。你能觀察到是誰做了這些，是否還有其他人在做，你能找到那些使用產品一周以上的長期用戶?；旧希P注 長期的客戶分層而非單純統計值。

舉一個簡單的例子：如果有人以每周一次，每天五次的頻度注冊并登錄應用，你能得到一個多少人仍在使用的大概估計。第一課，可能高達100%或 90%，第二課，也許80%，下周70%，你希望在50%或其他目標上保持穩定。若半數的人還在，你想知道最終是否會下降到0。是否有忠實用戶。一般而 言，新人進入時，只關注統計器會讓你很難分辨這是新人還是老用戶；Mixpanel在這方面做得很好，它允許你關注關聯事件，如消息回復或類似事件。

?

好的，最后一個問題，在面臨很多工具（自己動手、參與開源項目、采用可信的第三方服務，如graphite, nagios, jmeter, yammer metrics, New Relic等等）可選時，你會如何抉擇？最主要的影響因素是什么？

Kevin: 我常關注是否已有現成的解決方案。我會先從開源工具中選取。開源工具的一大好處在于，若是存在痛點，將會是很多人共同的痛點，他們會嘗試修復，若尚未修 復，我會親手完成。曾發生過很多次我或同事修復痛點的情況，我們編碼回饋發起者。真的很像一塊踏腳石，你打下樁，其他人幫你完善。

Picasso是源于Square的一款我非常喜歡的程序庫。在just.me我用Picasso來載入圖像。我已經向Square提交了一些功能 請求。我還擁有為功能或其他東西投票的權利。對just.me而言，這很實用。我真的不愿意為緩存和圖像載入編寫所有需要的代碼。

我常常關注開源，但開源并非次次有效。有時會沒有足夠的人對這一問題感興趣。有時會需要你啟動自己的開源項目。以我在E*TRADE工作時為例，我 想測試應用如何在所有瀏覽器中運行，我想用Jenkins做持續集成。沒有人那樣做。我發起并為Jenkins完成了具備相關功能的插件。很多人開始貢獻 補丁、修正和各種很棒的功能需求。

很多次，開源方案并不完全適合你的需求。就像我對Graphite所做的，我需要一個儀表盤，他們的儀表盤做得很用心，但很難做出契合需求的修改。 我并不認為在他們的儀表盤上再進行改進來契合需求可行，所以我在他們所提供原始圖表基礎上創建了自己的儀表盤。Graphite圖表的自由度令我嘆為觀 止，但我發現儀表盤有不足。所以我用自己的工具開發出一個更靈活的儀表盤。

我也會關注一些商用軟件。商用產品在滿足需求又不需過多個性化定制的情形下能幫你節約時間和支出。涉及業務核心時從零開始構建的確是正確的選擇。你 想和其他產品有足夠的區分度，你想完完全全控制。具備資本時，你可以力挺開源項目。然而，當那些東西作為你的業務核心時，你不該總從開源入手。

如果你需要比較高級的功能，比如JVM調優，這時候你會發現在整個開源界里找不到能夠同時做分析和調優的項目。人們并沒有足夠的時間和精力將之投放到開源世界。我認為New Relic已經做得很好，所以我們選擇了跟New Relic合作。

?

Kevin Nilson 是一位Java Champion，曾三次獲得JavaOne Rock Star稱號。Kevin在JavaOne, Devoxx, JAX, O"Reilly Fluent, Silicon Valley Code Camp, JAX, HTML5DevConf, On Android, NFJS SpringOne and AjaxWorld等會議上做過講演。Kevin是Web 2.0 Fundamentals的作者之一。 他曾在San Mateo大學當助教。 Kevin擁有Southern Illinois大學的計算機碩士和學士學位。Kevin是Silicon Valley Java User Group, Silicon Valley Google Developer Group和Silicon Valley JavaScript Meetup的領跑者。

• 上一篇：國內公有云服務商業務現狀
• 下一篇：云計算和大數據：成功組合指南