云端監(jiān)控和移動(dòng)測(cè)試釋疑——對(duì)話Just.me工程副總裁Kevin Nilson

作者 Sai Yang ，譯者 劉君

云端監(jiān)控和服務(wù)器管理區(qū)別甚遠(yuǎn)。在2013上海JavaOne大會(huì)上，just.me工程部副總裁Kevin Nilson講述了云端部署的必要措施，其中涵蓋一些AWS平臺(tái)管理操作時(shí)的注意事項(xiàng)。

InfoQ就云端監(jiān)控和服務(wù)器管理的具體差異、差異相關(guān)的應(yīng)對(duì)方案以及app監(jiān)控和移動(dòng)測(cè)試的必備知識(shí)等方面內(nèi)容采訪了Kevin。

InfoQ：Kevin你好，很高興你能來(lái)。你今早就云端監(jiān)控做了講演。那么就你看，從現(xiàn)有服務(wù)器向AWS遷移時(shí)，監(jiān)控方面的最大不同是什么？

Kevin：云端部署會(huì)面臨很多挑戰(zhàn)，其中之一是確知特定時(shí)刻正在運(yùn)行的服務(wù)器數(shù)量。系統(tǒng)規(guī)模會(huì)自適應(yīng)調(diào)整，因而無(wú)從知曉到底有多少服務(wù)器在運(yùn)行，亦無(wú)從知曉這些服務(wù)器的性能如何。這會(huì)是一種挑戰(zhàn)。

另一個(gè)特定的挑戰(zhàn)在于，云服務(wù)建立在商用硬件之上。云中一切共享，但每臺(tái)服務(wù)器并非完全相同。很可能新啟動(dòng)的實(shí)例會(huì)比你先前使用的實(shí)例慢很多。

你要學(xué)會(huì)以不同的監(jiān)控粒度查看API性能，一些情況下視整個(gè)服務(wù)為一體，另一些時(shí)候以服務(wù)器為性能查看的基本單元。有時(shí)，你大致了解API調(diào)用的執(zhí)行流程，卻發(fā)現(xiàn)本次調(diào)用的性能遠(yuǎn)低于預(yù)期。遇到這種情況，你可以試試刪除當(dāng)前實(shí)例并重新申請(qǐng)。畢竟，沒(méi)有人會(huì)愿意為遠(yuǎn)低于應(yīng)得的性能付款，而這種情況雖不常發(fā)生但確實(shí)存在。

許多人——我曾和Pinterest的首席工程師談過(guò)，他們也曾遇到過(guò)同樣的問(wèn)題。我還知道Netflix的那群人在這一研究領(lǐng)域做了不少調(diào)研，而我們會(huì)繼續(xù)保持對(duì)該領(lǐng)域的關(guān)注。

還有一件有意思的事情在于，使用云服務(wù)時(shí)，你常常會(huì)終止實(shí)例，而終止意味著完全終結(jié)。你會(huì)失去一切，包括各種日志以及其他類似物。這是另一種挑戰(zhàn)。

云端部署的其他挑戰(zhàn)源于服務(wù)器管理。在just.me我們使用Graphite，一種類似Ganglia的工具。配置特定數(shù)量的服務(wù)器實(shí)例并不困難，你可以用Graphite對(duì)這些服務(wù)器進(jìn)行監(jiān)控，并以拉模式收集運(yùn)行時(shí)信息。這也是此類工具最常見(jiàn)的用途。不過(guò)，在云端使用拉模式意味著每次新實(shí)例添加都必須重啟Graphite，重新配置并重啟服務(wù)器。這顯然不合適。

或許你可以試著換個(gè)角度。不是讓服務(wù)器監(jiān)管所有運(yùn)行時(shí)實(shí)例，而是打破常規(guī)，讓全部運(yùn)行時(shí)實(shí)例了解到監(jiān)視服務(wù)器的存在。這樣，數(shù)據(jù)會(huì)被運(yùn)行實(shí)例推送給負(fù)責(zé)匯報(bào)的進(jìn)程，而不是匯報(bào)進(jìn)程從服務(wù)器上主動(dòng)獲取。

