一校回饋 - HackMD

一校回饋 ==================== ###### tags: `Observability-Engineering` ## 對本書的讚譽你需要解決你前沒有見過問題的能力 -> 你需要解決你之前沒有見過問題的能力 ## 序言 p11 遙測管道 -> 遙測流水線 p12 O'Relly -> O'Reilly # 第一章 p21 漏翻的註釋-> 有時會加入時間跨度來表示「變化的離散事件」。這可以被視為遙測的一個擴充面向或第四大支柱。 p22 事際做法 -> 實際做法 p23 處在這一行中 -> 處在這一行業中時序性資料庫 -> 時序資料庫 # 第二章 p34 被餵入時序性資料庫 -> 被餵入時序型資料庫 # 第三章統一名詞, 可觀察性->可觀測性 # 第四章統一名詞, 可觀察性->可觀測性 p45 改變工作習慣有其必要性 -> 改變工作習慣是必要的可觀測性本身的目標在實現方式方面是語言中立的 -> 可觀測性本身不依賴於特定的語言或技術 ## 第五章統一名詞, 可觀察性->可觀測性 p51 只是在特定時間發生事件的聚合度量 -> 只是在特定時間發生事件的聚合數值 p52 整個字典會捕獲最近發生事情豐富紀錄 -> 整個字典會捕獲了對最近發生事情的豐富紀錄還是整個字典會捕獲了最近發生事件的詳細紀錄 p55 在現代，日誌通常會串流傳輸到集中式聚合器中，並且儲存在非常大的儲存後端中 -> 在現代，日誌通常會透過串流傳輸到集中式聚合器中，並且儲存在非常大的儲存後端中 p57 可觀測系統的後端資料存儲必須允許你的事件任意廣泛。 -> 可觀測系統的後端資料儲存必須允許你的事件任意廣泛。 ## 第六章統一名詞, 可觀察性->可觀測性 page 62 分散式追蹤（Distributed tracing）是一種追蹤單個請求，也可稱為追蹤 -> 分散式追蹤（Distributed tracing）是一種追蹤單個請求，簡稱追蹤我在想這裡的用簡稱比較適合, 因為之後全書都不會在提到分散式追蹤 p64 Span ID這的還需要一個唯一 ID 來標識每個創建的追蹤節點，包含在單個追蹤期間發生的工作單元中捕獲的資訊。這個唯一的 ID 可以在需要時參考這個追蹤節點。 -> 還需要一個唯一 ID 來標識每個創建的跨度節點，包含在單個追蹤期間發生的工作單元中捕獲的資訊。這個唯一的 ID 可以在需要時參考這個跨度節點。 p67 深入研究指標如何儲存在時序資料庫 -> 深入研究指標如何儲存在時序型資料庫對於如何理解指標和時序資料庫與可觀測性之間的不兼容 -> 對於如何理解指標和時序型資料庫與可觀測性之間的不兼容 p68 圖 6-3 範例應用程式現在會將 traceID 和 parentID 傳播到每個子跨 -> 圖 6-3 範例應用程式現在會將 traceID 和 parentID 傳播到每個子跨度。 p71 將事件定義為一個紀錄 -> 將事件定義為一個紀錄 traceDat -> traceData p72 非傳統的檢測使用方式是針對一些不需要分散處理的工作 -> 非傳統的追蹤使用情境是針對一些不需要分散處理的工作但你仍希望將其分成自己的檢測範圍 -> 但你仍希望將其分成自己的跨度範圍其中一個方法是將這些「熱點區塊」的程式碼包裝成自己單獨的檢測範圍 -> 其中一個方法是將這些「熱點區塊」的程式碼包裝成自己單獨的跨度單體式或非面向服務的程式中創建檢測 -> 單體式或非面向服務的程式中創建追蹤在可觀測系統中，任何一組事件都可以串成檢測，且檢測不一定僅限於服務對服務呼叫 -> 在可觀測系統中，任何一組事件都可以串成追蹤，且追蹤不一定僅限於服務對服務呼叫而檢測僅是一系列相互關連的事件 -> 而追蹤僅是一系列相互關連的事件將跨度拼合成一個有連貫性的檢測所使用的概念 -> 將跨度拼合成一個有連貫性的追蹤所使用的概念 ## 第七章 p79 以便確定服務的狀況或受到影響的使用者集 -> 以便確定服務的狀況或受到影響的用戶群 p80 sp.SetAttributes(attribute.String("app.user", username))</C> -> 多了</>C> p94 了解如何使用遙測管道來規範和管理資料的結構。 -> 了解如何使用遙測流水線來規範和管理資料的結構。 ## 第八章 p90 系統測量基線 -> 這裡我想加入註解, 方便後續閱讀時更清楚 <註>基線（baseline）指的是系統在正常或預期運行狀態下的性能指標。它作為一個參考點或基準，用於與異常狀態（即你正在調查的問題區域）進行比較。</註> p92 圖8.3中的 Baseline和Selection有需要翻譯成基線事件與選定區域嘛? 在深灰色長條則顯示在基準線事件中只有 17% 的事件如此。-> 在深灰色長條則顯示在基線事件中只有 17% 的事件如此。 ## 第九章 p99 像度量這樣的聚合量測很好，但度量不是指示你所開發的程式碼 -> 像指標這樣的聚合量測很好，但指標不是指示你所開發的程式碼設計它以用於檢測認知缺乏的故障 -> 設計它以用於檢測認知缺乏（unknown-unknowns）的故障軟體是你的業務想要運行以解決市場問題的具體內容 -> 軟體是你的業務想要運行以解決市場問題的具體內容系統是你的業務需要運行行，以支援所要運行的軟體 -> 系統是你的業務需要運行行，以支援所要運行的軟體 ## 第十章 p112 快速證明投資回報 -> 快速證明投資回報率使用 OpenTelemetr 對應用程式進行自動化檢測 -> 使用 OpenTelemetry 對應用程式進行自動化檢測 p126 是用於指標監控的時序資料庫 -> 是用於指標監控的時序型資料庫 ## 第十二章 p131 為實際營運環境流量提供服務的分散式系統中，故障是不可避免的。 -> 為實際營運環境流量提供服務的分散式系統中，故障是不可避免的。 p132 自動修復的失敗不應該觸發警報。 -> 自動修復的失敗不應該觸發警報。這並不是說你不應該排除自動修復的失敗，在正常工作時間內，你絕對應該排除這些失敗。 -> 這並不是說你不應該排除自動修復的失敗，在正常工作時間內，你絕對應該排除這些失敗。 p133 較少組件的傳統自包含軟體系統 -> 較少組件的傳統獨立軟體系統譯者註：傳統的自包含軟體系統在設計上較為簡單 -> 譯者註：傳統獨立軟體系統在設計上較為簡單參考自微軟, https://learn.microsoft.com/zh-tw/dotnet/core/deploying/trimming/trim-self-contained p135 服務水準目標（SLO）是衡量服務健康狀態的內部目標 -> 服務水準目標（SLO）是衡量服務健康狀態的內部目標但是，沒有任何關連性說明原因，以及服務性能如何受到影響，只能知道有問題存在。 -> 但是，我們對服務性能為何和如何受到影響沒有任何相關的解釋或聯繫，只能知道有問題存在。因為原文有why跟how, 想說這翻譯好像沒法提取出這兩個問題點 p136 警報的第二個準則是必須是可行動的 -> 警報的第二個準則是必須是可操作的 p137 在封閉式、不變的系統中 -> 在獨立、不變的系統中響應p133那個修改, 都是self-contained 請注意，是所有相關資料，而不是所有警報。 -> 請注意，是所有相關資料，而不是所有警報。 p149 measure 測量->量測 ## 第13章 p150 詳細的推斷機制可見第 148 頁「根據上下文的燃燒警報」的更詳盡說明。這個頁碼是原文的頁碼, 翻譯的會在更後面頁碼 p152 在接下來的兩節中，單位指的是用於 SLO 燃燒警報計算的細粒度構建塊 -> 在接下來的兩節中，單位指的是用於 SLO 燃燒警報計算的細粒度構建塊根據典型的流量量 -> 根據典型的流量數量 p153 根據典型的流量量 -> 根據典型的流量數量 p157 使用不同的向前查看窗口大小 -> 使用不同的預測窗口大小 ## 第14章 p163 CI/CD 管線 -> CI/CD 流水線 p181 會有更多關於觀察性管道的細節 -> 會有更多關於可觀測性流水線的細節 ## 第15章 p183 地殼深處的「砹」數量在任何時候都少於 1 克 -> 地殼深處的「砈」數量在任何時候都少於 1 克 p202 （CI / CD）構建管道 -> （CI / CD）構建流水線 ## 第16章 p208 時序性資料庫（TSDB）看起來似乎是一個理想的選擇 -> 時序型資料庫（TSDB）看起來似乎是一個理想的選擇 p209 時序性資料庫對於可觀測性的不足 -> 時序型資料庫對於可觀測性的不足 p210 圖 16-1 顯示一個典型的時序性資料庫（TSDB） -> 圖 16-1 顯示一個典型的時序型資料庫（TSDB） p219 程式碼範例中 (note: timestamps do not need to be chronological) -> （註︰時間戳記不需要按照時間順序排序） p223 並用作索引或查找查件 -> 並用作索引或查找