1. 程式人生 > >在Docker中監控Java應用程式的5個方法

在Docker中監控Java應用程式的5個方法

http://geek.csdn.net/news/detail/218595


譯者注:Docker是一個開源的應用容器引擎,讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中,然後釋出到任何流行的Linux機器上,也可以實現虛擬化。通常情況下,監控的主要目的在於:減少宕機時間、擴充套件和效能管理、資源計劃、識別異常事件和故障排除分析等。本文作者介紹了5種方法幫助你在Docker中監控Java應用程式。

你知道有什麼好的方法可以在Docker容器中監控Java應用程式嗎?

在容器中執行應用程式是一種日益流行的維護大型分散式棧的方法,這種棧基於需求而變化。對於基於容器的架構來說,Java虛擬機器是一種理想的程式語言。由於存在很多活動的部件和組成元素,在容器中監控Java應用程式時,需要提前計劃和選擇正確的工具,從而有效地監控對你有用的地方。

在一個監控堆疊中需要考慮5個部分的因素。首先,我會簡要介紹前面兩個部分,並且指出覆蓋到這兩部分的有用的資源,然後我將著重講解後面三部分。

目錄

  1. 生成有用的日誌
  2. 效能監控
  3. 錯誤追蹤
  4. 容器測量指標

  5. Orchestration

  6. 結語

生成有用的日誌

當然,Java會生成自己的應用程式日誌,但是通常需要額外的工具去增加這些日誌的可讀性和可用性,其中包括公認的、大型的工具,例如

Splunk and the Elastic stack,或小型的(但效能相當)工具,例如Sumo Logic, Graylog, Loggly, PaperTrail, Logentries and Stackify

需要考慮的主要因素是你正在使用或計劃與Docker整合的日誌管理工具的效能如何。通常,與Docker整合會成為安裝過程中另一個基本步驟,不需要繞什麼彎路。

存在的缺陷就是,生成的日誌只會和你選擇的資訊一樣好,而其他的工具就可以填補這些空缺。

效能監控

應用程式效能監控(APM)工具可以識別程式碼或基礎設施中的效能瓶頸,讓你知道有哪些地方需要進一步提升。這是一個繁忙的空間,常用的工具有

AppDynamics,Dynatrace,New Relic一些開源工具

和日誌管理工具一樣,從Docker的角度出發需要考慮的主要問題是整合工作的效能怎樣。Docker容器已經成熟到足以成為APM安裝過程中的一個步驟。

錯誤追蹤

應用程式會生成錯誤,但是利用現有的複雜的interwoven和分散式程式碼基通常難以直接定位錯誤來源。錯誤追蹤工具可以通過監控生產中的應用程式幫你解決這個難題。

其中有一款叫做OverOps的工具脫穎而出,這是一款完全專注於基於JVM(Java虛擬機器)應用程式的工具,是一款高度優化的本地代理,使用過程中最多增加1%的CPU開銷,幾乎不存在網路或儲存開銷。這對於記憶體空間和效能要求較高的基於容器的JVM來說是一個理想的選擇。

你可以看到實時異常,並記錄錯誤或警告,然後過濾出特定的錯誤,例如與JVM、資料庫或網路有關的錯誤。

如果你發現一些錯誤需要進一步瞭解細節,你可以點進去,裡面會顯示整個呼叫堆疊內引發錯誤的程式碼和錯誤發生時具體的變數狀態。

OverOps有一個專門為容器設計的版本,你可以通過在Dockerfile中新增少量的程式碼來訪問和使用,其中包括Debian /Ubuntu、CentOS / RedHat和Alpine Linux。

一般來說,容器通常在持續變化的應用環境中使用,會定期介紹新程式碼,OverOps可以快速識別新增的錯誤並深入分析其原因。如果你的應用程式是在一個容器叢集上執行,那麼設定過程也是一樣的,OverOps也可以監測並整合所有的錯誤。

容器測量指標

容器本質上是小型的、獨立的機器,所以,例如CPU和記憶體使用率等指標對於跟蹤高階應用程式問題來說至關重要。接下來我將重點介紹基於Docker的容器,也會稍微提一下這個工具是否支援其他選項。

  • Docker Stats

首先,我說一下Docker自帶的API介面,因為很多其他的工具是基於這個介面提供的資料,然後新增來自其他地方的資訊。一個簡單的docker stats命令可以讓你一覽容器的CPU、記憶體和I/O使用情況,其他API端點可以提供任務、日誌、時間等等指標的具體情況。

  • Portainer

我是在一次Docker交流會上接觸到的Portainer,Portainer是一款公認好用的開源Docker管理工具,它本身是在容器內執行,位於兩個無害的連結後面,這兩個連結分別在應用程式的兩個容器上。Portainer可以提供介面友好的視覺化統計資料和日誌明細,應該可以滿足你的要求,另一個吸引人的地方就是這個專案簡單易行並且成本低廉。

  • Datadog

