iT邦幫忙

2023 iThome 鐵人賽

DAY 14
0
DevOps

Observability 101系列 第 14

Day14 - 可觀測性管道:解析現代數據收集與分析

  • 分享至 

  • xImage
  •  

今天要與大家探討「可觀測性管道 Observability Pipeline 」主題

可觀測性管道

在上一篇提到可觀測性信號(Observability Sialgns),為了處理這龐大的遙測數據資訊與分析,我們需要有效的方式來整合這些遙測數據,可觀測性管道的概念也因應而生,資料從它的來源地匯出到使用者需要查詢的地方,這包含以下四個不同的階段
https://ithelp.ithome.com.tw/upload/images/20230929/201625772bgI9TqUHT.png

  • 收集(collection) : 接收可觀測資料,通常在主機上運行的代理程式進行。
  • 攝取(ingestion): 遙測資料在目的地處理,可能會經過批次、壓縮和其他轉換,以使資料處於最佳儲存形式。
  • 儲存(storage) : 保存可觀測資料,可能會涉及索引以加快查詢速度。
  • 查詢(query) : 尋找可觀測資料,可能會涉及將查詢條件轉換為對底層儲存系統的 Get/List 請求。

獨立組件

當有多種可觀測性信號時,意味需要不同的收集、儲存跟查詢層獨立的系統處理方式。例如在 Open Source 的世界中,大家所重視的三個可觀測性信 Metrics、Traces、Logs 可以分別採用 Prometheus、ElasticSearch 和 Jaeger 作為解決方案。這裡列出每項服務的管道

https://ithelp.ithome.com.tw/upload/images/20230929/20162577hmxGGSYDse.png

Prometheus for Metrics

collect (prometheus scraper) -> ingest(prometheus) -> store (prometheus) -> query (prometheus)

Elasticsearch for logs

collect (logstash) -> ingest (elasticsearch) -> store (elasticsearch) -> query (elasticsearch)

Jaeger for traces

collect (jaeger collector) -> ingest (jaeger) -> store (cassandra) -> query (jaeger)

統一採集 Unified Collection

https://ithelp.ithome.com.tw/upload/images/20230929/20162577Q77cVXKyfR.png

  • 在過去統一採集的標準有 OpenTracing 與 OpenCensus,各自有不同擁護者與供應商支持其格式。
  • 2019 年 OpenTelemetry (aka OTel) 發布,為收集遙測數據的統一標準,並合併 OpenTracing 與 OpenCensus 重要專案。
  • 2023 年 OpenTelemetry 已逐漸成熟,提供供應商中立的規範與實踐,可以從應用程式(支援的程式語言)來源收集指標、日誌和追蹤並將其送到目的地。

統一儲存 Unified Storage

https://ithelp.ithome.com.tw/upload/images/20230929/20162577yiCIq1WEKb.png
當可觀測性資料越來越多,隨之而來的挑戰是儲存資料空間與查詢效能的議題浮上檯面。在 Open Source 中可以透過以下解決方案

  • Metrics : Prometheus with Cortex/Mimir
  • Logs : Loki
  • Trace : Tempo

核心階段 : Collect 採集

前面提到的四個階段中,資料來源地收集是相對重要的。它決定了我們可以收集多少資料,以及我們可以如何使用這些資料,這裡針對 Collect 階段做進一步的探討。在應用程式蒐集可觀測性資料時可能有下面流程
https://ithelp.ithome.com.tw/upload/images/20230929/20162577mVw5qfhiQV.png

  • receivers: 從不同的來源推拉數據資料
  • processors: 將資料轉換/過濾/加工的動作
  • exporters: 將資料傳送到目的地

以上組合共同創建出收集的可觀測性管道。透過簡單範例讓大家更清楚
https://ithelp.ithome.com.tw/upload/images/20230929/20162577cAvLF4LiP2.png

  • 收集 Log 資料將傳送到 AWS S3 的管道,並將錯誤的 Log 設定傳送到 datadog。
  • 管道中將主機與容器資訊做為 Log 的自定義屬性添加到每筆資料中。
  • 從可觀測性資料中刪除未使用的屬性。

接下來,我們來探討可觀測性管道的三個重要組件

Agent

https://ithelp.ithome.com.tw/upload/images/20230929/20162577V5UbtDDcCU.png

  • 代理主要運作於他們收集資料的或是應用程式上。
  • 主要職責:拉取數據、進行輕量級的資料聚合,並將數據發送到預定的目的地。
  • 每個可觀察性供應商都有其客製化的代理。

Collectors

https://ithelp.ithome.com.tw/upload/images/20230929/20162577DtoB2CJ29j.png

  • 收集器可以部署於它監控的相同系統上或作為獨立的部署。
  • 主要職責:整合來自不同來源的可觀測性數據、應用基本過濾器,並將數據路由到一個或多個目的地。
  • 常見的收集器:FluentD 和 Fluent Bit,兩者在社群中擁有多種整合解決方案。

Pipelines

https://ithelp.ithome.com.tw/upload/images/20230929/20162577zRb29YZIAb.png

  • 可觀測性管道是收集器的進階版。
  • 可以在同一系統、作為獨立部署或雲端上運作。
  • 主要職責:能夠從任何來源接收數據,對蒐集到的的數據進行多種轉換,並將其匯出到任何指定的目的地。

以上是今天的分享。下一篇休刊,如果有任何疑問或想法,歡迎留言提出討論 !

小結

  • 可觀測性管道四個階段 : 收集(collection)、攝取(ingestion)、儲存(storage)和查詢(query)
  • 三個重要組件 : Agent、Collectors、Pipelines

參考連結

The Architecture of Modern Observability Platforms

First Mile Observability and the Rise of Observability Pipelines


上一篇
Day13 - 可觀測性信號(Signals)的進化之旅
下一篇
Day15 - 開賽至今的回顧與反思
系列文
Observability 10131
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言