HOME > 解決方案

監控工具:滿足您所有需求的六個工具

2021/12/30

監控分散式系統是一項複雜的工作。現代雲端原生架構包含許多可動的部分,您必須觀察它們全部才能真正評估系統的健康狀況。為此,您需要所有可以取得的資訊。因此,在今日,在沒有適當監控的情況下,根本不能啟用應用程式。

幸運的是,市場上可用的監控工具很多,涵蓋了所有可能的使用案例。這些產品已經發展了很長一段時間,為開發人員提供了處理所有這些複雜的問題所需的工具。有了它們,監控更容易和方便了。



 
在這篇文章中,我想談談不同類型的監控工具。我將使用 Splunk 的產品來展示它們能如何幫您監控系統。我相信專用的 SaaS 監控解決方案是許多組織的正確選擇。因此,在這篇文章中,我將向您介紹使用它可以帶來的效益。

監控應用程式示範
首先,讓我們來看一個示範場景。我想使用一個大家都很熟悉的應用程式設定,目的是更容易描繪出各種不同的元素。這張圖是一個很好的開始: 
 



這些是相關的元件:
    服務於前端的單頁式應用程式。這代表大部分的互動都會發生在使用者的瀏覽器中。
    一個容器化後端,為前端提供 API。如果您使用微服務,那麼將會有非常多不同的服務相互通訊。
    執行後端工作負載的 Kubernetes 叢集。同樣地,在實務上也會有多個叢集。我們必須要考慮到開發和生產環境,而且如果系統必須全球可用,那麼在各個地區也會有叢集。上述均由雲端供應商維護,例如 AWS。除
了託管上述元件外,環境中還要具備其他要件:網路 (例如虛擬網路、閘道和負載平衡器)、資料儲存 (包括 SQL 和 NoSQL)、事件資料流處理器,以及 AWS Lambda。 

我還可以繼續寫下去,但我想您已經明白重點了。要注意的事情很多!現在讓我們看看每個元件需要什麼樣的監控。

監控簡介
在我開始討論監控工具之前,有必要先介紹一下監控的基礎知識。
監控的核心是收集和分析執行中系統的資訊。隨著時間變化,系統會出現監控解決方案可以收集並彙總的指標。在指標收集上有許多相關方面:
    提取與推入:監控系統可以主動獲取指標,也可以等待被監控的系統將指標推送給它。
    原生指標與插入的代理:監控系統或讀取系統原生的指標。或者,它會插入一個與被監控系統一起執行的軟體代理程式,然後產生會送回中央監控系統的指標。
    取樣:監控收集指標的頻率如何?指標越多,您建立的全貌就越準確。但是,這也意味著要儲存和在系統中移動的資料更多。
    標記:通常,您會將監控資料表示具備隨時間產生的讀數的時間序列。標籤是附加到資料的額外資訊。例如可以知道是哪台伺服器產生了讀數。
    基數:標籤的功能強大,但如果您有許多不同的標籤和多種可能的值,過多複雜的組合會使得儲存和處理變得困難。 

這些部分我就不贅述了。我只想說,指標就在那裡。下一步是使用監控系統來匯入它們。

指標部分我們先介紹到此。接下來,我們來談工具。

應用程式效能監控
這是維基百科上對應用程式效能監控 (APM) 的描述:
軟體應用程式的效能和可用性的監控和管理。
換句話說,就是即時了解應用程式的行為方式。這種類型的監控適用於範例中的後端 API。APM 工具會監控三個主要指標:
    速率:應用程式收到多少個請求?
    錯誤:發生了什麼樣的錯誤?
    期間:回應請求需要多久的時間? 

對於每個指標,您都需要夠深和夠廣的資訊。您應該能夠深入研究一個請求並對其徹底分析,還要有一個針對所有請求的彙總觀點,以瞭解應用程式的行為方式。請記住避免只看平均值,因為它們可能會誤導您。 


 
來源:https://www.splunk.com/en_us/devops/application-performance-monitoring.html