Datadog主要用於為整個堆疊提供詳細的測量指標,您可以將所有被監控的點排列成定製的儀表板,以滿足你的需要,並根據問題和嚴重性觸發適當的通知,當它標記一個潛在問題時,會有內建到Datadog的通訊工具來進行註釋和討論,並且重點突出任何可能衍生的問題,幫你做到提前預防。

如果有一些資料是你的應用程式想要監控但是Datadog卻缺乏正式整合的,你可以使用它們的全訪問API去獲取資料,然後把它們輸入到相同的儀表板、警報和協同工具中。

對於在容器中執行的JVM應用程式來說,有幾個元件反映了Datadog函式的粒度。你可以為你的主機作業系統新增一個代理,然後,監控獨立容器效能和監控容器效能的Docker整合與它們正在執行的應用程式會關聯起來。安裝過程有可能很複雜,這取決於你的主機/Docker配置,由於Datadog想要監控主機、容器引擎和應用程式的效能,所以,將呈現出一個完整的畫面。

比如,如下圖所示,Docker執行在我的Mac上幾個對於Datadog來說非常重要的層:

為了監控容器的內部情況,你通過把每一個代理加入到Dockerfile中,然後執行各個容器內部的代理。如果是監控應用程式的話,使用Java/JMX整合,你可以監控到任何你想監控的資料。

如果這些還不能滿足你,Datadog還可以讓你通過statsD傳送測量指標,它們會提供一個Java庫幫你完成。

  • SignalFX

雖然可以配置好文中提到的所有服務並與微服務友好協作,但這對於SignalFX來說卻是主要關注點之一。SignalFX服務是基於開源collected統計守護程序的,統計守護程序提供了一個現成的生態系統和社群,意味著你可以把collected外掛新增到SignalFX預設模式時無法訪問的collect資料中。

對於Docker容器,SignalFX將使用stats API來監控資料從而顯示CPU、記憶體和硬碟使用情況。一個儀表板將首先向你提供跨所有容器的指標的聚合檢視,並讓你深入到每個docker主機和容器中檢視效能問題所在。

我喜歡SignalFX的一個特性是在系統級別上安裝代理,因此更簡單。比如,如果你想在Ubuntu和Debian上安裝一個Java外掛(其他分佈是一個包括兩個步驟的過程),你只需要通過JMX技術安裝SignalFx的主collectd代理,它包括Java支援和其他代理,你可以在Java應用程式中為來自SignalFX的庫新增自定義集合點。

  • Wavefront

Wavefront和本文中的其他方法不一樣,它不是提供特定的日誌解決方案,而是從其他日誌服務(包括collectd、statsd和JMX)收集時間序列資料。

對於Docker容器,Wavefront有cAdvisor,cAdvisor是一個類似容器的輕量級代理,它用來監控CPU、記憶體和硬碟等底層資源利用率。如果你正在使用ECS、Kubernetes、Mesos或Docker Swarm等容器服務,那麼Wavefront可以提供打包整合選項,這個選項在預設情況下可以提供跨叢集的聚合指標。

Orchestration

隨著容器架構越來越複雜,需求日益變化,你應該需要使用到orchestration工具去構建和管理你的應用程式,同時保持容器和機器問題的一致性。在這個空間裡有幾個主要的玩家,它們都提供了一個監控測量指標的解決方案,因為測量指標是一個非常關鍵的元件。

  • Prometheus

Prometheus是一個雲本地計算基礎專案,它是一個系統和服務的監控系統,當條件為真時,它會觸發警報。這是現在很流行的一款開源工具,所以,你需要花費一定的時間對它進行配置以滿足自己的需求。如果你使用Mesos或Kubernetes去管理和安排你的容器,那麼對於很多用這些工具的人來說,Prometheus會是一個優先選擇。

  • Kubernetes Dashboard

覆蓋Kubernetes叢集的選項本身就是另一篇文章,但值得一提的是預設的Kubernetes儀表板選項,以免你用Kubernetes去管理你的容器,它為每個’pod’、日誌和作業檢視器提供了資源使用的整體情況。

  • Mesos Metrics

如果你在用Mesos管理你的容器,同樣,它也有自己內建的選項去監控它執行的容器。雖然不像Kubernetes儀表板那樣可視性強,但是它可以提供一系列的端點,你需要自己去實現,或者使用一種工具將這些資料視覺化。

結語

容器是小型的、獨立的機器,通常,它的監控能力和一個“正常的”物理機或虛擬機器差不多,主要的區別在於你的應用程式中容器數量的多少,並且它們的生存週期很短,容器不適用於長期執行的服務。組裝好監控堆疊之後,確保你選擇的解決方案使例項的數量容易變化,並且度量標準提供了對你的應用程式的一致概述。