從控管記錄資料產量實踐FinOps

如果妥善地執行記錄，良好記錄可以提供關於資料管道等複雜系統的狀態和寶貴的運行資訊。在調試、除錯問題時，一條經過深思熟慮且妥善設計的訊息內容可以點出發生的問題，好讓人藉此線索來解決問題，是不幸中的大幸。

除了調試、除錯問題和觀察執行情況外，將記錄下的資料導出到諸如Google BigQuery之類的查詢工具，也可以將格式良好的記錄儲存至資料庫。分析這些巨量的記錄可讓人進一步了解整體效能和系統健康情況，並生成對應的監控指標。但若是無法完善地執行記錄，則這件事也可能成為絕望的深淵，例如，過度的記錄會拖慢效能表現並增加雲端成本支出。過多或考慮不周全的記錄可能會破壞使用日誌檔偵錯和分析的能力。此外，如果意外地記錄下憑證、金鑰和其他敏感資訊，還可能會造成安全事件，並在某些情況下違反法律。

記錄成本

巨量資料的處理加上雲端儲存的彈性，可以為資料管道創造出一個完美的風暴，即產生大量的記錄資料。

在我過往的資料管道開發經驗中就曾遇過這類情況，記錄使執行時間翻倍增加，並且使得每個月的雲端成本支出增加了數千美元。除此之外，記錄方式也會受到不同使用情境的影響，例如，在本地開發環境中，針對少量資料來調試、除錯問題時，因為是單一執行程序，故無須在記錄訊息內容中加註標籤標示源於哪個程序。但若是換成分散式環境的話，同樣的使用方式會使得日誌檔內容難以理解，因為無法從中得知是產生這筆記錄訊息的執行程序。

還有一種最糟糕的情況：大量的日誌檔對整體效能產生嚴重的影響。由於記錄檔的資料量和執行時間的增加，雲端成本也隨之增加；最重要的是，這些記錄並沒有考慮到擴展性，所以它們不僅對於調試、除錯工作毫無幫助，甚至還因為大量冗餘、無用的資訊內容，而淹沒重要的日誌訊息。

 規模的影響 

為較小規模的執行環境所設計的記錄實踐方式，在面臨較大規模的執行環境時，可能會造成問題，這尤其適用於更詳細的日誌檔設置，例如為調試、除錯目的而設定的那些日誌檔。

有時，這種情況會發生在巨量資料處理管道導入為較小規模的執行環境所設計的記錄實踐方式。當該日誌檔在集中式執行環境中運行時，或許能提供有用資訊；但若是在平行部署時，它可能變成大量無連貫性的訊息內容。至於那些用於開發或為調試、除錯目的而添加的程式碼，也可能引起這些問題。

 雲端儲存彈性的影響 

坦白說，雲端記錄是一件好事，在Pod或叢集關閉後，還能夠利用它的回顧記錄來了解發生的事情。但它所帶來的缺點，可能會沒注意到這些雲端操作產生大量記錄資料，直到帳單出現。

FinOps基金會曾發表過一篇文章〈Managing Retention in CloudWatch〉（https://oreil.ly/ sIXD6），提及每月超過1400美元的費用都是源於不必要的調試、除錯記錄。關於這種情況的一個有趣之處是，在雲端帳單中，費用支出會呈現為特定物件操作的成本，PutLogEvents。物件在保存到雲端儲存中時，您會承擔許多不同的成本，如儲存靜態資料的成本，和對該物件執行操作的成本；使用雲端記錄時，還可能會有針對記錄的攝取成本，以及儲存記錄的成本。

降低記錄成本

可以透過多種方式來利用雲端記錄的好處，同時控制成本支出，這包括替雲端服務設定限制、設計記錄的技術，以及相關維運工具來處理巨量記錄。

先從雲端服務方面開始。使用雲端記錄時，通常會永久保留記錄，除非特別設定記錄的保留期限，如在AWS〈Altering CloudWatch log retention〉一文所述。設定記錄保留期限，將使得日誌檔在特定時間後移除，以確保不再儲存不需要的記錄檔。

不同服務和環境的記錄保留期限也會有所不同，例如，至少保留一週的正式環境記錄，對於調試、除錯和監控來說可能很有價值。至於在測試環境中，您可能僅會在短期時間內進行故障調試，因此使用較短的保留期限設定或許更具成本效益。