值得一提的是,Splunk 的 APM 支援 OpenTelemetry,這是一個來自 Cloud Native Computing Foundation (CNCF) 的架構,目的是標準化遙測軟體時所收集的資訊。如果您擔心受制於特定廠商,那麼這是在保持彈性的同時還能獲得產品優勢的絕佳方式。

真實使用者監控
監控工具不見得總是能接觸到用戶端。在過去,當後端將回應發送回用戶端時,整個監控鏈就結束了,瀏覽器中發生的事情與您無關。然而,時代變了。流行的單頁式應用程式使得這種方法不再適用。前端包含的邏輯處理太多,所以還是要加以監控。
真實使用者監控 (RUM) 能夠處理這一點。它嵌入在瀏覽器執行的 JavaScript 中,能幫助了解使用者如何與您的應用程式互動。 
 


來源:https://www.splunk.com/en_us/software/real-user-monitoring.html

這裡的建置組塊是使用者工作階段。您可以追蹤所有使用者工作階段及其點擊路徑,進而了解使用者如何與您的軟體進行互動。由於這部分的應用程式並不是在您的伺服器上執行,所以您需要額外的資訊,例如:
    使用哪種瀏覽器? 
    使用者的地理位置在哪裡? 
    他們使用哪種作業系統? 

與 APM 類似,您需要高保真的請求和彙整結果。

綜合監控
內部的開發人員會擔心系統是如何運作的。但是,使用者看不到這一點。從他們的角度來看,您的應用程式是一個黑箱,不是可以運作,就是不能運作。 
綜合監控可模擬真實使用者與應用程式的互動。綜合監控就像是在全球多個資料中心執行的高階測試。它們比從開發人員的電腦甚至是 CI/CD 代理執行的測試還能說明應用程式的狀態。
請記住,綜合監控是一種黑箱測試。它無法準確告訴您出了什麼問題,但可以偵測使用者是否無法使用您的應用程式。 

 

來源:https://www.splunk.com/en_us/software/synthetic-monitoring.html

想要確保系統始終可用時,這種監控是第一道防線。我將其視為持續性的端對端測試。它適用於前端和後端元件。這取決於您要監控的內容。

綜合測試的另一個方面是效能。您可以將這些測試視為系統預期效能的基準。歷史資料可以讓您了解系統效能的演變。如果您擁有資料,就能夠進行效能改進並評估其是否有效。

一旦您有了一套綜合測試,自然就會將它們視為預警系統。如果有問題,系統應該用警報通知工程人員,這一點我們將在收到通知時看到。

基礎架構監控
如今,越來越多的工作負載是在雲端執行。如果您實作基礎架構即程式碼,那麼會將您的基礎架構視為另一個透過程式碼管理的工件。在這種情況下,監控即程式碼會是一種合乎邏輯的演變。即使您手動佈建基礎架構,它也需要監控。 

基礎架構是一個很大的主題。在較低的抽象層,您會有諸如儲存 (S3)、負載平衡 (ALB) 或運算執行個體 (EC2) 等物件。雖然雲端供應商會負責提供和運作基礎架構,但您仍然需要監控在那裡執行的內容,因為它是您的技術堆疊的一部分。基礎架構監控可以幫助您做到這一點。

如果您正在執行一些容器協調軟體怎麼辦?當然,我想的是 Kubernetes。現在還有不使用 Kubernetes 的組織嗎?我想應該沒有。然而,Kubernetes 是一個複雜的野獸,絕對值得透過多種監控來仔細檢視它。只是監控叢集中執行的應用程式還不夠。Kubernetes 是由不同的資源類型組成,例如執行在節點上的 Deployment 或 Service。如果您想獲得當前狀態的全貌,就需要監控所有這些物件。 
 


Source: https://www.splunk.com/en_us/devops/kubernetes-monitoring.html

