View a markdown version of this page

階段 2：實作可觀測性 - AWS 方案指引
選擇您的可觀測性平台檢測您的應用程式收集遙測實作可觀測性元件驗證可觀測性系統

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

階段 2：實作可觀測性

在此階段，您會開始讓團隊逐步前往北極星的程序。

選擇您的可觀測性平台

第一步是識別正確的工具來擷取、視覺化和分析訊號，以及傳送提醒。選取工具時，請考慮其功能集、授權模型、價格、技能需求和維護。

功能集

以下是一些要考慮的問題：

  • 可設定性和自訂。該工具提供哪些功能來簡化調查體驗，並協助減少 MTTR？ 此工具是否提供警示關聯性、指標數學、處理遺失遙測的彈性，或異常偵測？

  • 精細程度。支援的遙測訊號擷取和視覺化精細程度為何？

  • 角色。此工具是否支援您想要提供給開發人員、平台工程師和其他角色的體驗？ 它是否適用於技術和業務角色？

  • 小工具。儀表板支援哪些類型的小工具？ 工具是否允許建立自訂小工具？

  • 預先建置的解決方案。該工具提供哪些預先建置的可觀測性解決方案，以縮短實現價值的時間？

  • 自動化和生成式 AI。該工具提供哪些功能，可協助您和您的團隊自動化或減少混沌？ 例如，自動異常偵測、預測分析和其他生成式 AI 功能有助於減輕假設和未知因素的壓力 （也就是您不知道或完全了解的事物）。此工具是否支援使用生成式 AI/ML 模型來增強大規模資料分析？ 它是否為您提供自動化和實作 AIOps 的選項？

  • 安全性。 工具支援哪些類型的身分驗證和授權整合？ 使用者和登入體驗是否符合組織的需求？

  • OpenTelemetry 支援。工具和代理程式是否支援 OpenTelemetry？ 大多數可觀測性平台支援擷取 OpenTelemetry 相容訊號，但並非所有代理器都提供組態選項，將這些訊號轉送至可觀測性平台。

  • 整合。工具提供哪些整合？ 考慮是否需要傳送提醒給 Slack、頁面團隊成員或自動化解決方案。

  • 延展性。​ 工具的可擴展性和效能如何？ 可觀測性解決方案必須隨著您的需求和用量增加而擴展，因此即使您的應用程式無法使用，它也可以提供診斷。

  • 支援。提供哪些支援模型？ 即使應用程式失敗，您的可觀測性工具也必須可用，如此您才能符合 MTTR 和應用程式可用性目標或服務層級協議 (SLAs)。開放原始碼解決方案可能提供有限的正式支援。

授權和部署模型

考慮解決方案的授權模式 （開放原始碼或商業） 和部署模式 （自我託管或雲端型）。開放原始碼選項通常具有較低的預付成本，但在提供價值之前，可能需要更多時間進行部署、設定和組態、維護和團隊升級。如果您正在考慮開放原始碼選項，您可能需要一個專門的可觀測性專家團隊。商業軟體通常會以更高的前期成本提供更快的價值時間，而且專用可觀測性團隊的需求會隨著採用率、複雜性和成熟度的增加而隨時間演進。與雲端型解決方案相比，自我託管解決方案需要更多時間進行部署、設定和組態、維護和操作開銷。

定價維度

隨著您的應用程式獲得新的使用者、更大的架構足跡或新的功能和應用程式，工具的定價模型將如何影響您的總體擁有成本 (TCO)？ 例如，某些典型的授權模式是永久的或基於訂閱、具名使用者數量、耗用量或磁碟區。考慮您的應用程式和可觀測性工具如何擴展用量，以及授權模型如何影響工具的成本。

團隊技能

根據團隊目前的技能集和成熟度，您需要判斷需要多少提升技能。考慮廠商提供哪些支援來訓練您的團隊。同時考慮您的組織結構是否支援您選擇的工具的組態和管理。例如，如果您選擇 OpenTelemetry，您應該考慮設定專門提供可觀測性的單獨團隊。

操作和維護

評估下列問題：

  • 可觀測性代理程式或收集器提供哪些部署選項？ 這些選項是否符合架構的要求？ 例如，如果您使用可觀測性工具的容器化部署，它是否支援協助程式集或附屬項目？ 營運團隊需要採取或使用哪些額外的步驟或工具，以確保符合安全性和所有其他程序？

  • 維護解決方案所需的工作量為何？ 更新代理程式或收集器的程序有多簡單或自動化？ 與自我部署和託管應用程式相比，完全受管和雲端型可觀測性界面通常具有較低的操作開銷，但代理程式或收集器的管理保持不變。將您的團隊結構納入考量，並考量維護您選擇的選項的人力成本。

檢測您的應用程式

上一節問題的答案為您提供檢測應用程式所需的資訊，也就是新增程式碼以擷取應用程式的遙測訊號，以及測量、觀察和驗證行為。您可以使用SDKs應用程式語言的 OpenTelemetry SDK 等 SDK 來自動檢測應用程式。您可能仍然需要新增手動檢測程式碼，以涵蓋任何差距，並確保end-to-end可見性。請特別注意您新增的遙測，並確保您可以將它連接到您在上一個階段建立的一或多個 SLIs 和 SLOs。

收集遙測

設定遙測收集器或代理程式來擷取相關的遙測訊號，以符合您在階段 1 中排定優先順序的結果。

實作可觀測性元件

當遙測正在流動並擷取到可觀測性平台時，請建立儀表板、警示、手冊和 Runbook。

  • 儀表板：建立包含相關資訊的儀表板，包括與優先結果相關聯的目前和歷史趨勢視覺化呈現。將這些儀表板提供給您在階段 1 中定義的利益相關者。如需詳細資訊，請參閱 Amazon Builders' Library網站上的建置儀表板以取得操作可見性。

  • 提醒：定義提醒，在結果處於風險或違規時通知您的團隊。請考慮新增安全性和效能問題的提醒。採用下列方式來最佳化警示，以減少警示疲勞和成本：

    • 使用異常偵測來避免設定硬閾值，這需要頻繁調整，並減少未知的發生。

    • 使用智慧提醒組合，一起查看多個相關指標，而不是為每個指標設定個別提醒。例如，不針對 CPU、記憶體和回應時間設定個別提醒，而是建立一個有意義的提醒，只在這些指標共同指出實際問題時觸發。這種方法可大幅減少警示雜訊，並協助您的團隊專注於實際的服務影響問題，而不必回應隔離的指標峰值。

    • 只有在使用者體驗或結果處於風險時，才會產生提醒。例如，當您的應用程式沒有作用中的使用者時，請避免收到由自動升級引起的 CPU 峰值提醒。

  • 手冊：手冊為回應事件或警示的人員提供心理模型和內容，並協助他們更快識別根本原因。考慮為高度耦合、複雜的應用程式和缺少檢測但直接影響您在階段 1 中識別和優先結果的應用程式建立手冊。

  • Runbook：使用 Runbook 定義解決事件或警示所需的步驟。

驗證可觀測性系統

在整個軟體開發生命週期 (SDLC) 中，驗證儀表板是否在系統測試期間提供預期的行為和更新。實作混沌工程並驗證手冊和 Runbook 中記錄的步驟，以確保它們準確並滿足其目的。您也應該驗證警示擁有權和呈報路徑。