一文搞懂基於 OpenTelemetry 進行 Kubernetes 全鏈路觀測

Hello folks，我是 Luga，今天我們來聊一下雲原生生態核心技術—— 可觀測性，即 “基於 OpenTelemetry 進行 Kubernetes 全鏈路觀測” 。

基於 OpenTelemetry 徹底改變我們的觀測意識

隨着組織越來越多地採用 Kubernetes 來部署和管理應用程序，Kubernetes 已成爲事實上的容器編排標準。在這樣的動態 Kubernetes 環境中，觀測資源對於確保平臺上運行的應用程序的健康至關重要。

然而，動態的 Kubernetes 環境給觀測帶來了很大的複雜性。應用程序不斷地進行擴展、部署和更新，傳統的依賴代理或輪詢的監控技術無法滿足 Kubernetes 環境的需求，因爲它們無法跟上環境變化的速度和分佈式架構的複雜性。

如果無法及時提供實時觀測功能，將導致平均解決時間（MTTR）的增加。這將顯著影響應用程序的整體可用性和性能，對業務本身產生負面影響。

爲了克服傳統監控解決方案的這些缺點，技術團隊依靠使用 OpenTelemetry 的創新方法來觀測 Kubernetes 環境。通過採用 OpenTelemetry，我們可以使用標準化的方法來收集、處理和導出遙測數據。

OpenTelemetry 提供了一套統一的 API 和工具，使得在 Kubernetes 環境中收集和處理遙測數據變得更加簡單和一致。它支持跨語言和跨平臺，可以與不同的組件和工具集成。這使得管理員能夠實時監測應用程序的性能指標、日誌和跟蹤數據，並使用可視化工具進行分析和故障排除。

通過 OpenTelemetry，技術團隊可以更好地瞭解 Kubernetes 環境中應用程序的行爲和性能，快速識別和解決潛在的問題。這將有助於減少 MTTR，提高應用程序的可用性，並確保業務能夠正常運行。

當前觀測 Kubernetes 所面臨的挑戰

傳統觀測 Kubernetes 環境面臨一些挑戰，這些挑戰可能限制組織對其應用程序和基礎設施的完整可見性和細粒度控制。

1、複雜性：Kubernetes 是一個高度複雜的容器編排平臺，由多個組件和服務組成。傳統的觀測方法可能無法有效應對這種複雜性，導致難以收集和分析相關的監控數據。

2、動態性：Kubernetes 環境中的應用程序和資源拓撲通常是動態變化的，包括 Pod 的創建、刪除、縮放等操作。傳統觀測方法可能無法及時跟蹤這些變化，導致監控數據的準確性和一致性受到影響。

3、高度分佈式：Kubernetes 環境中的應用程序通常是分佈式的，由多個容器和服務組成。傳統的觀測方法可能無法提供對分佈式系統的全面可見性，導致難以追蹤和分析應用程序的端到端性能和依賴關係。

4、多樣性：Kubernetes 生態系統中存在多種不同的組件和工具，用於不同的觀測需求，例如 Prometheus、Grafana、ELK 堆棧等。組織可能需要整合和管理這些不同的工具，以獲得全面的觀測能力。

5、彈性和可擴展性：Kubernetes 環境的彈性和可擴展性使得應用程序的規模和負載模式可能隨時發生變化。傳統觀測方法可能無法有效應對這種變化，導致監控數據的準確性和時效性受到影響。

面對這些挑戰，組織需要採用更先進的觀測方法和工具，如 OpenTelemetry，以應對 Kubernetes 環境的複雜性和動態性，提供更全面和準確的觀測能力。這樣可以幫助組織更好地理解和管理其應用程序和基礎設施，提高性能和可用性，並加快故障排除和問題解決的速度。

OpenTelemetry 提供了一種方法，可以從應用程序和 Kubernetes 環境中收集這些觀測參數，包括輕鬆實現分佈式跟蹤。這使得組織能夠快速識別和診斷問題，從而提高故障排除的效率。

通過 OpenTelemetry，組織可以獲得更全面的可見性，瞭解應用程序的各個組件之間的相互依賴關係和性能表現。它提供了一種標準化的方式來收集和傳輸監控數據，使組織能夠深入瞭解應用程序的運行狀況，並快速響應潛在的問題。

因此，使用 OpenTelemetry 可以幫助組織克服傳統觀測方法的侷限性，提供更全面、細粒度的觀測能力，從而提高對分佈式應用程序的理解和故障診斷能力。

揭祕 OpenTelemetry 在觀測 Kubernetes 中的關鍵作用

儘管有多種方法可以對 Kubernetes 進行觀測，但與傳統的觀測選項相比，使用 OpenTelemetry 提供了更多的優勢。然而，如果完全忽視對業務應用程序的觀測，可能會對其性能和可用性產生嚴重而可怕的影響。

忽視觀測意味着組織將無法準確地瞭解應用程序的運行狀況和健康狀態。沒有及時的觀測數據，組織將無法獲得關鍵的指標和指示器，以評估應用程序的性能表現和資源利用情況。這將使組織難以發現潛在的性能瓶頸、資源爭用或其他可能導致應用程序性能下降和可用性問題的因素。

