OTEL是DEVOPS成功秘訣

代碼部署後，開發和運維的真正工作才開始，這提升了可觀測性對應用程式性能的重要性。

譯自 OTel Is the Secret to DevOps Success，作者 Clay Roach。

過去“開發人員編寫代碼，運維人員運作代碼”的界限已經不存在了。如果你編寫、設計或貢獻應用程式，你對應用程式在生産中的執行負有一定的責任。在某些時候，你會被要求診斷和修複它。

在建立應用程式時，開發人員需要從一開始就樹立這樣的心态：真正的工作從代碼部署後開始。那時，開發人員會看到他們的應用程式在現實世界中的表現，并確定它們提供積極的客戶體驗。

通過使用 應用程式性能管理 (APM) 工具在前期捕獲有關代碼和業務流程的詳細資訊，運維人員可以繼承開發人員所做的一切出色、周到的工作。運維人員在事件響應期間可以更快地查明關鍵問題，進而節省時間和精力。通過通路有助于修複特定于每個應用程式的錯誤和延遲問題的資訊，開發人員和運維人員的生活都變得更加輕松。

從本質上講，APM 是關于 實作 DevOps 的，而那些在他們開發的應用程式中 建構更好的可觀測性 的開發人員将自己置于這種實作的最前沿。

開發和運維：不同的視角

盡管開發人員和運維人員有共同點，但兩者仍然從不同的角度進行操作。開發人員将職業生涯投入到建立對業務至關重要的應用程式中。對于每個編寫的應用程式，開發人員都希望成為建立者、故障排除者和修複者。

開發人員還希望看到新功能投入生産後使用情況和輸入之間的差異。應用程式是否按預期工作？它是否為客戶提供價值？應用程式支援的業務流程是否得到改善？

與此同時，運維人員對應用程式和基礎設施性能采取整體的視角。一切是否正常運作？基礎設施變更是否影響應用程式性能？這個問題是否影響其他服務？我們是否滿足客戶期望或合同服務級别協定 (SLA)？如果是代碼問題，誰需要通路此資訊來修複它？

了解這一點，我們如何才能獲得開發回報循環和最佳業務名額，以實作真正的 DevOps？

OTel 的優缺點

要建立不會占用資源的高性能應用程式，關鍵是要通過 OpenTelemetry (OTel) 等周到的檢測來了解生産中的應用程式代碼。通過在建立代碼時捕獲有關應用程式流程和依賴項的詳細資訊，開發人員可以在以後需要修複問題或提高性能時節省大量時間。

OTel 支援對同一個應用程式同時使用自動和手動檢測。這種檢測使開發人員能夠添加代碼片段來捕獲和發送特定于其應用程式的自定義名額。

自動檢測提供預建構的庫或代理，這些庫或代理捕獲标準名額，例如 CPU 使用率、記憶體使用率、請求延遲和錯誤率。自動檢測不需要開發人員修改代碼，實施起來更簡單、更快，但靈活性較差。

手動和自定義檢測使 DevOps 團隊能夠輕松通路有關發生了什麼以及原因的詳細資訊，并以有用的格式呈現。此外，使用 OTel 可以幫助您設計和改進本地和測試環境中的監控，以便您知道在生産中會發生什麼。您在不同的環境中不會擁有不同的資料集，因為工具在所有環境中都是相同的。

但是，OpenTelemetry 本身并不知道什麼對業務很重要。該技術捕獲 SQL 查詢、HTTP/TCP 調用、消息傳遞調用以及硬體和網絡資訊。OTel 不會捕獲使用者 ID、非通用中繼資料或任何特定于您的應用程式和業務的任何内容。

這就是自定義檢測發揮作用的地方。自定義檢測需要工作和時間來實施，但它使開發人員能夠靈活地控制捕獲在生産中進行故障排除所需的資訊。

現實世界中的例子

為了了解這在實踐中是如何運作的，讓我們來看一個線上購物車結賬。一個交易可能會命中一個端點，四個端點，甚至 10 個或更多端點。這些端點可能會命中其他端點。應用程式可能有一個 Kafka 後端，一個消息總線後端，資料庫或 NoSQL 資料庫存儲，或任何數量的自定義 API 或資源。當客戶下訂單時，系統會運作所有這些與訂單處理、計費、營銷和履行相關的特定于業務的應用程式和服務。

那麼，當許多使用者通過購物車結賬時，您如何才能确定，當客戶點選購買按鈕時，它會正确地觸發訂單處理、采購、運輸、計費以及其他任何需要的操作的完成？最重要的是，您如何知道每個人都被正确地計費？

通過自定義儀器，OTel 使您能夠将所有這些不同的應用程式連結在一起，并獲得對所有這些不同服務中整個業務交易的整體視圖。

OTel 充當 DevOps 之間的橋梁，将開發團隊關注的代碼内部與您的運維團隊監控的網絡流量資料和來源連接配接起來。這種精确的可觀測性使 DevOps 能夠快速排查和解決問題，并確定應用程式和業務流程得到優化和準确。

自定義儀器還使應用程式能夠捕獲對您的 DevOps 團隊確定出色使用者體驗至關重要的特定于業務的遙測資料。

使用 OTel 還是不使用 OTel

擁有大型 APM 部署的公司可能已經在員工中擁有高技能的開發人員，他們可以利用 OTel 和自定義儀器來提高 DevOps 效率。

如果您的開發人員沒有能力進行自定義儀器，那麼讓他們學習可能值得。您可以在應用程式中逐漸嵌入自定義 OTel 儀器，這将把時間和成本分散到整個開發周期中。

現有的 APM 使用者需要考慮更多因素，首先是其 APM 部署的廣度。當您監控數千個應用程式時，添加 OTel 功能無疑會更加複雜，并且費用可能會被視為過高。這些公司可以在其應用程式的子集中測試 OTel 增強型 APM 的優勢，或者在開發或通用可用性環境中使用低成本的開源監控替代方案。

OpenTelemetry for DevOps：下一步

OTel 的目标是标準化遙測資料的收集和導出，以便組織能夠靈活地選擇其後端 APM 或可觀測性解決方案。随着對分析的支援的增加，分析在運作時動态檢查應用程式代碼的行為和性能，OpenTelemetry 項目正在擴充功能以比對商業産品。

持續分析提供了對代碼級别資源使用率的洞察，并允許随着時間的推移以及跨不同屬性存儲、查詢和分析分析資料。這些資料使開發人員和營運人員能夠将跨服務的資源耗盡或糟糕的使用者體驗與受影響的特定服務或 Pod 以及導緻它的函數或代碼行相關聯。

無論您的企業是大型還是小型，是 APM 新手還是廣泛的 APM 使用者，OTel 都可以幫助您以最少的額外代碼或工作量來實作可觀測性的承諾。