工程團隊使用集成了Kubernetes管理與編排層的云原生可觀測性平臺，有助于更快達成業(yè)務(wù)目標(biāo)。

譯自10 Ways Kubernetes Observability Boosts Productivity, Cuts Costs，作者 Eric Schabell 是 Chronosphere 的布道總監(jiān)。他在開發(fā)社區(qū)中被認為是演講者、講師、作家和棒球?qū)＜摇?/p>

云原生很快成為數(shù)字化轉(zhuǎn)型的首選路徑，但它并非沒有增加復(fù)雜性和成本。不同于基于虛擬機(VM)的基礎(chǔ)設(shè)施，采用 Kubernetes 的云原生環(huán)境總是在變化；它們包含了數(shù)千個容器和微服務(wù)，產(chǎn)生更多數(shù)據(jù)，而且相互依賴性更強。

為了解決這些挑戰(zhàn)，工程團隊可以使用集成了 Kubernetes 管理和編排層的云原生可觀測性平臺，以更快實現(xiàn)數(shù)字化業(yè)務(wù)目標(biāo)、保護收益和支持創(chuàng)新。

如果您的組織希望運行云原生可觀測性和 Kubernetes 管理解決方案，以下是在Kubernetes 可觀測性方面需要遵循的10條最佳實踐。

遵循這10個簡單步驟，可以幫助您掌控或重新掌控可觀測性數(shù)據(jù):

1. 明確目標(biāo)

首先，確立數(shù)字化轉(zhuǎn)型計劃愿景，并設(shè)定實現(xiàn)目標(biāo)。例如，如果是一款允許混合工作模式與客戶聯(lián)系的應(yīng)用程序，服務(wù)級別目標(biāo)(SLOs)應(yīng)該是什么？

反過來，目標(biāo)平均修復(fù)時間(MTTR)是多少，或者組織可以承受多長時間的停機時間？應(yīng)該允許什么程度的資源峰值，以及可以投入多少資金都應(yīng)該從一開始就確定。由此向后推，您就可以確定需要什么樣的平均檢測時間(MTTD)才能實現(xiàn)目標(biāo)。

2. 選擇最佳可觀測性解決方案

與每個數(shù)字化轉(zhuǎn)型項目一樣，您的團隊需要尋求盡可能最佳的解決方案或解決方案組合，這將取決于您的用例和目標(biāo)。監(jiān)控 Kubernetes 或?qū)崿F(xiàn)云原生并沒有一種固定方法，它取決于您的人員、組織、業(yè)務(wù)目標(biāo)和現(xiàn)有技術(shù)堆棧。

在為組織選擇最佳可觀測性解決方案時，需要考慮以下類型工具:

• 開源指標(biāo)工具: Prometheus 是 Kubernetes 指標(biāo)的事實標(biāo)準(zhǔn)。由于它具有可擴展性限制，人們通常會選擇添加時序數(shù)據(jù)庫，如 Thanos、Cortex 或 M3DB 用于長期存儲。
• 開源日志工具: 在云原生環(huán)境中，許多人會查看日志聚合工具，如 Cloud Native Computing Foundation (CNCF) 項目 Fluentd，它充當(dāng)數(shù)據(jù)收集器，可將數(shù)據(jù)發(fā)送到多種不同的后端。
• 開源追蹤工具: Jaeger 開始時是最受歡迎的開源追蹤工具之一。后來被 OpenTelemetry 所取代，OpenTelemetry 目前是 CNCF 中活躍程度僅次于 Kubernetes 的項目，是追蹤數(shù)據(jù)的事實標(biāo)準(zhǔn)。
• 開源成本優(yōu)化工具: 這些工具報告有關(guān)集群和資源的成本信息，以便您采取行動。這一類別中最受歡迎的是 Kubecost 和 OpenCost。
• 非開源工具: 許多供應(yīng)商提供可觀測性工具。這里最重要的是要評估它們在可觀測性數(shù)據(jù)編碼、傳輸、引入和查詢方面對開放標(biāo)準(zhǔn)的使用。尋找這些可觀測性供應(yīng)商與 CNCF 項目的集成，如 Chronosphere 致力于遵守社區(qū)標(biāo)準(zhǔn)。

