Odigos(https://github.com/keyval-dev/odigos) 是一個開源的可觀測性控制平面，允許企業創建和維護他們的可觀測性管道，Odigos 允許應用程序在幾分鐘內提供追蹤、指標和日志，重要的是無需修改任何代碼，完全無任何侵入性。

當你的應用程序在世界各地的數十個節點上的數百個 pod 上運行時，很難全面了解整個應用程序，對于需要跟蹤、管理和優化這些環境的性能和可用性的團隊來說，可觀測性就成為了關鍵的工作任務。

如果整合得當，可觀測性工具可以通過集中你的數據并提供對性能、使用情況和用戶行為等關鍵指標提供更智能的洞察力來監控和排查問題，可觀測性工具應支持你使用的語言和框架，與你的容器平臺和你使用的其他工具輕松集成，包括任何通信或報警。問題是實施、維護和擴展是持續的任務，如果沒有適當的執行和持續的配置，可觀測性工具是有限的，很多時候還是無效的。

對于研發團隊來說，在云上應用可觀測性能力需要特定的技能組合，特別是考慮到向 OpenTelemetry & eBPF 的轉變。企業必須確保他們能夠在有限的、競爭激烈的人才庫中獲得特定的技能組合。學習 SDK、添加自動儀表（針對每種語言）、編寫代碼、部署和維護采集器--這些都需要大量的時間和知識，而大多數組織并不具備這些條件。

為了解決這些集成問題，一些大型的可觀測性工具供應商提供自己的代理，提供他們自己的定制解決方案。這樣做的問題是，通過使用專有格式攝取和存儲數據的專有代理，但是會和這些供應商綁定在一起了。隨著企業越來越多地尋求與開源標準的兼容性，以及跨部門共享和訪問數據的能力，將數據鎖定在一個獨立的供應商中會阻礙這些努力并增加成本。

Odigos 可觀測性控制平面提供了一個全面的、完全自動化的解決方案，使各組織能夠在幾分鐘內建立他們的可觀測性管道。Odigos 專注與第三方集成、開源、開放標準，以及整體上更加綜合的方法，減少了結合多個可觀測性軟件平臺和開源軟件解決方案的復雜性。

Odigos 自動檢測你集群中每個應用程序的編程語言，并相應地進行自動檢測。對于已編譯的語言（如 Go），使用 eBPF 來檢測應用程序，對于虛擬機語言（如 Java）則使用 OpenTelemetry。此外，Odigos 創建的管道遵循最佳實踐，例如：將 API 密鑰持久化為 Kubernetes 的 Secret，使用最小的采集器鏡像，等等。安裝、配置和維護一個開源的、不可知的 Observabiity 控制平面的能力將使各種規模的組織有能力在任何時候采用適合他們的工具，并根據需要添加更多工具。

Odigos 使可觀測性變得簡單，人人都能使用。

使用

準備

接下來我們將安裝一個 bank-of-athnos(https://github.com/keyval-dev/bank-of-athnos) 應用，這是一個由 Google 創建的銀行應用程序示例，我們使用沒有任何檢測代碼的修改版本來演示 Odigos 如何自動從應用程序收集可觀察性數據。

當然前提是需要一個 Kubernetes 集群，如果是在本地開發環境強烈推薦使用 kind 來創建一個測試集群，只需要使用名 ??kind create cluster?? 即可創建一個集群。有了集群后使用下面的命令部署測試應用即可：

kubectl apply -f https://raw.githubusercontent.com/keyval-dev/bank-of-athnos/main/release/kubernetes-manifests.yaml

在進入下一步之前，確保所有的 pod 都處于運行狀態（可能需要一些時間）。

安裝 Odigos

接下來我們需要先安裝 Odigos，最簡單的方式是使用 Helm Chart 進行安裝：

helm repo add odigos https://keyval-dev.github.io/odigos-charts/
helm install my-odigos odigos/odigos --namespace odigos-system --create-namespace

在 odigos-system 命名空間中的所有 pod 運行后，通過運行以下命令可以打開 Odigos UI：

kubectl port-forward svc/odigos-ui 3000:3000 -n odigos-system

然后我們就可以在瀏覽器中通過 http://localhost:3000 訪問 Odigos UI 了，正常可以看到如下所示的頁面：

有兩種方法可以選擇 Odigos 應該使用哪些應用程序進行觀測：

• Opt out（推薦）：檢測所有程序，包括每一個將要部署的新應用，用戶仍然可以手動標記不被檢測的應用程序。
• Opt in：只對用戶手動選擇的應用程序進行檢測。

這里我們就選擇使用 Opt out 模式。

配置

接下來是告訴 Odigos 如何訪問我們自己的可觀測后端，Odigos 支持很多的后端服務：

比如我們這里選擇自己托管的 Prometheus、Tempo、Loki 三個服務，當然也需要提前部署該 3 個服務：

添加以下三個目的地：

Tempo：

• Name: tempo
• URL: http://observability-tempo.observability

Prometheus：要添加其他目的地，請從側欄中選擇目的地，然后單擊添加新目的地

• Name: prometheus
• URL: http://observability-prometheus-server.observability

Loki

• Name: loki
• URL: http://observability-loki.observability

選擇后等待幾秒鐘，讓 Odigos 完成部署所需的采集器并對目標應用程序進行檢測。你可以通過運行以下程序來監控進度

kubectl get pods -w

等待所有的 pods 都處于運行狀態（特別是注意 transactionservice 應用程序，它的啟動時間很慢）。最后我們就可以在 Grafana 中探索我們的可觀測數據，我們現在可以看到并將指標與追蹤和日志數據關聯了起來。

同樣可以通過運行端口轉發到你的 Grafana 實例。

kubectl port-forward svc/observability-grafana -n observability 3100:80

并導航到 http://localhost:3100，輸入 admin 作為用戶名，對于密碼，輸入以下命令的輸出：

kubectl get secret -n observability observability-grafana -o jsnotallow=”{.data.admin-password}” | base64 --decode

Service Graph

現在我們就可以查看微服務的 Service Graph 了。

1. 點擊側邊欄的 Explorer
2. 選擇 Tempo 作為數據源
3. 選擇 Service Graph 標簽
4. 點擊 Run query 按鈕開始查詢

指標

接著我們可以查看一些指標，從 service graph 中點擊 contacts 節點并選擇 Request rate：

就會出現如下所示的一個非常熟悉的圖表：

還有很多 Odigos 收集的指標可以從 Prometheus 數據源輕松查詢，請查看此文檔(??https://odigos.io/docs/telemetry-types/??)以了解完整的清單 。

追蹤

再次點擊 Service Graph 中的 contacts 應用，但這次選擇請求直方圖，為了將指標和追蹤聯系起來，我們將使用一個叫做 exemplars 的功能，要顯示 exemplars，按照如下步驟：

1. 打開 options 菜單。
2. 打開 exemplars。
3. 注意現在直方圖上增加了綠色的菱形。

將鼠標懸停在其中一個添加的點上，點擊 Query With Tempo，應該會出現類似于下面的追蹤數據。

在此 trace 中，可以準確地看到整個請求的每個部分花費了多少時間，深入其中一個部分將顯示其他信息，例如數據庫查詢。

日志

要進一步調查具體操作，可以簡單地按下小文件圖標查詢相關日志。按平衡器旁邊的文件圖標，顯示相關日志。

總結

我們已經展示了僅使用開源解決方案提取和傳輸日志、追蹤和指標是多么容易。此外，我們還能夠在幾分鐘內從一個應用程序中生成追蹤、指標和日志數據，現在也有能力在不同的信號之間進行關聯。可以將指標與追蹤和追蹤與日志相關聯，現在擁有所有需要的數據來快速檢測和修復目標應用中的生產問題。