而同時，缺乏觀測將導致組織擁有更長的平均解決時間（MTTR），因爲組織將沒有必要的指標來有效和高效地識別應用程序中問題的根本原因。通過監控 Kubernetes Cluster 中的關鍵組件，可以顯著降低 MTTR。

組織可能會在沒有充分觀測其 Kubernetes 環境的情況下遇到一些問題，例如 Kubernetes Pod 崩潰循環、持續的卷故障和作業故障。所有這些問題都會導致 Kubernetes 環境和在這些資源上運行的應用程序出現嚴重的停機時間和性能問題。

另一個需要通過充分觀測來改進的關鍵方面是識別應用程序的分佈式組件和運行這些服務的基礎設施之間的依賴關係所需的端到端可見性。如果對應用程序的整體情況缺乏瞭解，組織就無法對可能出現的問題進行分析和深入研究，從而增加了縮小根本原因和減少平均解決時間（MTTR）的複雜性。

觀測還爲異常檢測奠定了基礎，這允許組織識別與應用程序正常操作不符的行爲。這一點在嘗試解決可能影響應用程序性能的異常時變得尤爲重要。

OpenTelemetry 提供的額外好處確保了觀測實施不當造成的挑戰最小化，團隊可以通過解決 MTTR 時間增加、可見性有限等問題來充分利用這些功能。因此，使用 OpenTelemetry 觀測 Kubernetes 是至關重要的。

最佳實踐：確定關鍵觀測目標

在收集和分析來自 Kubernetes 環境的指標時，有一些關鍵指標需要考慮。以下內容提供了組織所需收集的關鍵指標的良好基礎知識。

1、Node 指標

此指標提供有關各個 Kubernetes Cluster 節點性能和資源使用情況的詳細信息，包括 CPU、內存和網絡使用情況。通過監測節點指標，可以瞭解到節點的負載狀況，發現資源瓶頸並進行容量規劃。

2、Pod 指標

此指標提供有關在節點上運行的 Pod 資源使用和操作的信息，包括 CPU、內存和網絡使用情況。通過監測 Pod 指標，可以瞭解到每個 Pod 的資源消耗情況，識別資源密集型的 Pod 並進行優化。

3、Container 指標

此指標提供有關 Pod 中運行的各個容器性能和資源使用情況的詳細信息，包括 CPU、內存和網絡使用情況。通過監測容器指標，可以深入瞭解每個容器的資源消耗情況，找到資源泄漏或不良配置的容器並進行調整。

4、API Server 指標

此指標包括請求延遲、響應時間和錯誤率，提供有關 Kubernetes API 服務器功能和可用性的詳細信息。通過監測 API 服務器指標，可以瞭解 API 服務器的性能狀況，識別潛在的性能瓶頸和故障情況。

5、Etcd 指標

此指標包括磁盤使用情況、響應時間和錯誤率，提供有關 Etcd Cluster 操作和狀態的詳細信息。通過監測 Etcd 指標，可以瞭解 Etcd Cluster 的健康狀況、性能瓶頸和故障情況。

通過收集和分析這些關鍵指標，組織可以獲得關於 Kubernetes 環境中 Node、Pod、Container、API Server 和 Etcd Cluster 的詳細信息。這將幫助組織實時監測和優化 Cluster 性能，提高應用程序的可靠性和性能。

基於 OpenTelemetry 進行 Kubernetes 的解決方案

在 Kubernetes 上部署一個 OpenTelemetry 收集器，這個收集器將負責接收和處理跟蹤數據。一旦部署完成，我們可以使用 OpenTelemetry 提供的 OTEL 檢測庫（基於 Go 語言編寫的應用程序）將跟蹤數據發送到收集器。

一旦跟蹤數據到達收集器，它將被傳送到 Jaeger 收集器，進一步處理和存儲。最後，我們可以使用 Jaeger 的用戶界面（UI）來可視化這些跟蹤數據，以便更好地理解應用程序的性能和行爲。

下面的圖示展示了這個流程，包括應用程序、OpenTelemetry 收集器和 Jaeger 之間的交互，以及跟蹤數據的流動路徑。具體可參考：

在此方案中，我們的 OTEL 設置如下所示：

在實際的業務場景中，OpenTelemetry 可與 Kubernetes 結合使用，從 Kubernetes Cluster 上運行的容器化應用程序收集遙測數據。OpenTelemetry 提供了多個 Kubernetes 特定的組件和集成，使我們可以輕鬆地在 Kubernetes 環境中收集和處理遙測數據。

這些包括：

1、Kubernetes 特定的工具

Kubernetes API 服務器、Etcd、Kubelet 等。這些儀器可用於生成用於 Pod 創建、刪除和擴展等操作的遙測數據。

2、Kubernetes 元數據注入

自動將 Kubernetes 特定的元數據（例如 Pod 名稱、Pod 命名空間和容器 ID）注入到遙測數據中。這樣可以更輕鬆地將遙測數據與 Kubernetes 特定的元數據關聯起來，並診斷與容器化應用程序相關的問題。