一旦確定所需的解決方案，就該決定如何利用它們了。對于任何依賴 Kubernetes 的云原生生態(tài)系統(tǒng)收集器而言，開源都是一個關(guān)鍵特性。

以下是部署和訪問可觀測性的一些關(guān)鍵方式:

• 開源自主管理(又稱 DIY): 這是大多數(shù)組織的切入點，因為他們希望控制自己的數(shù)據(jù)和可觀測性創(chuàng)新，而不受供應(yīng)商時間線和鎖定的影響。如果環(huán)境無需快速或大規(guī)模擴展，內(nèi)部可觀測性是一個不錯的選擇。但是，您必須擁有運行、托管、操作、托管和監(jiān)控解決方案的資源、經(jīng)驗和規(guī)模，且該可用區(qū)域與運行應(yīng)用程序生產(chǎn)環(huán)境的區(qū)域不同。
• 專有 SaaS 解決方案: DevOps 和站點可靠性工程(SRE)組織的健康和發(fā)展往往是選擇 SaaS 的一個主要因素。如果您在非容器化環(huán)境中有現(xiàn)有的軟件即服務(wù)(SaaS)可觀測性供應(yīng)商，您可能可以將其擴展到監(jiān)控 Kubernetes，但您需要注意一些陷阱:由于定價是為面向 VM 的環(huán)境構(gòu)建的，許可成本高昂;儀表板速度緩慢;由于數(shù)據(jù)量太大和缺乏對 Kubernetes 集群中關(guān)鍵指標(biāo)的可見性，導(dǎo)致警報延遲。
• 開源兼容 SaaS 解決方案: 這條"黃金路徑"通過提供對整個堆棧的全面、可擴展的可見性，以及數(shù)據(jù)控制和無供應(yīng)商鎖定的所有優(yōu)勢，簡化了實施過程。完全與 Prometheus 和 OpenTelemetry 兼容的解決方案可以讓您獲得兩全其美的好處。因此，您的組織不僅可以獲得開源解決方案帶來的回報，還可以獲得社區(qū)、生態(tài)系統(tǒng)和教程的支持。開源服務(wù)還提供了回到自托管的退出通道，以應(yīng)對目標(biāo)發(fā)生變化的情況。

選擇解決方案的最后一步是選擇云提供商工具。對于單一云環(huán)境，使用云提供商的分析和監(jiān)控工具是明智之舉，因為您可以獲得價格優(yōu)勢，并借助與現(xiàn)有云基礎(chǔ)設(shè)施的深度集成實現(xiàn)可見性。無論您使用單云還是多云，您都要對客戶體驗負責(zé)。

3. 代碼插樁

為了充分利用所使用的工具，并實現(xiàn)分布式追蹤(參見第7點)，您需要檢測代碼。在實踐中，檢測代碼意味著收集數(shù)據(jù)，然后將其發(fā)送到任何所需位置——不會再像應(yīng)用程序性能監(jiān)控(APM)或基礎(chǔ)設(shè)施監(jiān)控提供商那樣存在供應(yīng)商鎖定。許多解決方案可在沒有太多工作量的情況下開箱即用，但通過檢測代碼，您可以獲得最佳可用數(shù)據(jù)，從而采取最佳行動方案。

在開源世界中，Prometheus 是了解 Kubernetes 集群健康狀況的標(biāo)準(zhǔn)。但是，要謹慎行事，因為您實際上可能不需要所有發(fā)出的數(shù)據(jù)。如果數(shù)據(jù)對您和組織沒有用處，就會成為負擔(dān)。針對特定用例和業(yè)務(wù)需求進行調(diào)整，始終比一刀切的監(jiān)控體驗更好。如果您正在使用 Prometheus 儀表板學(xué)習(xí)，請注意這一點。

4. 使用儀表板收集和可視化可觀測性數(shù)據(jù)

您的工程師將負責(zé)創(chuàng)建可交付數(shù)據(jù)可視化的儀表板。這樣，您就可以迅速掌握系統(tǒng)中正在發(fā)生的情況。許多解決方案都包含儀表板系統(tǒng)。例如，Chronosphere 通過Query Accelerator技術(shù)幫助您體驗更快的儀表板。在整個系統(tǒng)中，它運行迅速、高效，無需手動優(yōu)化。