我認(rèn)為這是云服務(wù)的極大進(jìn)步。行動(dòng)前確定方向并考慮清楚，將很大程度上簡(jiǎn)化我們想做的事。

InfoQ：你在演講中曾提及AWS CloudWatch會(huì)有5分鐘的時(shí)延。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

InfoQ：儀表盤保留了哪些量度?

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

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

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

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

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

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

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

InfoQ：就iOS和Android應(yīng)用的性能而言，你會(huì)重點(diǎn)監(jiān)測(cè)哪些量度？

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

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

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

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

我們支持1500種設(shè)備，但公司里只有10到15種獨(dú)立設(shè)備。我確實(shí)對(duì)開發(fā)者施加過(guò)不少壓力來(lái)讓他們購(gòu)置和市場(chǎng)使用者接軌的個(gè)人手機(jī)。是否流行對(duì)我們而言很重要，因?yàn)椋挥羞@樣QA才能側(cè)重關(guān)注人們真正在用的設(shè)備。

幾周前索尼設(shè)備上出過(guò)問(wèn)題，應(yīng)用上架后我們發(fā)現(xiàn)索尼用戶無(wú)法發(fā)布信息。之前我們從未購(gòu)置過(guò)索尼設(shè)備。我們?cè)诎儆嗳酥凶鲞^(guò)beta測(cè)試，有意思的是，他們中沒(méi)有人用索尼。反正就是沒(méi)有人報(bào)告問(wèn)題。不過(guò)，產(chǎn)品發(fā)布的第一天，我撥通了索尼熱線，讓他們盡快送來(lái)一臺(tái)Xperia。我們拿到了機(jī)器，并在20分鐘內(nèi)做出了修正，然后上架應(yīng)用商店。

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

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

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

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

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

當(dāng)你完成一項(xiàng)特性的開發(fā)，你會(huì)很想立刻將其發(fā)布出去，認(rèn)為這會(huì)挽救你的公司，帶來(lái)商機(jī)，閉合下行困境而使相關(guān)指數(shù)上揚(yáng)。但我們需要忍，因?yàn)橐鄶€點(diǎn)新特性一起發(fā)布才能上編輯推薦區(qū)。這很痛苦，卻無(wú)疑是移動(dòng)領(lǐng)域成功的關(guān)鍵。

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

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

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

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

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

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

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

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

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

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

如果你需要比較高級(jí)的功能，比如JVM調(diào)優(yōu)，這時(shí)候你會(huì)發(fā)現(xiàn)在整個(gè)開源界里找不到能夠同時(shí)做分析和調(diào)優(yōu)的項(xiàng)目。人們并沒(méi)有足夠的時(shí)間和精力將之投放到開源世界。我認(rèn)為New Relic已經(jīng)做得很好，所以我們選擇了跟New Relic合作。

Kevin Nilson是一位Java Champion，曾三次獲得JavaOne Rock Star稱號(hào)。Kevin在JavaOne, Devoxx, JAX, O'Reilly Fluent, Silicon Valley Code Camp, JAX, HTML5DevConf, On Android, NFJS SpringOne and AjaxWorld等會(huì)議上做過(guò)講演。Kevin是Web 2.0 Fundamentals的作者之一。 他曾在San Mateo大學(xué)當(dāng)助教。Kevin擁有Southern Illinois大學(xué)的計(jì)算機(jī)碩士和學(xué)士學(xué)位。Kevin是Silicon Valley Java User Group, Silicon Valley Google Developer Group和Silicon Valley JavaScript Meetup的領(lǐng)跑者。

查看英文原文：Interview with Kevin Nilson on Cloud Monitoring and Mobile Testing

查看原文：云端監(jiān)控和移動(dòng)測(cè)試釋疑——對(duì)話Just.me工程副總裁Kevin Nilson