除了設定保留期限，也可以進一步地設定應轉發到記錄服務的記錄，及應忽略的記錄。這可以使您專注於感興趣的記錄內容，並進一步地減少多餘記錄持續占用儲存空間。例如，Google Cloud Logging允許您設定排除與包含的過濾條件來達到這一目的。

在記錄技術方面，利用不同的日誌級別有助於調節記錄的詳細程度。Python官方文件的記錄主題（https://oreil.ly/Uyw0-）中，包括取決於想傳達的資訊類型，而何時使用不同記錄級別的概述；換言之，可以在不同環境中選擇不同記錄級別。例如，在正式環境中，可能會使用預設的WARNING級別來顯示資訊類別的訊息、警告和錯誤，同時降低調試訊息出現的頻率；而在開發或測試環境中，則可以將記錄級別設置為DEBUG來獲得更多訊息。

對於訊息量特別多的模組，可以考慮用更細緻地方法控制記錄。例如，在預設記錄級別為DEBUG的測試環境中，可以引入一個額外的控制參數，來進一步地設定此模組的級別是否允許印出所有詳細資訊。在一般情況下，可以先將此模組記錄級別的參數設為INFO，以減少記錄的訊息；如果有需要更多記錄的情形也可以改變級別，而不是不斷地處理可能無用的大量訊息。

基於上述配置策略，可以在不更改程式碼的情況下更改記錄級別，這種方法還可以在不同環境中使用不同記錄級別。我們曾藉由環境變數來實現這一點，在測試環境中將參數設定為DEBUG，但在正式環境中關閉，如果正式環境中出現問題，本團隊就可以透過切換一個環境變數，來重新啟用調試記錄。

特別值得一提的是，針對Python，可以透過延遲建立日誌訊息來減少記錄對效能的影響。從Python記錄流程（https://oreil.ly/dxMWJ）中可以看到，只有在記錄器啟用時，才會創建一個記錄，沒啟用的話則不會創建。

如下所示，這裡有兩種使用變數以記錄訊息的不同方法，第一種方法是使用%格式化；另一種方法是使用f-strings：

logger.debug("Finished extracting species for user %s. Species extracted: %s",
 user_id, species)
logger.debug(f"Finished extracting species for user {user_id}.
 Species extracted: {species}")

現在來試想在記錄級別設定高於DEBUG的環境中會發生的事。在使用f-strings的情況下，調用logger.debug函式之前，記錄訊息已經被插值；無論記錄處理程序是否實際創建記錄，都會創建這個字串。

在使用%格式化的情況下，將user_id和species作為參數傳遞給logger.debug函式，僅在需要記錄的時候，由記錄處理程序進行字串插值。

雖然這可能看起來是微不足道的小事，但請記住，在處理巨量資料的情境中，任何微小事物都有可能會累積成巨大的影響。

以Python為例，另一種優化策略是條件式記錄法（https://oreil.ly/NRux3），在這種技術中，只有在滿足某個條件時才能建立日誌訊息。對於仰賴記錄來調試、除錯問題的情境，這是一種限制日誌訊息筆數的好方法；如果沒有發生故障，會丟棄原本寫入記錄的訊息。記錄使管道的運行時間翻倍，但如果僅在發生錯誤時會 留下診斷的日誌訊息，則採用條件式記錄法將會消除大部分記錄。

如Python官方文件中的範例所示，妥善設置記錄暫存區大小是一個好習慣，這將防止過度浪費記憶體空間在暫存的記錄訊息上，以合理使用記憶體容量。（本文摘錄整理自《具成本效益的資料管道》第十章，碁峰資訊提供）

圖片來源_碁峰資訊

 書名  具成本效益的資料管道（Cost-Effective Data Pipelines）

Sev Leonard／著；簡誌宏／譯

碁峰資訊出版

定價：680元

 作者簡介 

Sev Leonard

在科技產業擁有20多年的經驗。在英特爾微處理器的電路設計、使用者驅動的應用程式開發、醫療保健和網路安全領域，從小規模到大規模的資料平台開發方面，都擁有豐富的經驗。在他的整個職業生涯中，Sev Leonard一直擔任作家、演說家和教師，致力於傳承他所學到的知識，讓所有人都能接受技術教育。