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

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

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

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

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

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

1. 明確目標(biāo)

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

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

2. 選擇最佳可觀測(cè)性解決方案

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

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

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

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

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

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

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

3. 代碼插樁

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

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

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

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

這種方法更簡單，因?yàn)槟墓こ處煙o需成為查詢語言(如 PromQL)、環(huán)境架構(gòu)和規(guī)模、可觀測(cè)性解決方案的底層數(shù)據(jù)模型或測(cè)試中的查詢?cè)谏a(chǎn)環(huán)境中的性能等方面的深度專家。

5. 跟蹤資源利用率

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

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

6. 日志記錄和日志聚合

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

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

7. 分布式跟蹤

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

8. 警報(bào)和通知

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

9. 遵循最佳實(shí)踐和更新

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

10. 控制成本

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

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

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

云原生入門

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