Java開發者在某個重大發布后需要使用的15個工具

新發布的根本生存裝備

不像玩僵尸毀滅的場景，也不像辯論大刀對抗獵槍，在Java的生產環境中問題是真實存在的，特別是在一個新的發布之后（有備無患嘛）。更進一步說，比起當時 將編碼周期縮短至幾周或是幾天，甚至一天縮短多次，反而現在更容易陷入麻煩。為了避免這些麻煩，你需要完全理解新的代碼會對你的系統產生什么影響。是否會 對原有的系統產生破壞？是否會讓系統運行遲緩？怎么去解決這些可能出現的問題呢？下面介紹一些工具和架構來徹底破解這些問題。

現在開發生命周期非但不會縮短，每天不斷膨脹的日志數據 甚至可以達到GB級別的量級。讓我們說說在新發布之后的問題：如果你想及時響應，在沒有合適的工具的情況下，想要處理多數據源多服務器的GB量級的數據， 幾乎是不可能的。在這樣的情況下，除開重型企業內部的工具Splunk和他的SaaS中的競爭對手，如Sumo Logic， Loggly等等。我們依然有提供類似功能的其他選擇，因此我們對日志的管理做了一個深入的分析，你可以參照這里。

#1 建立一個可靠的日志管理策略，能幫助你看到的不止是單獨的日志文件，能讓你在新發布之后快速做出相應。

我們最后發現，在新發布之后的一個有用的日志框架就是開源的ELK stack。因為它是開源免費的，所以被特別提到。

ELK stack包括 ElasticSearch,，Logstash 和Kibana

那么我們所說的 ELK到底是什么呢？它是一個混合體，包括用作搜索和性能分析的elasticsearch，用于日志收集的Logstash和用作前端展現的 Kibana。我們已經用過有一段時間了，依靠它和Redis分析我們的Java日志，它也有被用在開發和BI之中。現在，elasticsearch已經內置于Logstash，Kibana也是一個elasticsearch的產品，這樣能讓集成和安裝更容易。

每當一個新的發布之后，前端會展現出我們對這個應用健康所關心的自定義指標。這些指標會實時更新，并且允許剛交付的代碼上傳到生產環境后馬上就得到監測。

#2 搜索，可視化以及對多數據源日志的聚合，是決定你日志管理工具選擇的第一要素。

#3 從一個開發者的角度，評估新的發布的影響也包括BI等方面。

可供選擇的工具：

1. 內置工具: Splunk
2. SaaS：Sumo Logic
   3. SaaS：Loggly
   4. 開源：Graylog2
   5. 開源：Fluentd
   6. The ELK stack (開源)： Elasticsearch + Logstash + Kibana

性能監控：

發 布周期被縮短，日志文件越來越大，但這并不是全部。隨著用戶請求的數量急劇增長，他們都希望達到性能的峰值。如果你不努力優化，簡單的日志記錄讓你只能看 到這么多。這樣說來，專用應用程序性能管理工具(APM)已不再被認為是奢侈品,它已經迅速成為一種標準。從本質上說，APM意味著時間需要多長時間來執 行不同的地區代碼并完成匯報——要達到這個，可以通過代碼檢測，日志監控或是包括網絡/硬件指標。考慮到后臺以及用戶設備，首先進入我腦中的兩個APM工 具分別是New Relic(最近剛IPO)以及AppDynamics。

左邊為AppDynamics，右邊為New Relic的主面板

不 管是初創還是成熟的公司，這兩個都能滿足不同類型的開發者。但是兩個都在走IPO,在經歷巨大的增長后，產品線越來越模糊。這個選擇不是很清晰，但是你不 能陷入誤區，即On premise = AppDynamics。相反，這是一個獨立的需求，它依賴于誰更適合你的站點（即它們提供的所有特性就是你實際上想要使用的）。看看我們最近發布的關于二者的分析報告，點擊這里。

我 們最近發布的另外兩個工具是Ruxit（由Compuware開發）和DripStat（Chronon Systems開發），它們每一個都來自由New Relic開創的嘗試自己解決SaaS監控市場的大公司。為了深入JVM硬核內部，jClarity和Plumbr也絕對值得一試。

