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

作者 Sai Yang ，譯者 劉君

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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í)可以避免安裝。也許有人會和他們分享信息，而他們會得到一種很棒的本地化體驗(yàn)，并宣布“哇，我想安裝完全版并繼續(xù)使用”。

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

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

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

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

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

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

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

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

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

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

當(dāng)你完成一項(xiàng)特性的開發(fā)，你會很想立刻將其發(fā)布出去，認(rèn)為這會挽救你的公司，帶來商機(jī)，閉合下行困境而使相關(guān)指數(shù)上揚(yáng)。但我們需要忍，因?yàn)橐鄶€點(diǎn)新特性一起發(fā)布才能上編輯推薦區(qū)。這很痛苦，卻無疑是移動(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來獲取量度，但獲取數(shù)據(jù)前你必須真正理解Google Analytics。一般職員并不會去獲取Google Analytics的各類數(shù)據(jù)。市場上只有真正想找到數(shù)據(jù)的人才能得到這些，而普通開發(fā)者并不會閑逛并宣布“噢，我洞察到了”。這不會發(fā)生，沒有人會愿意讓他們耗費(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，但更擅長同期群分析和路徑分析。你能觀察到是誰做了這些，是否還有其他人在做，你能找到那些使用產(chǎn)品一周以上的長期用戶?；旧?，它更關(guān)注長期的客戶分層而非單純統(tǒng)計(jì)值。

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

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

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

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

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

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

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

如果你需要比較高級的功能，比如JVM調(diào)優(yōu)，這時(shí)候你會發(fā)現(xiàn)在整個(gè)開源界里找不到能夠同時(shí)做分析和調(diào)優(yōu)的項(xiàng)目。人們并沒有足夠的時(shí)間和精力將之投放到開源世界。我認(rèn)為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大學(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)測試釋疑——對話Just.me工程副總裁Kevin Nilson