其他基礎架構元件呢?Splunk 能夠幫您!假設您有幾個想要監控的無伺服器功能 (例如 AWS Lambda)。無伺服器功能是隨需執行,並在完成後立即消失。這使得它們非常靈活,但也更難監控。一個經過整合的監控系統可以減輕您的負擔。與 APM 類似,您想要注意速率、錯誤和持續時間。 
 


來源:https://www.splunk.com/en_us/devops/serverless-monitoring.html

我參與過將大量現有應用程式移轉到雲端的專案。這是一個需要數月甚至數年的過程。如果您使用監視工具來觀察兩邊,那麼工作起來會更輕鬆一些。
透過全面了解整個堆疊中所有層,能更容易實現「誰建置,誰維護」的心態。

從觀察到通知
監控使您可以了解系統的情況。但您還是需要找人去查看它。高度可用的系統不能等待有人檢查一切是否正常。萬一發生事故就太慢了。您會希望負責人立即知道出現了問題。
那該怎麼做?您可以將監視器轉換為偵測器,利用我們所知道的以及使用 AI/ML 技術來識別出我們可能還不知道的事物。每當指標達到某個閾值時,偵測器就會觸發警報,並立即通知負責人。接著負責人會介入,並透過本文介紹的全面性監控工具解決問題,挽救局面。乾淨俐落。

小心錯誤設定的警報
不過,這並不像聽起來那麼容易。事實上,工程人員被在任何時間點觸發的大量警報壓垮很常見的。或是相反的,儘管系統著火了,相關人員仍未收到警報。
當您調整警報的閾值時,還會出現另一個問題。那就是拿捏時需要一點經驗。如果閥值不正確,警報觸發太頻繁,或是根本不會被觸發。結果都不是您想要的。警報的觸發頻率應該是有意義的。
營運應用程式時,警報疲勞是一個真正的風險。如果您的開發人員由於誤報而對警報失去戒心,他們將開始忽略收到的簡訊或通報。這會是災難的開始。
如果您之前遇過待命的輪值,可能就會知道使用不合標準的工具的痛苦。Splunk On-Call 中的這句話比我說過的結論來得好:
「讓待命 (on-call) 不那麼糟糕」 
 


來源:https://www.splunk.com/en_us/software/splunk-on-call.html

一個好的待命工具可以集中排程、減少不必要的雜訊,並確保在正確的時間提醒正確的人。在更複雜的環境中,將合適的人員分配到正確的警報群組並非易事。從本質上來說,它就像一本巨大的行事曆,您想確保任何一天都有人看守。當然,您不會想自己管理這本行事曆。相反的,您可以讓工具來幫助您。有了工具的組織化協助,使其更易於管理。

不要忘記安全
如果您執行任何軟體,並且至少有一個使用者,那麼安全就是您的問題。正如無數的資料外洩經常提醒我們的,安全仍是許多組織沒有足夠重視的問題。開發安全營運 (DevSecOps) 實務等鼓勵從一開始就考慮安全問題。安全性始於在一開始開發應用程式時就使用最佳作法。不過,並非僅止於此。您需要持續監控以領先攻擊者一步。

難題之一是安全資訊和事件管理 (SIEM)。您希望根據收集的所有資料識別威脅,然後將這些威脅轉換成為以風險為基礎的警報。就像待命,警報疲勞是一個問題。一個工具需要確保操作人員不會收到不必要的警報。 
 


來源:https://www.splunk.com/en_us/software/enterprise-security.html

安全的另一部分是監控可疑行為。為此,使用者行為分析 (UBA) 應運而生。這種系統會在許多使用者中尋找惡意模式,應用機器學習方法,以便讓您儘早發現這些威脅。 


 
來源:https://www.splunk.com/en_us/software/user-behavior-analytics.html

即使您擁有一流的安全保健措施,仍有可能發生安全漏洞。一旦發生這種情況,保存證據是非常重要的。您不會每天會使用這種資訊,但在需要時將非常有用:
    攻擊者做了什麼?能追溯他們的腳步嗎?
    存取了哪些資訊?這會有法律後果。 
 


