累積日誌的好處 | 原創，AI翻譯
累積日誌的好處
我之前在一間銀行擔任承包商時，我們使用多雲應用平台來提供微服務。那時候，我開始在公司工作時就培養了累積日誌的習慣。
幾年過去了，我仍然認為這是幫助我工作或進行軟件工程的最佳方法之一。隨著時間的推移，我的日誌目錄中累積了數百個日誌文件。
我沒有為這些日誌文件特定的子目錄或正式的命名規則。有時，我只是使用JIRA任務名稱或該功能的名稱作為日誌文件名的前綴，然後在後綴添加一個數字。例如，mutual-fund-1.log，mutual-fund-2.log等。這意味著在共同基金微服務中，我在運行該微服務時有那個日誌。
有時，當我處理為多個地區提供服務的項目時，我會將該國家作為後綴添加，例如mutual-fund-cn-1.log，mutual-fund-sg-1.log。日誌的文件名有些隨意。因為那時候，我需要專注於錯誤堆棧或周圍的函數調用。
程序的日誌很重要。每個人都知道。但是，我想強調累積日誌的重要性，而不是僅僅在控制台查看它們然後就放任不管。當項目進行時，你會發現更多的便利。你有更多的時間來查找以前的日誌。你可能需要知道以前是否發生過類似的數據庫存儲過程調用。你可能需要知道以前是否發生過相同的錯誤。你可能需要回憶上次如何解決這個問題。
在一個大型項目或數十個微服務中，有大量的細節。錯誤、異常或問題不斷重複發生。日誌就像是程序的運行文件。它們是由程序自動生成的，無需人工輸入。對於開發人員來說，這些日誌是可讀的。因此，當你開始一個新任務或修復一個新錯誤時，你手中有數百個日誌來修復這個新錯誤。你並非孤單。
我們為什麼要累積它們？因為事物或知識很容易被遺忘。
當紙張發明時，人類文明取得了進步。當計算機發明時，人類文明又達到了一個新的層次。在紙上做筆記就像在電腦中累積日誌一樣。
不僅是對於人類，對於AI聊天機器人、大型語言模型工具來說，這些日誌正變得越來越重要。GreptimeDB，一個成立於2022年，用於統一收集和分析可觀測性數據（指標、日誌和追蹤）的數據庫，它的出現並非巧合。
我以前為什麼不這樣做？在我為大型銀行擔任承包商之後，我需要進行更多的協作並參與更大的項目。在那之前，在創業公司或我創業期間的大部分時間裡，我都是單打獨鬥。我之前在LeanCloud工作時，我大約一半時間都在開發IM應用LeanChat。
當我進入更正式的企業環境時，項目的開發與我的個人項目或創業項目不同。他們有SIT、UAT測試環境。生產環境通常只對某些小團隊成員開放。從他們那裡獲取日誌並解決問題變得漫長而有些乏味。運行一個項目需要時間，而Jenkins流水線通常需要半小時才能運行。
所以我不能像飛一樣運行或測試程序。我不能僅僅通過在個人電腦上輸入命令並將代碼上傳到服務器來執行部署。
因此，它在某種程度上讓我累積日誌以獲得更多的上下文來處理任務。我們最好一次性解決問題。我們最好在幾次內驗證我們的修復。我們不容易從在雲端或公司服務器上運行的程序中獲取日誌，所以我們最好將其複製並保存到本地筆記本電腦上進行分析。
現在，對於我的個人項目，我也會累積日誌。這成為了一種習慣。在大型公司工作了幾年之後，我對讓我的項目更大、更長遠，有了更多的耐心或策略。所以我知道隨著時間的推移，我需要這些日誌。
有人可能會說，你只需要優雅的代碼和一個正常的項目。你不需要累積日誌或錯誤堆棧追蹤。沒關係。當我們遇到錯誤或需要開發新功能時，我們可以運行程序來獲取當前的日誌。我們不需要開發過程中的日誌。它們就像科學實驗的詳細記錄。乍一看，這似乎沒問題。但從長遠來看，如果有一天你想再次處理它，或者你想分享它，或者讓別人接手它，這可能就不太好了。
我認為這裡可能有很多機會。在公司裡，我們為什麼不鼓勵每個開發人員分享他們累積的日誌呢？在開源項目中，我們也應該這樣做。我們不覺得別人的日誌有吸引力，因為我們不了解它們。我們在保存這些日誌時失去了上下文。而且在其中，似乎有大量不相關或瑣碎的消息。
但是累積日誌的努力是微不足道的。每次我們看到一些日誌，尤其是錯誤日誌時，只是簡單地複製和粘貼。那麼我們如何以自動化的方式來做呢？每次運行項目時，將日誌記錄在一個目錄中，例如那些Spring Boot項目，這是一個好主意。
世界變得越來越數位化，所以累積數位程序的日誌就像在實體世界中累積書籍一樣。