探索系統的可觀測性：從事件風暴到OpenTelemetry
====
### TODO 業務指標
>首先，Event Storming作為一種模型化與視覺化的大腦風暴方法，它的目的是將事件的理解融入業務模型中。這意味著我們在理解和討論業務需求時，會主動尋找和定義出一系列的"事件"。這些"事件"是系統中的關鍵活動，並且會留下"記錄"或"日誌"。
>
> 接著，在現代的系統架構下（容器化、Severless），當我們轉向12-Factor App的Log觀念，我們將更深入地理解事件在系統中的角色。在此架構中，事件（或logs）不僅是靜態的記錄，而且是一種動態的資料流，它反映了系統在特定時間點的狀態。
>
> 再來，這樣的觀念將我們引向了可觀測性工程。在這裡，日誌（或事件）只是我們試圖理解並改進系統行為的一種手段。除了logs之外，metrics和traces也是我們用來獲取系統全面瞭解的重要數據來源。可觀測性工程的實踐就是要將這些數據集中並有效利用，以便我們能在運行中的系統中找出問題並改善其性能。
>
> 最後，OpenTelemetry就是一個實現可觀測性工程的工具，它將logs、metrics和traces結合在一起，讓我們可以有一個統一而全面的視角來觀察和理解我們的系統。這種全面性使我們能更好地理解事件（即日誌中記錄的）如何影響我們的系統，並為我們提供了改進性能的策略。
>
> 透過上述的探討，我們可以看到Event Storming、12-Factor App的Log觀念、可觀測性工程和OpenTelemetry之間存在一種演進和深化的關係，並且這些主題都圍繞著一個核心問題：如何更好地理解和改進我們的系統。

# <span style="color: blue;">事件</span><span style="color: red;">風暴</span>（EventStorming）：
在這個部分中，你可以深入討論事件風暴的細節，並提供一些例子來說明其效果。

定義事件風暴： "事件風暴是一種集體的建模練習，它鼓勵團隊成員共享他們對業務流程的理解。在此過程中，每個"事件"都被記錄下來，成為我們理解業務需求的基礎。"

事件風暴的重要性： "透過事件風暴，我們可以將抽象的業務需求轉化為具體的、可操作的事件。這些事件不僅描述了業務流程，也成為了我們理解和改進系統的工具。"

實例： "例如，假設我們正在開發一個電商平台。在事件風暴的過程中，我們可能會確定如下的事件：客戶下單、庫存檢查、付款處理、出貨等。每一個事件都可能會影響到其他的事件，並留下日誌來追蹤這些交互。這就是我們如何從事件風暴轉向日誌的過程。"

# 從事件風暴到日誌
解釋事件如何轉變為日誌，並為我們提供有關系統行為的重要信息。

在事件風暴過程中，團隊將一系列的業務活動或過程（事件）定義並視覺化。這些事件可能包括：客戶下單、庫存檢查、付款處理、出貨等。每一個這樣的事件都可能會產生相關的日誌條目。

例如，當"客戶下單"這個事件發生時，系統可能會生成一個日誌條目，記錄下單時間、客戶ID、訂單詳情等重要信息。當系統進行"庫存檢查"時，又會產生一個新的日誌條目，記錄檢查時間、庫存狀態等。

這些日誌條目提供了關於這些事件如何在實際操作中執行的重要信息。比如，從"客戶下單"的日誌中，我們可以知道客戶的需求和訂單的具體細節。從"庫存檢查"的日誌中，我們可以知道我們的庫存是否足夠，是否需要重新進貨。

進一步，如果某一個事件導致錯誤或異常，相關的日誌可以幫助我們快速定位問題，比如，如果"付款處理"失敗，日誌可能會記錄失敗的原因（比如信用卡過期或余額不足）。

因此，透過事件風暴識別的事件和相應的日誌，我們不僅能夠更好地理解業務流程，也可以獲得系統運行中的重要反饋，進而找出可能的瓶頸或錯誤，優化我們的服務。

如何要求應用程式將事件流輸出為日誌，並且這些日誌可以被後續的工具或系統進行收集和分析。就是12Factor Log的概念。

# 12-Factor App的Log觀念
解釋12-Factor App中日誌的角色和重要性，以及它如何作為系統狀態的重要反饋。