#4：新的發布有可能影響你應用的性能使之運行變慢。APM工具可以提供你應用健康的總體情況。

可供選擇的工具：

1. AppDynamics
2. New Relic

新的成員：

1. jClarity
2. Plumbr
3. Ruxit
4. Dripstat

產品調試

發 布周期短了，日志文件變大了，用戶請求增多……允許犯錯誤的余地幾乎不存在了。但當錯誤真的到來時，你需要能夠馬上解決掉。大規模的生產環境，每天可以從 成百上千個不同的代碼處產生無數的錯誤。雖然有些錯誤時不重要的，但有些可能對你的應用產生致命的影響，并影響你所接觸不到的終端用戶。另外，為了鑒別和解決這些錯誤，你必須依賴于你的日志或是日志管理工具去查看錯誤的發生，更不用說如何修復它。

有了Takipi，你能夠知道最有可能出問題且需要優化的地方，并且能得到怎么取解決每個問題的可行的信息。

為了關注新發布后的危機，Takipi解決了三個主要問題：

1.了解哪些錯誤最有可能影響你——在生產中發現100%的代碼錯誤，包括JVM異常和記錄的錯誤。使用智能過濾以減少噪音使之專注于最重要的錯誤。超過90%的Takipi用戶報告說，在他們使用的第一天，至少在生產中找到了一個嚴重的bug。

2、在調試上花更少的時間和精力——Takipi再現了每個錯誤并顯示出代碼和導致它產生的變量，甚至可以跨服務器。這消除了手動復制錯誤的必要，節省了工程時間,顯著降低時間。

3. 沒有風險的發布——當新的版本中有錯誤，或是已經解決的錯誤又重現時，Takipi都會提醒你。

#5：運用Takipi你能很快地解決任何問題，以至于不讓你在新的發布之后一無所知。

可選擇的工具：

1. Takipi

從這篇文章之后，Takipi的使用時間擴展到了兩個月

100%發現生產中的錯誤

發現每個錯誤后面的參數

使大規模調試變得容易

報警和追蹤

發 布周期，日志文件，用戶請求，零錯誤……你怎么才能全部跟進呢？你可能認為這一類和其他的重疊了，可能你是對的，但是當所有的這些工具都有他們自己的流水 線時，你可能會意識到自己哪里錯了——這將變得很混亂。特別是在各種意想不到的事情都可能發生的新發布后（也就是整個災難降臨）。

滿足這個的事件管理工具之一的就是PagerDuty：它能從監控工具收集報警，創建時間表來協調你的團隊，或是通過文本、郵件、短信或是推送通知，把每個報警發給特定的人。

#6：考慮使用一個事件管理系統來處理信息過載。

在這里我們真正喜歡使用的專業工具是Pingdom（也是和Pagerduty的結合）。它所做的很簡單而且有用：即對你的站點的響應時間做24*7小時的追蹤和告警。它能回答一個看起來微不足道，實則至關重要的問題：從世界各地檢測來看，當前的站點可用嗎？

系統如上圖

另一個角度來解決信息過載的方法，是通過對日志分析來進行錯誤的跟蹤:管理異常和日志錯誤的智能展現。從多個服務器聚合數據到一個地方，即使你的日志事件或是其他插件來自你的代碼。為了更深入地錯誤追蹤，點擊這篇文章可以得到更多的信息。

#7 代碼層的錯誤來源各種各樣，在選用追蹤工具時，應該給予特別的對待（在我們關注他們的時候就修復一些bug，哈哈）

可供選擇的工具:

1. PagerDuty
2. Pingdom

總結

我們親身經歷，現代軟件開發如何影響發布生命周期，放大如何評估新的快速部署的影響——在你部署之前，你應該完全了解最后更新的影響。從長遠來看,任何工具都應該擁有這五個特點:

1. 縮短發布周期
2. 增加日志文件
3. 增大用戶請求
4. 減小錯誤
5. 信息的過載

最重要地是，思考一下現在你是怎么解決這些的，哪一個花了你更多的時間。很可能就有一個工具適合解決這個問題。

原文鏈接： takipi 翻譯： ImportNew.com - 張 健
譯文鏈接： http://www.importnew.com/14616.html