這種方法更簡單，因為您的工程師無需成為查詢語言(如 PromQL)、環(huán)境架構(gòu)和規(guī)模、可觀測性解決方案的底層數(shù)據(jù)模型或測試中的查詢在生產(chǎn)環(huán)境中的性能等方面的深度專家。

5. 跟蹤資源利用率

資源利用率的顯著變化可能意味著好消息或壞消息——您的客戶群體突然激增或出現(xiàn)了故障。無論哪種情況，要用現(xiàn)有的 APM 或基礎(chǔ)設(shè)施監(jiān)控工具來了解正在使用多少資源、使用哪種資源、供哪個應(yīng)用程序使用以及是否過度使用資源，這都是一個挑戰(zhàn)。

來自 Chronosphere 的可觀測性數(shù)據(jù)優(yōu)化周期可以通過分析、完善和操作等過程，幫助您的組織更好地了解并采取行動來控制可觀測性數(shù)據(jù)的成本，從而克服這些挑戰(zhàn)。

6. 日志記錄和日志聚合

在云原生世界中，日志記錄很重要，因為它幫助團隊捕獲、聚合和理解系統(tǒng)事件。在云原生架構(gòu)中，事件數(shù)量增加，但獨立系統(tǒng)中不相關(guān)的日志數(shù)量也會增加。這使得很難找到所需的數(shù)據(jù)并對問題進行故障排查。雖然指標(biāo)是診斷問題癥狀的重要工具，但您需要使用跟蹤來定位問題，而日志最適合發(fā)現(xiàn)問題的根本原因。

要在 Kubernetes 環(huán)境中控制日志，您需要能夠聚合和過濾數(shù)據(jù)，以減少浪費，節(jié)省成本，并及時輕松地找到所需數(shù)據(jù)。

7. 分布式跟蹤

如果沒有正確檢測代碼(參見第2點)，就無法支持分布式跟蹤。然而，分布式跟蹤可讓您查看請求在整個系統(tǒng)中執(zhí)行的情況。這是您確定某個單一功能運行時間過長的方式，以便在影響客戶體驗之前深入了解原因。

8. 警報和通知

完成1-7步后，最佳實踐是設(shè)置警報和通知，發(fā)送給您自己或團隊。這樣，一旦出現(xiàn)問題，就能及時進行分類和修復(fù)。

9. 遵循最佳實踐和更新

這一步是常識性的。新的更新幾乎每天都在出現(xiàn)，要實現(xiàn)未來防護并不容易。請跟上解決方案補丁和可觀測性最佳實踐的步伐。在可能的情況下添加自動化，以消除費時且容易出錯的手動流程。

10. 控制成本

最佳可觀測性平臺將幫助您控制云成本和可觀測性支出。選擇諸如 Chronosphere 及其控制平面的解決方案，可為您提供沿著可觀測性渠道的不同工具，使組織能夠:

• 了解所擁有的數(shù)據(jù)
• 分析哪些是有用的，哪些是浪費
• 了解是否有人對某個指標(biāo)發(fā)出警報
• 查看哪個標(biāo)簽導(dǎo)致了最大的基數(shù) - 成本最高，但使用最少

這種透明度可讓有價值的才華橫溢的工程師專注于對業(yè)務(wù)更有影響力的項目。在實施成本控制后，您就可以開始微調(diào)數(shù)據(jù)，了解其有用性；根據(jù)可觀測性支出為團隊設(shè)置配額，并跨獨立微服務(wù)運行的團隊進行成本核算趨勢分析。

云原生入門

對于希望利用數(shù)字化轉(zhuǎn)型力量的企業(yè)而言，云原生環(huán)境是必不可少的，但必須配備可以互相協(xié)作的正確工具并采用最佳實踐。Chronosphere 及其合作伙伴從頭構(gòu)建，旨在抽象云原生環(huán)境的復(fù)雜性，優(yōu)化數(shù)據(jù)并減少工程師的工作壓力。