3、Kubernetes 感知採樣

根據 Kubernetes 特定的元數據（例如 Pod 名稱、命名空間或服務名稱）採樣遙測數據。這有助於減少發送到後端的遙測數據量並提高性能。

4、Kubernetes 部署

OpenTelemetry 可以部署爲 Kubernetes 部署或守護進程集，從而可以輕鬆在 Kubernetes 環境中擴展和管理 OpenTelemetry 組件。

通過基於 OpenTelemetry 的 Kubernetes 解決方案，我們可以實現對 Kubernetes Cluster 中應用程序的端到端監測和可觀察性，從而幫助我們更好地理解應用程序的性能、排查問題，並採取適當的優化措施，以提高應用程序的可靠性和性能。

實施 OpenTelemetry 的核心步驟

通過實施 OpenTelemetry 來觀測 Kubernetes 環境，團隊組織可以收集和分析各種指標，並將這些指標與從應用程序的不同部分收集的其他指標相關聯，以更好地瞭解整體應用程序的性能。

在實際的業務場景中，如下是正確實施 OpenTelemetry 來觀測 Kubernetes 環境的四個易於遵循的核心步驟，具體可參考：

1、安裝 OpenTelemetry Collector

首先，我們需要正確安裝 OpenTelemetry Collector。Collector 是用於接收、處理和導出遙測數據的組件。我們可以根據官方文檔提供的指南，在 Kubernetes Cluster 上安裝和配置 Collector。

在 Kubernetes Cluster 中，可以將 OpenTelemetry 代理配置爲一個 DaemonSet，以確保代理在 Cluster 中的每個節點上都能運行。通過以下命令可以安裝代理：

[leonli@LugaLab ~ ] % kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

當然，這裏，我們還可以使用 Helm Charts 進行安裝：https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator

2、配置 OpenTelemetry Collector

一旦安裝了 Collector，我們需要配置它以收集所需的指標和數據。配置文件可以指定要收集的指標類型、導出器（用於將數據發送到後端）以及其他特定的收集器設置。通過仔細配置 Collector，我們可以根據組織的需求來定製數據收集和導出。

OTel 支持多種後端，包括 Prometheus、Jaeger 和 Zipkin。具體配置可參考如下示例：

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  prometheus:
    endpoint: "localhost:4444"
  jaeger:
    endpoint: "http://jaeger:14268/api/traces"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [jaeger, prometheus]

3、在 Kubernetes 應用程序中啓用 OpenTelemetry 檢測

爲了在 Kubernetes 應用程序中啓用 OpenTelemetry 檢測，我們通常需要在應用程序代碼中添加 OpenTelemetry SDK。SDK 提供了用於在應用程序中插入代碼以收集指標、跟蹤請求和記錄日誌的 API。通過在應用程序中使用 OpenTelemetry SDK，我們可以捕獲關鍵的性能數據和上下文信息。

4、將數據發送到首選的後端

最後一步，我們需要配置 OpenTelemetry Collector 將收集到的數據發送到所首選的後端。後端可以是各種數據存儲和分析平臺，如 Prometheus、Grafana、Jaeger 等。根據我們的需求和環境，選擇合適的後端，並配置收集器以將數據導出到該後端。

這裏，以 Jaeger 後端爲例，它提供了各種可視化選項，使我們可以輕鬆理解 Kubernetes Cluster 中的請求流，並支持各種跟蹤格式，包括 OTel 等，具體可參考如下所示：

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: allInOne
  allInOne:
    image: jaegertracing/all-in-one:latest
    options:
      log-level: debug

在確保基於 Kubernetes 的應用程序的性能、可靠性和可用性方面，觀測 Kubernetes 是至關重要的。OpenTelemetry 爲觀測 Kubernetes 環境提供了一個強大的框架，利用分佈式跟蹤、指標和日誌記錄等功能。

通過遵循最佳實踐並利用適當的工具，如 OpenTelemetry 和其他工具，我們可以實時瞭解 Kubernetes Cluster 的狀態，從而提升應用程序的性能。

隨着 Kubernetes 的廣泛應用，強大的觀測策略比以往任何時候都更爲重要。通過實施 OpenTelemetry 和其他監控工具，您可以避免潛在問題，並確保 Kubernetes 環境的平穩運行。

這些監控工具可以幫助我們收集和分析關鍵的指標、跟蹤請求的路徑，並記錄關鍵事件和日誌。通過實時觀測 Kubernetes Cluster，我們可以及時發現潛在的問題，追蹤性能瓶頸，並採取適當的措施來優化和調整應用程序。

總而言之，通過實施 OpenTelemetry 及其他類似觀測工具，我們可以建立強大的觀測策略，從而確保基於 Kubernetes 的應用程序的性能和可靠性。這樣，我們將能夠及時發現和解決問題，提高應用程序的可用性，併爲用戶提供更好的體驗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0XYTeK3RD-EqpWY8sUlasg