從Prometheus, Grafana再到ELK stack, 把工具都摸過一輪之後,發現自己侷限於工具的使用,卻沒有好好了解可觀測性工程是什麼?它又該如何在工作現場當中實踐?本系列文將從我們熟知的三本柱metrics, traces, logs出發,深入探討它們各自的價值與局限。接著進入OpenTelemetry的世界,不只學習怎麼用,更要理解它背後想實踐的可觀測性精神。最後,我們會討論如何選擇適合的資料儲存後端,以及如何從零開始規劃一個真正符合團隊現況的可觀測性系統架構。
對於微服務架構來說,一個看似簡單的用戶請求,實際上可能要橫跨十幾個不同的服務才能完成。當系統出現問題時,我們很難就著單一個服務的錯誤來排查問題。這正是 Open...
在昨天的 Traces 介紹中,我們了解到 SpanContext 提供了追蹤關聯性,讓分散式系統中的操作能夠正確地關聯到同一個 trace。然而,在實際的業務...
很快地第二週的學習即將告一段落!到今天為止,我們學習到 OpenTelemetry 解決了哪些可觀測性的痛點,了解了它的元件是如何各司其職,專門來生成、收集、匯...
目前已經有許多發展成熟的 Data Lakehouse 解決方案,例如 Apache Hudi、Apache Iceberg、Delta Lake 等。它們都是...
在前兩篇文章中,我們探討了 Data Lakehouse 的概念演進,以及 Apache Iceberg 如何透過三層架構實現高效的 metadata 管理。但...
昨天,我們成功將 OTLP 資料轉換成 Parquet 格式。今天,讓我們接續昨天的實驗,來拆解 Parquet 內部的結構吧。 實驗工具 由於 Parquet...
目前為止,我們已經深入了解 Parquet 的欄式儲存設計,看到它如何透過分層架構和壓縮技術來高效儲存資料。但是,資料儲存只是第一步,真正的價值在於如何快速查詢...
前言 前面幾天,我們深入探討了 Data Lakehouse 的核心技術:從 Apache Iceberg 的 table format、Parquet 的欄式...
昨天我們探討了在建立可觀測性資料管道時的考量,以及為什麼最後選擇 AWS Kinesis Data Firehose + Lambda 作為我們的即時轉換方案。...
上一篇文章中,提到 Firehose 的 recordID 會和目標寫入的資料是一比一的關係,所以必須在 Firehose 前面架設一個 Lambda 來去分割...