OpenTelemetry 指標現已發布 RC 版本

發布日期:2022/07/04

Splunk 全力支援 OpenTelemetry,例如我們在 Observability Cloud、Splunk Enterprise 和 Enterprise Cloud 中對 OpenTelemetry Collector 的原生支援,以及用於 OpenTelemetry Kubernetes 的 Splunk Connect 就是最好範例。我們的長期目標是將 OpenTelemetry 作為所有 Splunk 產品從客戶基礎架構和應用程式中獲取資料來進行分析的主要方式,以及盡力為該專案做出巨大貢獻。

今天,OpenTelemetry 實現了一個重要的里程碑,發布了第一波指標 (metrics) 的正式版候選版本,包括 API、SDK 和語言代理程式。這實現了該專案對統一分散式追蹤和指標收集的最初承諾,並可讓社群將重心集中在日誌支援、與更多資料來源整合以及其他訊號類型上。您可以從 OpenTelemetry 官方部落格文章中了解更多資訊,我也將資訊貼在下面。

OpenTelemetry 的指標功能現已提供候選版本 (RC),從 Java、.Net 和 Python 開始!這意味著編寫、擷取、處理和與指標互動的規範、API、SDK 和其他元件,現在具有完整的 OpenTelemetry 指標功能集並且可以使用。這些候選版本將在接下來的幾週內升級為正式版本。


1.0 版指標包括以下內容:

  • OpenTelemetry 特定語言 API 中包含的指標功能將提供特定語言的介面,可以建立和操作指標,並將中繼資料和屬性與每個指標關聯起來。
    這些功能適用於以下對象:
    ──發布共用程式庫給使用者的開發人員,以便使用者可以使用 OpenTelemetry 原生地從這些共用程式庫中擷取指標。例如,gRPC 可使用這些 API 為特定服務上的每個 RPC 方法產生延遲、輸送量和錯誤率的指標。
    ──建立和維護 Web 服務或用戶端應用程式的開發人員,以便他們可以產生自定義指標或與現有指標互動。例如,電子商務公司可以使用 API 來追蹤一段時間內的購買次數。

 

  • 適用於 Java、.Net、Python 和 JS (下週推出) SDK 的 OpenTelemetry SDK 中包含的指標功能,可從 API 擷取指標並執行一些處理。對其他語言的指標支援仍在開發中。
    這些功能適用於以下對象:
    ──其他部門使用的應用程式 (如資料庫、訊息佇列等) 的開發人員,他們將可透過 OTLP (或 Prometheus) 找出指標,以便自己的使用者能夠監控這些應用程式的效能。開放原始碼或封閉原始碼的應用程式均可適用。
    ──技術部門內的應用程式開發人員,他們希望在自己的應用程式中擷取由 OpenTelemetry API 產生的指標,無論是資訊是來自他們的開發人員還是應用程式使用的共用程式庫。這些指標可以透過 OTLP 或任何其他 OpenTelemetry 匯出工具匯出。

 

  • 對指標的收集器支援包括從各種資料來源 (如主機指標或預先封裝的應用程式) 擷取指標的能力。收集器還可從使用多種資料通訊協定的來源接收指標,如原生 OpenTelemetry 通訊協定 (OTLP) 和符合 OpenMetrics 規範的通訊協定 (例如 Prometheus) 等。還支援以組態驅動的指標處理和原生 OTLP、Prometheus 和自訂匯出工具,以將可觀察性指標發送到您指定的雲端和本地監控系統。
    這些功能適用於以下對象:
    ──任何想要從其主機 (Linux VM、Windows、VM、Kubernetes 等) 或預先封裝的應用程式 (資料庫、訊息佇列等) 擷取指標的人。
    ──任何想要從 OTLP (來自 OpenTelemetry SDK、預先封裝的應用程式等)、Prometheus 等現有來源擷取指標的人。
    ──任何想要處理/修改從這些來源擷取的指標和指標中繼資料的人。
    ──任何想要將指標從一種格式轉換為另一種格式的人。例如,收集器可以從混合的 OTLP 和 Prometheus 來源中擷取,然後使用 OTLP (使用標準 OpenTelemetry 語意慣例)、Prometheus 或任何其他匯出工具將所有這些指標發送到單一目的地。

 

  • 完整的 OpenTelemetry 通訊協定 (OTLP) 支援,用於在系統之間有效地序列化和傳輸指標。

 

  • 規範中的指標部分定義了不同類型的指標、它們的類型、如何處理它們以及語意慣例。主要的使用族群是 OpenTelemetry 開發者,但也為編寫指標或中繼資料的 OpenTelemetry 使用者提供指導。

 

所有這些功能都是對 OpenTelemetry 現有追蹤支援的補充,兩種訊號類型並可以共用相同的中繼資料和語意慣例。本次發布已包含以下語言的候選版本:

  • Java
  • .Net
  • Python

JS 的 RC 版本預計在下週發布,其他更多語言將在未來幾個月發布 RC 指標。在我們收到使用者的意見反映後,這些版本都將發布正式版本。

入門
如果您已經混合使用 OpenTelemetry API、SDK、語言代理程式和收集器,則可以將您的 OpenTelemetry 工件更新到最新版本,即可取得 RC 指標功能。我們目前正在更新每個工件的指標功能的OpenTelemetry 官方文件。範例和補充文件也被新增到每個工件的相應 GitHub 存放庫中。


OpenTelemetry 的下一步
當我們在 2019 年的 Kubecon EU 上宣布 OpenTelemetry 的核心承諾時,兩大主軸是分散式追蹤和日誌。當指標發布正式版本後,我們已經開發出最初想要建立的功能,接著會將重心轉移到進一步強化每個元件的穩定性和易用性、OpenTelemetry 可以擷取遙測資訊的資料來源數量 (透過 OpenTelemetry API、OTLP 或其他方式),以及其他新功能和訊號類型。


日誌功能 (logging) 是即將發布的最主要版本,我們正在全速推動這項工作。期待聽到更多今年日誌功能的進展 (日誌已經有穩定的資料模型和 OTLP 支援),以及對此領域感興趣的任何人,都歡迎加入每週 SIG 日誌功能電話會議。除了日誌之外,主要的新專案還包括正規化和實作用戶端檢測工具以及對 eBPF 的調查。隨著指標的完成,我們也可以將注意力轉向到其他的訊號類型。

 

作者
Morgan McLean
Morgan McLean 是 Splunk 的產品管理總監,專注於 Splunk Observability Cloud,以及 Splunk 對 OpenTelemetry 的貢獻以及 Splunk Observability Cloud 和 Splunk Enterprise 之間的代理和擷取統一。此外,他還是 OpenCensus 和 OpenTelemetry 的聯合創始人,其現在是僅次於 Kubernetes 的第二大 CNCF 專案。在加入 Splunk 之前,Morgan 在 Google Cloud Platform 擔任了五年的產品經理,致力於開發營運和可觀察性專案,並在 Microsoft 擔任了三年多的專案經理,負責設計和實作電子商務服務。Morgan 擁有英屬哥倫比亞大學的工程物理學學士學位和經濟學學士學位。

返回上一頁