來源:https://www.splunk.com/en_us/cyber-security/forensics-and-investigation.html

如您所見,這裡有一些工具可以讓您在晚上睡得更好。不過,不要自滿。工具無法取代良好的安全作法——只會增強它們。

把監控作為一個平台
當我說監控有很多方面要談時,不是隨口說說的!我在這裡展示了一大堆監控工具。每一個都有自己的監控風格。即便如此,還有更多我沒有接觸到的工具。它們本身都是非常可靠的產品。但是您的應用程式並不是一組分散的區塊,所有部件都是相互關聯的。一個地方出現警告,可能表明另一個完全不同的地方有問題。

這裡就是像 Splunk 這樣的整合平台可以凸顯價值的地方。監控並不是標記個別元件的功能選項。如果您想提供真正可靠的服務,關聯不同指標並在不同層之間輕鬆切換的能力是非常寶貴的。為您的工程人員提供合適的工具,他們將會覺得自己無所不知。 



 
能自己開發這個工具嗎?是的,當然。只要夠努力,您可以複製出這個整合功能。不過代價是什麼?我敢說代價遠比您想像的要多。我見過不止一個組織嚴重低估這項工作,後來後悔不已。在走這條路之前,您應該至少考慮一個現有的解決方案。如您所見,Splunk 可以處理絕大多數的監控要求。我在本文中介紹的所有工具都是緊密相連的。您可以一鍵從 RUM 追蹤切換到 APM。或者在 On-Call 中輕鬆地將任何指標轉換為警報。再怎麼強調一點也不為過:這種程度的整合很難實現。

日誌觀察器
日誌彙整是監控的一部分嗎?當您想瞭解系統中發生的一切時,界限就不是那麼明確了。如果您正在觀察某個指標,檢查相關的日誌會提供更多參考資料。那能幫上一點忙,對吧?


 
來源:https://www.splunk.com/en_us/software/log-observer.html

正如我所提到的,關聯性是使用整合式平台時一個受到歡迎的好處。如果您正在觀察一項指標或追蹤所攔截的事件,那麼如果能找出與日誌事件的明確關聯,將可節省大量精力。當您不想花費過多心力來建立這種連結時尤其如此,因為它是可觀測性平台的一部分,免費又方便。

我們學到了什麼?
監控不是一個單一的概念。隨著架構的發展,不同的領域需要稍微使用不同的方法。雲端原生架構就是一個明顯的例子。其中有許多特別的可動部件。它們能從專用的監控工具獲得很多效益。

您可以為您執行的所有內容建立自訂的監控,但這會轉移工程人員應該要專心提供業務價值的注意力。根據我的經驗,使用背後有公司全力支持的專用工具通常比自己開發的工具更具成本效益。 

還有一個值得一提的重要好處。一個整合性方法可關聯起不同來源的信號。困難的問題幾乎都不是在網路邊界內。如果您的工具可以讓您從一個區域切換到另一個區域,那將顯著提高可見度。打破孤島是在組織中採用開發營運思維的重要目標。

如果您想研究我在本文中提到的工具,請查看這個連結。最重要的是,無論您採用何種方法,都要像對待第一類物件 (first-class citizen) 一樣對待監控。

________________________________________
這篇文章是由 Mario Fernandez 撰寫。Mario 以開發軟體為生——然後他回家繼續研究軟體,因為他實在是樂此不疲。他熱衷於各種工具和作法,例如持續交付。而且他參與過前端、後端和基礎架構的專案。
 
作者
Greg Leffler
Greg 是 Splunk 可觀測性團隊的負責人,任務是向全世界傳播可觀測性的好消息。Greg 的職業生涯從 NOC 到 SRE,再到 SRE 管理,並於閒暇時間從事安全和編輯的角色。除了可觀測性之外,Greg 的專業領域還包括招聘、培訓、SRE 文化和運作高效率的遠距團隊。Greg 擁有美國歐道明大學的工業與組織心理學碩士學位。