隨著動態(tài)系統(tǒng)架構的復雜性和規(guī)模的增加,IT 團隊面臨著越來越大的壓力來跟蹤和響應其多云環(huán)境中的條件和問題。因此,IT 運營、DevOps 和 SRE 團隊都在尋找對這些日益多樣化和復雜的計算環(huán)境的更高可觀察性。
但什么是可觀察性?為什么它很重要,它實際上可以幫助組織實現什么?
什么是可觀察性?
在 IT 和云計算中,可觀察性是根據系統(tǒng)生成的數據(例如日志、指標和跟蹤)來衡量系統(tǒng)當前狀態(tài)的能力。
可觀察性依賴于源自多云計算環(huán)境中端點和服務的儀器的遙測。在這些現代環(huán)境中,每個硬件、軟件和云基礎架構組件以及每個容器、開源工具和微服務都會生成每個活動的記錄??捎^察性的目標是了解所有這些環(huán)境和技術之間正在發(fā)生的事情,這樣您就可以檢測和解決問題,以保持您的系統(tǒng)高效和可靠,讓您的客戶滿意。
組織通常使用包括開源儀器工具(如 OpenTelemetry)在內的儀器方法組合來實現可觀察性。
許多組織還采用可觀察性解決方案來幫助他們檢測和分析事件對其運營、軟件開發(fā)生命周期、應用程序安全和最終用戶體驗的重要性。
近年來,可觀察性變得越來越重要,因為云原生環(huán)境變得更加復雜,并且故障或異常的潛在根本原因變得更加難以查明。隨著團隊開始收集和使用可觀察性數據,他們也意識到它對業(yè)務的好處,而不僅僅是 IT。
由于云服務依賴于獨特的分布式和動態(tài)架構,因此可觀察性有時也可能指企業(yè)用來解釋云性能數據的特定軟件工具和實踐。盡管有些人可能將可觀察性視為復雜應用程序性能監(jiān)控 (APM) 的流行詞,但在比較可觀察性和監(jiān)控時需要牢記一些關鍵區(qū)別。
監(jiān)控和可觀察性有什么區(qū)別?
可觀察性真的是用另一個名字來監(jiān)控嗎?簡而言之,沒有。雖然可觀察性和監(jiān)控是相關的——并且可以相互補充——但它們實際上是不同的概念。
在監(jiān)控場景中,您通常會預先配置儀表板,這些儀表板旨在提醒您稍后會看到的性能問題。但是,這些儀表板依賴于一個關鍵假設,即您能夠在問題發(fā)生之前預測您會遇到哪些類型的問題。
云原生環(huán)境不適合這種類型的監(jiān)控,因為它們是動態(tài)且復雜的,這意味著您無法提前知道可能會出現什么樣的問題。
在可觀察性場景中,環(huán)境已被充分檢測以提供完整的可觀察性數據,您可以靈活地探索正在發(fā)生的事情并快速找出您可能無法預料的問題的根本原因。
要了解分析師的觀點,您可以聽聽 451 Research 的 Nancy Gohring 如何定義可觀察性:
為什么可觀察性很重要?
在企業(yè)環(huán)境中,可觀察性有助于跨職能團隊理解和回答有關高度分布式系統(tǒng)中正在發(fā)生的事情的具體問題??捎^察性使您能夠了解什么是緩慢或損壞的,以及需要做什么來提高性能。有了可觀察性解決方案,團隊可以收到有關問題的警報,并在問題影響用戶之前主動解決這些問題。
由于現代云環(huán)境是動態(tài)的,并且在規(guī)模和復雜性方面不斷變化,因此大多數問題既不為人知,也不被監(jiān)控??捎^察性解決了“未知未知數”這一常見問題,使您能夠在新類型問題出現時持續(xù)自動地理解它們。
可觀察性也是用于 IT 運營 (AIOps) 的人工智能的一項關鍵能力。隨著越來越多的組織采用云原生架構,他們也在尋找實施 AIOps 的方法,利用 AI 作為在整個 DevSecOps 生命周期中自動化更多流程的一種方式。通過將 AI 應用于一切——從收集遙測數據到分析整個技術堆棧中發(fā)生的事情——您的組織可以獲得對自動化應用程序監(jiān)控、測試、持續(xù)交付、應用程序安全和事件響應至關重要的可靠答案。
可觀察性的價值并不僅限于 IT 用例。一旦您開始收集和分析可觀察性數據,您就有了一個了解數字服務對業(yè)務影響的寶貴窗口。這種可見性使您能夠優(yōu)化轉換、驗證軟件版本是否滿足業(yè)務目標、衡量您的用戶體驗 SLO 的結果,并根據最重要的事項確定業(yè)務決策的優(yōu)先級。
當可觀察性解決方案還使用綜合和真實用戶監(jiān)控分析用戶體驗數據時,您可以在用戶發(fā)現問題之前發(fā)現問題,并根據真實、即時的反饋設計更好的用戶體驗。
可觀察性的好處
可觀察性為 IT 團隊、組織和最終用戶等提供了強大的優(yōu)勢。以下是可觀察性促進的一些用例:
-
應用程序性能監(jiān)控:完整的端到端可觀察性使組織能夠更快地查明應用程序性能問題的根源,包括云原生和微服務環(huán)境引起的問題。高級可觀察性解決方案還可用于自動化更多流程,提高 Ops 和 Apps 團隊的效率和創(chuàng)新。
-
DevSecOps 和 SRE:可觀察性不僅是實施高級工具的結果,而且是應用程序及其支持基礎設施的基本屬性。創(chuàng)建軟件的架構師和開發(fā)人員必須將其設計為可觀察的。然后,DevSecOps 和 SRE 團隊可以在軟件交付生命周期中利用和解釋可觀察的數據,以構建更好、更安全、更有彈性的應用程序。
-
基礎設施、云和 Kubernetes 監(jiān)控:基礎設施和運營 (I&O) 團隊可以利用可觀察性解決方案提供的增強環(huán)境來提高應用程序的正常運行時間和性能,減少查明和解決問題所需的時間,檢測云延遲問題并優(yōu)化云資源利用率,并改善對其 Kubernetes 環(huán)境和現代云架構的管理。
-
最終用戶體驗:良好的用戶體驗可以提升公司的聲譽并增加收入,在競爭中提供令人羨慕的優(yōu)勢。通過在最終用戶注意到之前發(fā)現并解決問題并在甚至提出要求之前進行改進,組織可以提高客戶滿意度和保留率。還可以通過實時回放來優(yōu)化用戶體驗,獲得與最終用戶完全一樣的體驗的窗口,這樣每個人都可以很快就改進的地方達成一致。
-
業(yè)務分析:組織可以將業(yè)務上下文與全棧應用程序分析和性能相結合,以了解實時業(yè)務影響、改進轉換優(yōu)化、確保軟件版本滿足預期的業(yè)務目標,并確認組織遵守內部和外部 SLA。
-
DevSecOps 團隊可以利用可觀察性來更深入地了解他們開發(fā)的應用程序,并自動化測試和 CI/CD 流程,以便他們可以更快地發(fā)布質量更好的代碼。這意味著組織在作戰(zhàn)室和相互指責上浪費的時間更少。從生產力的角度來看,這不僅有好處,而且還能加強對有效協(xié)作至關重要的積極工作關系。
這些組織改進為進一步創(chuàng)新和數字化轉型打開了大門。而且,更重要的是,最終用戶最終會以高質量用戶體驗的形式受益。
如何使系統(tǒng)可觀察?
如果你讀過可觀察性,你可能知道收集日志、指標和分布式跟蹤的測量是取得成功的三個關鍵支柱。但是,僅從后端應用程序觀察原始遙測數據并不能提供系統(tǒng)行為的全貌。
忽視前端視角可能會歪曲甚至歪曲您的應用程序和基礎架構在現實世界中為真實用戶執(zhí)行的全貌。擴展三支柱方法,IT 團隊必須使用用戶體驗數據來增加遙測收集,以消除盲點:
-
日志:這些是在特定時間發(fā)生的離散事件的結構化或非結構化文本記錄。
-
指標:這些值表示為計數或度量,通常在一段時間內計算或匯總。指標可以來自多種來源,包括基礎設施、主機、服務、云平臺和外部來源。
-
分布式跟蹤:這會顯示事務或請求在流經應用程序時的活動,并顯示服務如何連接,包括代碼級詳細信息。
-
用戶體驗:這擴展了傳統(tǒng)的可觀察性遙測,通過在應用程序上添加特定數字體驗的由外而內的用戶視角,即使在預生產環(huán)境中也是如此。
為什么可觀察性的三大支柱還不夠
顯然,數據收集僅僅是開始。僅僅訪問正確的日志、指標和跟蹤并不足以獲得對環(huán)境的真正可觀察性。一旦你能夠使用遙測數據來實現改善最終用戶體驗和業(yè)務成果的最終目標,你才能真正說你已經實現了可觀察性的目的。
組織可以使用其他可觀察性功能來觀察其環(huán)境。OpenTelemetry 等開源解決方案為在云環(huán)境中收集遙測數據提供了事實上的標準。這些開源解決方案增強了云原生應用程序的可觀察性,并使開發(fā)人員和運營團隊更容易在多個環(huán)境中實現對應用程序健康狀況的一致理解。
組織還可以使用真實用戶監(jiān)控來實時了解用戶體驗,跟蹤單個請求的路徑,并深入了解它在此過程中與每項服務的每次交互。這種體驗可以通過綜合監(jiān)控甚至實際會話的記錄來觀察。這些功能通過從用戶角度添加 API、第三方服務、瀏覽器中發(fā)生的錯誤、用戶人口統(tǒng)計和應用程序性能的數據來擴展遙測。這使 IT、DevSecOps 和 SRE 團隊不僅能夠查看請求的完整端到端旅程,還能夠實時了解系統(tǒng)運行狀況。從那里,他們可以在影響應用程序性能之前主動排除運行狀況惡化的區(qū)域。他們還可以更輕松地從故障中恢復,并更深入地了解用戶體驗。
盡管 IT 組織擁有最好的意圖和策略,但他們經常高估已經負擔過重的團隊不斷觀察、理解和處理海量數據和洞察力的能力。盡管存在與可觀察性相關的許多復雜挑戰(zhàn),但克服這些挑戰(zhàn)的組織會發(fā)現值得一試。
可觀察性的挑戰(zhàn)是什么?
可觀察性一直是一個挑戰(zhàn),但云計算的復雜性和快速的變化使其成為組織需要解決的緊迫問題。云環(huán)境會生成大量遙測數據,尤其是在涉及微服務和容器化應用程序時。他們還創(chuàng)建了比團隊過去必須解釋的更多種類的遙測數據。最后,所有這些數據到達的速度使得跟上信息流變得更加困難,更不用說及時準確地解釋它以解決性能問題了。
組織還經常遇到以下可觀察性挑戰(zhàn):
-
數據孤島:多個代理、不同的數據源和孤立的監(jiān)控工具使得很難理解應用程序、多個云和數字渠道(如 Web、移動和物聯(lián)網)之間的相互依賴關系。
-
數量、速度、多樣性和復雜性:幾乎不可能從不斷變化的現代云環(huán)境(例如 AWS、Azure 和 Google 云平臺 (GCP))中每個組件收集的大量原始數據中獲得答案。對于 Kubernetes 和可以在幾秒鐘內啟動和關閉的容器也是如此。
-
手動檢測和配置:當 IT 資源被迫為每種新類型的組件或代理手動檢測和更改代碼時,他們大部分時間都在嘗試設置可觀察性,而不是根據可觀察性數據的見解進行創(chuàng)新。
-
缺乏預生產:即使在預生產中進行負載測試,開發(fā)人員仍然無法觀察或了解真實用戶在將代碼投入生產之前將如何影響應用程序和基礎設施。
-
浪費時間進行故障排除:應用程序、運營、基礎設施、開發(fā)和數字體驗團隊參與故障排除并嘗試找出問題的根本原因,浪費寶貴的時間猜測并嘗試理解遙測并提出答案。
-
然后,存在多個工具和供應商的問題。雖然單個工具可以讓組織對其應用程序架構的一個特定區(qū)域具有可觀察性,但該工具可能無法提供對可能影響應用程序性能的所有應用程序和系統(tǒng)的完全可觀察性。
此外,并非所有類型的遙測數據對于確定問題的根本原因或了解其對用戶體驗的影響都同樣有用。因此,團隊仍然需要在多個解決方案中挖掘答案并煞費苦心地解釋遙測數據的耗時任務,而此時他們可以應用他們的專業(yè)知識來立即解決問題。但是,通過單一的事實來源,團隊可以更快地獲得答案并解決問題。
單一事實來源的重要性
組織需要單一的事實來源才能在其應用程序基礎架構中獲得完整的可觀察性,并準確查明性能問題的根本原因。當組織擁有可以控制云復雜性、捕獲所有相關數據并使用 AI 進行分析的單一平臺時,團隊可以立即確定任何問題的根本原因,無論是應用程序本身還是支持架構。
單一的事實來源使團隊能夠:
-
將 TB 的遙測數據轉化為真正的答案,而不是要求 IT 團隊使用來自不同來源的數據片段拼湊對發(fā)生的事情的理解
-
獲得對他們可能無法看到的基礎設施領域的關鍵上下文洞察。
-
協(xié)同工作并進一步加快故障排除過程,使組織能夠比使用傳統(tǒng)監(jiān)控工具更快地采取行動,這要歸功于增強的可見性。
使 IT 團隊的可觀察性具有可操作性和可擴展性
可觀察性必須以允許資源受限的團隊對實時收集的大量遙測數據采取行動的方式實現,以防止影響業(yè)務的問題進一步傳播甚至首先發(fā)生。這里有一些方法可以使可觀察性具有可操作性和可擴展性。
-
了解上下文和拓撲:這涉及以一種方式進行檢測,以了解高度動態(tài)、多云環(huán)境中可能存在數十億個互連組件的每個相互依賴關系之間的關系。豐富的上下文元數據支持實時拓撲圖,提供對整個堆棧垂直和服務、進程和主機之間的因果依賴關系的理解。
-
實施持續(xù)自動化:持續(xù)自動發(fā)現、檢測和基線化每個系統(tǒng)組件,將 IT 工作從手動配置工作轉移到增值創(chuàng)新項目,這些項目可以優(yōu)先考慮對重要事物的理解??捎^察性變得“永遠在線”和可擴展,因此受限團隊可以事半功倍。
-
建立真正的 AIOps:詳盡的 AI 驅動的故障樹分析與代碼級可見性相結合,解鎖了自動查明異常根本原因的能力,而無需依賴耗時的人工試錯、猜測或關聯(lián)。此外,基于因果關系的人工智能可以自動檢測任何不尋常的變化點,以發(fā)現未被理解或監(jiān)控的“未知未知數”。這些可操作的洞察力推動了 DevOps 和 SRE 團隊所需的更快、更準確的響應。
-
培育一個開放的生態(tài)系統(tǒng):這將可觀察性擴展到包括外部數據源,例如 OpenTelemetry,這是一個由 Dynatrace、Google 和 Microsoft 等供應商領導的開源項目。OpenTelemetry 為提供拓撲映射、自動發(fā)現和檢測以及大規(guī)模可觀察性所需的可操作答案的平臺擴展了遙測收集和攝取。
人工智能驅動的基于解決方案的方法通過解決與云復雜性相關的挑戰(zhàn),使可觀察性真正可行。可觀測性解決方案可以更輕松地解釋以越來越快的速度從多個來源產生的大量遙測數據。借助單一事實來源,團隊可以在問題導致應用程序性能下降之前快速準確地查明問題的根本原因,或者在已經發(fā)生故障的情況下加快恢復時間。
高級可觀察性還通過跨無服務器平臺、Kubernetes 環(huán)境、微服務和開源解決方案的端到端分布式跟蹤來提高應用程序的可用性。通過了解請求從開始到結束的整個過程,團隊可以主動識別應用程序性能問題并獲得對最終用戶體驗的重要洞察。這樣,即使組織擴展其應用程序基礎架構以支持未來的增長,IT 團隊也可以迅速對關注的問題采取行動。
為一切帶來可觀察性
您不能浪費數月或數年時間嘗試構建自己的工具或測試多個供應商,這些供應商只能讓您解決可觀察性難題的一部分。相反,您需要一個解決方案來幫助您的所有系統(tǒng)和應用程序可觀察,為您提供可操作的答案,并盡快提供技術和業(yè)務價值。
Dynatrace 的高級可觀察性在單個平臺中提供所有這些功能,使您的組織能夠駕馭現代云復雜性并更快地進行轉型。文章來源:http://www.zghlxwxcb.cn/news/detail-499230.html
本文 :https://architect.pub/what-observability-not-just-logs-metrics-and-traces | ||
討論:知識星球【首席架構師圈】或者加微信小號【ca_cto】或者加QQ群【792862318】 | ||
公眾號 ? |
【jiagoushipro】 【超級架構師】 精彩圖文詳解架構方法論,架構實踐,技術原理,技術趨勢。 我們在等你,趕快掃描關注吧。 |
|
微信小號 ? |
【ca_cea】 50000人社區(qū),討論:企業(yè)架構,云計算,大數據,數據科學,物聯(lián)網,人工智能,安全,全棧開發(fā),DevOps,數字化. ? |
|
QQ群 ? |
【285069459】深度交流企業(yè)架構,業(yè)務架構,應用架構,數據架構,技術架構,集成架構,安全架構。以及大數據,云計算,物聯(lián)網,人工智能等各種新興技術。 加QQ群,有珍貴的報告和干貨資料分享。 |
|
視頻號 | 【超級架構師】 1分鐘快速了解架構相關的基本概念,模型,方法,經驗。 每天1分鐘,架構心中熟。 |
|
知識星球 | 【首席架構師圈】向大咖提問,近距離接觸,或者獲得私密資料分享。 | ? |
喜馬拉雅 | 【超級架構師】路上或者車上了解最新黑科技資訊,架構心得。 | 【智能時刻,架構君和你聊黑科技】 |
知識星球 | 認識更多朋友,職場和技術閑聊。 | 知識星球【職場和技術】 |
領英 | Harry | https://www.linkedin.com/in/architect-harry/ |
領英群組 | 領英架構群組 | https://www.linkedin.com/groups/14209750/ |
微博?? | 【超級架構師】 | 智能時刻? |
嗶哩嗶哩 | 【超級架構師】 | |
抖音 | 【cea_cio】超級架構師 | |
快手 | 【cea_cio_cto】超級架構師 | |
小紅書 | 【cea_csa_cto】超級架構師 | ? |
網站 | CIO(首席信息官) | https://cio.ceo |
網站 | CIO,CTO和CDO | https://cioctocdo.com |
網站 | 架構師實戰(zhàn)分享 | https://architect.pub? ? |
網站 | 程序員云開發(fā)分享 | https://pgmr.cloud |
網站 | 首席架構師社區(qū) | https://jiagoushi.pro |
網站 | 應用開發(fā)和開發(fā)平臺 | https://apaas.dev |
網站 | 開發(fā)信息網 | https://xinxi.dev |
網站 | 超級架構師 | https://jiagou.dev |
網站 | 企業(yè)技術培訓 | https://peixun.dev |
網站 | 程序員寶典 | https://pgmr.pub? ?? |
網站 | 開發(fā)者閑談 | https://blog.developer.chat |
網站 | CPO寶典 | https://cpo.work |
網站 | 首席安全官 | https://cso.pub????? |
網站 | CIO酷 | https://cio.cool |
網站 | CDO信息 | https://cdo.fyi |
網站 | CXO信息 | https://cxo.pub |
謝謝大家關注,轉發(fā),點贊和點在看。文章來源地址http://www.zghlxwxcb.cn/news/detail-499230.html
到了這里,關于【可觀察性架構】什么是可觀察性? 不僅僅是日志、指標和跟蹤的文章就介紹完了。如果您還想了解更多內容,請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章,希望大家以后多多支持TOY模板網!