12-Factor App是一套用於構建軟體服務的最佳實踐指導原則，其中的[第11項原則](https://12factor.net/logs)正是關於日誌（logs）。這一原則認為，日誌應該被視為事件流，並應被持續地記錄並輸出到標準輸出（stdout）。

在12-Factor App的觀念中，日誌是系統活動的重要反饋，它們提供了一種監視應用程序行為，了解系統狀態，並在問題發生時進行調查的有效方法。日誌應該包含所有類型的事件，包括但不限於系統錯誤，業務級別的事件（如在我們之前的電商平台例子中的訂單生成和庫存檢查等），以及其他可能有助於分析應用程序運行的任何資訊。

例如，在我們之前的電商平台例子中，當一個新訂單創建時，這個事件應該在日誌中記錄，包括訂單的詳細資訊和訂單生成的時間等。當庫存檢查發生時，相應的日誌也應該被記錄，包括庫存數量和檢查結果等。

此外，如果付款過程中出現錯誤，這個錯誤也應該被記錄到日誌中，包括錯誤的時間、詳細的錯誤資訊等。這些日誌可以幫助開發人員瞭解問題的具體原因，並提供解決問題的線索。

因此，在12-Factor App的視角下，日誌不僅是記錄和查詢事件的重要工具，也是系統自我監控和問題診斷的重要手段。

此外也在這裡說明結構化日誌的重要性, 在[RFC-5242 Syslog](https://hackmd.io/DtNaKR5XRFy41eiv8mlmIA)中也提到過結構化日誌，在可觀測性工程領域內也是特別講究結構化日誌的重要性，以及一些基本組成。

# 從日誌到可觀測性工程
解釋日誌如何用於實現可觀測性工程。可提供一些實際的例子，說明日誌如何用於監控和優化系統。

在可觀測性工程（Observability Engineering）中，日誌是三大基石之一，另外兩個是度量（Metrics）和追蹤（Traces）。

日誌記錄了系統中發生的具體事件，通過日誌，我們可以看到系統的內部狀態和行為，包括錯誤、警告和其他重要事件。與度量（系統的整體狀態）和追蹤（單一請求的生命週期）一起，日誌提供了對系統的深度了解，使我們能夠監控，除錯，並優化系統。

在我們之前的電商平台例子中，我們可以進一步探討如何利用日誌實現可觀測性：

故障診斷和修復：日誌中記錄的錯誤和警告信息可以幫助我們快速定位和修復問題。例如，如果支付流程出現故障，日誌可以提供故障發生的時間、訂單信息和具體的錯誤信息，有助於我們快速找到並解決問題。

性能優化：日誌中記錄的信息，如訂單處理時間、庫存檢查時間等，可以用來分析系統的性能瓶頸。例如，如果庫存檢查時間過長，可能會影響到訂單處理的速度，我們可以通過優化庫存檢查的算法或流程來提高系統的性能。

業務分析：日誌也可以用於業務分析。例如，通過分析訂單生成的時間和數量，我們可以了解到客戶的購買行為和喜好，並根據這些信息來調整我們的銷售策略。

通過上述方式，日誌對於可觀測性工程來說，不僅是一種監控和除錯的工具，更是一種系統優化和業務分析的重要資源。

# OpenTelemetry的角色
介紹OpenTelemetry是如何幫助我們實現可觀測性工程的。你可以分享一些OpenTelemetry的使用案例，並說明它如何提高系統的可觀測性。

OpenTelemetry是一個開源的端到端的可觀測性數據集合和分析工具，它為日誌、指標和追蹤提供了一致的APIs和數據模型。OpenTelemetry使得工程師可以更容易地獲取應用程式的執行信息，並將這些信息發送到他們選擇的分析工具。

在我們之前的電商平台例子中，我們可以使用OpenTelemetry來實現可觀測性工程：

事件追蹤：例如，當一個新的訂單創建時，我們可以使用OpenTelemetry來追蹤該訂單的生命周期。這可以幫助我們理解每一步的性能並找出可能存在的問題。OpenTelemetry將這些事件（訂單創建、庫存檢查、付款處理等）串連起來，形成一個完整的追蹤。

系統指標：OpenTelemetry可以收集如訂單處理的時間、錯誤的數量等指標資料。這些指標資料對於分析系統性能以及發現可能的瓶頸非常重要。

日誌集成：OpenTelemetry也可以集成日誌，使得我們能夠在一個統一的介面下查看和分析日誌，追蹤和指標資料。

OpenTelemetry的目標是提供一種統一的方法來收集和處理各種可觀測性數據，以此來改善系統性能，定位錯誤，以及優化用戶體驗。透過它，我們可以更輕鬆地實現可觀測性工程，進而對系統有更深入的理解和掌握。

# 總結
當然可以。結論部分是簡報的終結，也是一個回顧主要觀點和重申學習要點的機會。以下是基於你的簡報主題的結論範例：

* Slide 1:
標題: 結論：從事件風暴到OpenTelemetry

內容：

我們討論了如何通過事件風暴來理解和定義業務流程中的事件，並將這些事件記錄為日誌。

* Slide 2:
標題: 日誌的角色和重要性

內容：

我們進一步探討了12-Factor App的日誌觀念，說明了日誌是如何作為系統狀態的重要反饋，並提供有關系統行為的重要信息。

* Slide 3:
標題: 日誌與可觀測性工程

內容：

我們解釋了如何通過日誌實現可觀測性工程，並分享了一些具體例子來說明日誌如何被用於監控和優化系統。

* Slide 4:
標題: OpenTelemetry的角色

內容：

最後，我們介紹了OpenTelemetry如何幫助我們實現可觀測性工程，並分享了一些OpenTelemetry的使用案例。

* Slide 5:
標題: 下一步

內容：

現在你已經了解了如何從事件風暴開始，通過日誌，實現可觀測性工程，並利用OpenTelemetry來增強你的系統的可觀測性。接下來，我鼓勵大家實際操作，將這些理論知識應用到實際的工作中，看看這些方法如何能幫助你提高工作效率和系統性能。

以上就是我們今天簡報的重要觀點，希望你們能從中獲益。如果有任何問題或想要進一步討論的話題，請隨時提出。謝謝大家！

---
q1:左圖跟右圖87%像
q2:針對訂單狀態 因為庫存數量影響訂單狀態
q3:事件風暴來找出邊界 有系統邊界後可以帶到追蹤 單點log或分散式追蹤