?

?

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

Kevin: 誠然，AWS為監(jiān)控提供了很多基礎(chǔ)技術(shù)。CloudWatch十分出眾，它提供了一些基本的警告和通知，并幫你監(jiān)測一些基礎(chǔ)屬性，像CPU和網(wǎng)絡(luò)流入/流出。CPU是我很關(guān)注的一點。

CloudWatch的問題在于, 借助Amazon提供的基礎(chǔ)監(jiān)控技術(shù)，你無從獲取應(yīng)用相關(guān)的更深入細節(jié)。它只能讓你查看諸如服務(wù)器狀態(tài)、網(wǎng)絡(luò)流入/流出等基礎(chǔ)屬性。

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

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

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

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

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

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

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

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

?

在那么多的監(jiān)測量度中，你如何選定適合你的量度？

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

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

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

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

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

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

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

?

儀表盤保留了哪些量度?

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

我關(guān)注負載均衡器，確定順利運轉(zhuǎn)的實例數(shù)量不為0。我也關(guān)注主動請求并確定沒有出現(xiàn)API峰值。

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

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

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

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

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

?

就iOS和Android應(yīng)用的性能而言，你會重點監(jiān)測哪些量度？

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

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

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

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

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

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

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

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

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

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

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

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

回到Flurry的使用。最近Google Analytics發(fā)布了新更新Universal Access。Universal Access回歸到Android和iPhone的本質(zhì), 讓你能做移動分析。此前，他們?yōu)镴avaScript提供API。

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

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

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

?

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

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

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

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

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

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

如果你需要比較高級的功能，比如JVM調(diào)優(yōu)，這時候你會發(fā)現(xiàn)在整個開源界里找不到能夠同時做分析和調(diào)優(yōu)的項目。人們并沒有足夠的時間和精力將之投放到開源世界。我認為New Relic已經(jīng)做得很好，所以我們選擇了跟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的領(lǐng)跑者。

• 上一篇：國內(nèi)公有云服務(wù)商業(yè)務(wù)現(xiàn)狀
• 下一篇：云計算和大數(shù)據(jù)：成功組合指南