syslog替代者Journal詳細解讀

BKJIA編者按：在前幾天的外電頭條中，我們說到紅帽的兩位開發人員表示將用The Journal替換掉原本的Syslog。下面這篇是LinuxToy上翻譯的兩位開發人員的原文內容，裡面對The Journal的功能進行了詳細的介紹，還有一些常見問題的解答，以供參考。

Lennart Poettering 發表長篇文檔介紹 systemd 即將添加的新功能：Journal。

介紹 Journal

今天將為您介紹在過去的幾周我們在致力實現一個 systemd 的新功能。這項新功能同時將協助我們顯著的簡化迷你安裝的 Linux 系統，同時帶來一些新的概念，也會取代一個經典 Unix 系統中的組件。因此它需要一個比較長的介紹。所以請準備好一杯熱巧克力，慢慢閱讀。

背景：syslog

長久以來 syslog 是每一個 Unix 系統中的重要組件。在漫長的曆史中在各種 Linux 發行版中都有不同的實現去完成類似的工作，它們採取的是邏輯相近，並使用基本相同的檔案格式。

如其名所述，syslog 守護進程的任務是系統記錄。它從應用程式和服務中擷取格式各異的日誌訊息並儲存到磁碟上。通常，這些訊息唯一的中繼資料是組件名、優先順序、時間戳記、進程標籤和 PID。這些屬性由用戶端傳入，不經過驗證就直接原樣儲存。很多這些屬性都是可選的，不同的實現中具體的格式也是有很大變化的。有個 RFC 嘗試逐漸改進和正常化訊息格式，但是最重要的實現(比如 glibc’s syslog() 調用)基本無視了這些改進。

現實中，寬鬆的 syslog 日誌訊息格式帶來了靈活和強大，但同時也成為它最大的不足。因為沒有定義結構化的格式，系統的分析和日誌訊息處理變得十分混亂：在將其翻譯為人類語言的過程中大量與訊息產生源相關的上下文都丟失了。而且還有很多日誌分析器會嘗試通過分析人類語言來重構上下文。

Syslog 已經存在了差不多 30 年了，由於它的簡單和普遍，成為系統管理員的一個重要工作。但是它切實存在的局限開始導致一些嚴重的問題：

很多這些問題在最近變得十分明顯，例如覺察修改了記錄檔的入侵行為通常僅能靠運氣。此外，由於 syslog 的功能所限，目前部分使用者常常要依靠一些閉源的組件來處理收集到的日誌資訊，使其變得有意義，訪問更便捷。

日誌是服務管理中關鍵的一部分。在 Unix 系統上，絕大多數的運行服務都串連到 syslog 來寫入日誌訊息。在 systemd 中，我們將日誌做為服務管理的核心部分：從 Fedora 16 開始所有啟動的服務都將把標準輸出和錯誤輸出自動連接到 syslog 上。 不管服務是在啟動早期還是正常操作中，它的輸出結果都會儲存到系統日誌中。因此，由於日誌如此重要，於是需要特別配置才能禁用它，將原先的“可選記錄”策略轉變為“可選不記錄”策略。資訊透明不再是明智的選擇，而是預設選擇。

在開發 systemd 的過程中 syslog 的局限變得愈加明顯。例如：我們非常想添加的的一個簡化系統管理工作的功能是當使用 “systemctl status foo.service”時，在通常服務資訊的下面顯示最近的 10 條日誌資訊。若是使用經典的 syslog 這個實現將是難以忍受的低效率、不可靠和不安全：需要對於所有記錄檔的線性搜尋可能涉及即時解壓的操作），並且儲存的資料也是被修改過的，無法快捷的和 systemd 的服務名和運行環境匹配。

如果用一句話代替這些內容：傳統的 syslog 在 30 年的發展中演變成為有很多嚴重局限的強大工具。

現在，我們將如何改變這個狀況？

Journal

您可能已經從如上的描述中猜出了：我們正在開發一個解決已有日誌問題，彌補以上不足並且增添了一些新功能的工具：Journal。

當然，構建一個全新的系統核心組件時，設計目標必須要明確：

說了很多設計目標，下面是一些我們實現過程的技術概覽，並介紹新系統是如何工作的：

受 udev 事件啟發，Journal 條目與環境組塊相似。一個索引值域，按照分行符號分開，使用大寫的變數名。和 udev 裝置事件和真實環境組塊相比，有一個主要不同：儘管毫無疑問主要值會是 ASCII 格式的字串，也支援以二進位為值 -- 某些情況下可以用來添加 ATA SMART 健康資訊、SCSI 資料、核心轉儲或韌體轉儲。由代碼產生的 Journal 條目可以包含多個域，既可以是已知的類型，也可以是服務/子系統/驅動特定的。

應用程式和服務可以通過將項目域傳遞給 systemd journald 服務來產生項目。該服務可以為項目增加一定數量的中繼資料。這些受信任域的值由 Journal 服務來決定且無法由用戶端來偽造。一旦牽扯到硬體和核心裝置，Journal 服務將為記錄項目添加從 udev 資料庫獲得的當前裝置資訊，其中包含了所有裝置名稱和符號連結，以及與 Journal 條目關聯的其他裝置資料。

由 Journal 守護進程添加的域將具有底線首碼(“_”)， 用來標示該地區是可信的，而不是由未知用戶端提供的。應用程式自身無法傳遞以底線開頭的的網域名稱稱。這是一個範例展示在用戶端傳輸基礎上新增內容的日誌條目展示：

_SERVICE=systemd-logind.serviceMESSAGE=User harald logged inMESSAGE_ID=422bc3d271414bc8bc9570f222f24a9_EXE=/lib/systemd/systemd-logind_COMM=systemd-logind_CMDLINE=/lib/systemd/systemd-logind_PID=4711_UID=0_GID=0_SYSTEMD_CGROUP=/system/systemd-logind.service_CGROUPS=cpu:/system/systemd-logind.servicePRIORITY=6_BOOT_ID=422bc3d271414bc8bc95870f222f24a9_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721_HOSTNAME=waldiLOGIN_USER=500

該範例條目是由 systemd logind 守護進程在使用者 “harald” 登入時建立的。如您所見它自動添加了相當複雜的資料，包括一些重要的執行進程參數。更加詳細的定義的域說明請參考：

Well Known Journal Fields

原生的 Journal 檔案格式從經典的記錄檔和 Git 倉庫獲得啟發。它被設計來只將日誌資料添加到末尾(用來保證基於 mmap() 的訪問的健壯和原子性)，以及一些在用來反映新新增內容的檔案頭中繼資料變更。這些用來組成項目的域以獨立對象的方式儲存在 Journal 檔案中，當需要時被項目所引用。這將節省大量的磁碟空間，因為記錄項目通常會有很多的重複(試想：每個本地的訊息都會包含相同的HOSTNAME= 和 MACHINE_ID= 域)。資料域還會被壓縮來節省磁碟空間。直接效果就是儘管 Journal 相比經典的 Syslog 明顯記錄了更多的中繼資料資訊，但是磁碟佔用卻無明顯變化。

磁碟上使用特定的 64位 LE(從小到大)位移，目的是簡化操作並保證我們可以儲存大小可觀的位元據。日誌瀏覽工具和 journald 之間的無需同步，需要瀏覽 Journal 檔案的用戶端可以簡單的使用 mmap() 訪問檔案，並使用檔案變化通知來告知更新。

提供用於用戶端訪問 Journal 檔案的庫，用來實現對項目任意域的索引，以及通過單調化或者時序化時間戳記的隨機訪問。用戶端庫會自動合并多個 Journal 檔案使其看起來好像是一個統一的 Journal 項目流。這用來隱藏底層細節譬如已經歸檔的檔案，或屬於多個使用者的 Journal 檔案。在瀏覽介面上透明化的 Journal 檔案合并是完全動態：當建立新的 Journal 檔案或者刪除舊的檔案時都會自動更新瀏覽視圖。事實上，Journal 瀏覽期望做到即時性的，從而實現對 Journal 來源的即時監控。

Journal 用戶端庫標頭檔

從非特權登入使用者發來的訊息將按照每使用者分割為獨立的 Journal 檔案。使用 POSIX ACL 來實現讀取許可權控制，保證使用者可以訪問他自己的 Journal 檔案。系統服務產生的 Journal 條目預設情況下無法被一般使用者訪問，除非他們屬於一個特殊的 Unix 使用者組。值得注意的是檔案的分割是用來協助合適的存取控制的，但是全域的上下文並未因此丟失。用戶端會通過所有訊息強制按照統一的排序的方式將 Journal 檔案合并起來，從而保證自動分配的序號碼的全域順序。這意味著可以在不影響使用者條目內容相關的情況下實現存取控制。

Journal 的核心思路就是統一目前所用的各類日誌記錄技術。因此它將成為 wtmp 的替代品，啟動早期記錄器甚至授權記錄後端。資料將從各種不同的來源產生：printk() 產生的核心訊息，syslog(3) 產生的使用者態訊息，使用原生 API 產生的使用者態條目，通過 /proc/proc/sys/kernel/core_pattern 產生的核心轉儲及更多。以後我們希望能有韌體訊息(UEFI 日誌)的鉤子，並擴充基於核心的日誌來支援核心中結構化日誌。因為在 Journal 資料結構中所有的域都是隱式的索引過的，所以跟 wtmp 相比從 Journal 的中提取使用者資料是個很簡單的操作。啟動早期和運行時日誌時統一的。只要 /var 不可用，所有的 Journal 條目便會自動儲存在 /run 下，等待 /var 可用時再立刻寫入。這意味著最終所有系統產生的訊息，不管是在 POST 中由韌體，還是在核心初始化，啟動早期還是運行時，都將儲存到索引的 Journal 檔案中。

為了讓條目可以被用戶端工具識別出來，Journal 條目可選包含一個 128 位的標示符，由產生訊息的服務設定於 MESSAGE_ID= 中。這個 ID 應該由開發人員在開發過程中隨機產生的。例如，一個 ID 表示“使用者登出”而另外一個 ID 表示“使用者登入”。所有這些事件的條目都分別包含 128 位的 ID，因此將很容易辨識出來並索引。這個 ID 完全可以和 RFC4122 UUID 類型四保持相容，但是這嚴格的來說並不需要故也不強求。該設計會和其他採用 UUID 標示訊息類型的日誌系統保持相容，比如 UEFI 韌體日誌。考慮到128 位 ID 的全域錯誤碼的隨機本質，它們並不需要一個集中式的標準化機構來為某個特定的訊息類型指定 ID。指定訊息 ID 是完全可選的，我們認為只要少量的 Journal 的條目會包括它，比如那些需要被使用者態識別出來的部分。如果一個開發人員需要為他新引入的訊息類型指定一個新 128 位 ID 的話，只需要運行 “cat /proc/sys/kernel/random/uuid” 即可，它會在每次啟動並執行時候返回一個新的 UUID。這 128 位的 ID 亦可用於實現本地化的訊息 UI，按照他在 UI 工具中尋找翻譯過的訊息，然後呈現給使用者。

所有的條目都用現即時間和單調時間打上時間戳記。為了使單調時間戳記有意義，所有的訊息同時也包含啟動並執行 Linux 核心的啟動 ID (比如 /proc/sys/kernel/random/boot_id)。精確度是 1 微妙，現即時間採用 UTC 計時以避免遭受和 syslog 類似的時區問題。

Journal 檔案可以復原、刪除、複製到其他機器、合并或者更改。為了保證應用程式、同步公布和網路服務可靠的識別條目，所有 Journal 條目都可以用一個指標字串標識。一個這樣的字串可以標識一個特定的訊息，甚至在條目丟失或不可用時也保持不變，於是可以用來定位最近的下一個條目。

如果超過某個限額的話，journald 會自動復原 Journal 檔案。這被內建在磁碟空間分配的邏輯中，目的是避免單純基於時間復原的漏洞。復原不僅考慮最大磁碟利用限制，並且還將監視通常的磁碟使用水平來保證磁碟上至少預留有一定空間。

由用戶端發送的條目隱含的受到速率限制，避免未信任的用戶端通過大量發送自身資料的方式衝掉 Journal 中的相關資料。這個速率依照可用磁碟空間調整，於是在磁碟空間富裕的時候速率會高些，而磁碟空間低時將會強製為較低的速率。

在初始版本的 journald 中對於網路支援會非常簡陋：要在網路中分享 Journal 檔案的話，使用比如 scp、rsync 或者 NFS 複製到一個集中化主機上。Journal 瀏覽器用戶端將會透明化的合并這些檔案，如果需要的話進行交叉儲存。在稍候的版本中我們計劃最低限度的擴充 Journal 來支援即時遠程日誌，通過用本地 Journal 檔案做為緩衝的儲存-轉寄邏輯來實現 PUSH 和 PULL 兩種模式。不管使用何種模式，Journal 的底層格式設計適用於擴充到大規模主機環境，所有的條目都會用機器 ID 和主機名稱來標示。目的是實現一種有效 Journal 監控工具完成透明化、即時的多重主機日誌瀏覽任務，並且留給管理員按照自己需要調整傳輸方式的空間，比如是否即時功能比避免大量進程響應(Thundering Herd)更重要等。

互連網是個險象叢生的地方。對於重要網站的入侵已經變得愈加常見。在成功的滲透之後，攻擊者通常會通過編輯記錄檔的方式掩藏他的蹤跡。 這類修改在傳統的 syslog 下很難檢測：因為它用的是沒有加密認證的純文字，所以無法獲知變更。從 Git 中獲得啟發，Journal 中的所有條目都是加密雜湊過的，且在檔案中包含先前條目的雜湊值。這樣的結果是一個條目鏈，每一個條目都可以認證之前的全部。如果最頂端的雜湊通常都儲存在一個唯讀位置，整個鏈條都可以通過它認證。檢測攻擊者的修改將變得十分容易。

如上所述日誌是服務管理的必要部分。這不僅意味著服務本身的日誌輸出將傳遞到 Journal，並且將為額外的服務事件產生 Journal 條目，比如當服務開始、錯誤推出、停止或崩潰之時。

Journal 的守護進程 journald 首先將取代目前 systemd 分發的兩個日誌相關迷你守護進程(systemd-kmsg-syslogd and systemd-stdout-syslog-bridge)。長期目標是在多種安裝配置中取代傳統的 syslog 守護進程，而不造成衝突。由於運行服務的減少(由 3 降為 1)以及相比全尺寸的 syslog 守護進程少很多代碼的 journald，Linux 系統的資源消耗將會減低。

目前狀態

目前為止，核心的功能和和全部重要的演算法已經實現並放置在 systemd git 的 Journal 分支中。但是代碼目前還不完善，缺少一些上面提到的功能。

這篇博文是用來澄清一些社區中對於我們計劃、選擇和原因的誤解。

我們計劃在 Fedora 17 中初步實現，不過在首次亮相中只選擇與極少幾個組件關聯。rsyslog 會和它一起運行，使用者可能會很難注意到它，除了 “systemctl status” 將會顯示所有服務的最近日誌資訊，以及嘗試使用我們的用戶端工具，比如 “journalctl” 來搜尋索引的 Journal 時。

常見問題及回答

我們一直在和不同知識背景的人討論，收集想法、建議和批評。有一些問題經常被重複提到，下面就是我們的回答：

Journal 很酷，但是 systemd 很糟糕。我可以不用 systemd 而單獨使用 journald 嗎？

不行。日誌是服務管理的核心部分。Journal 和 systemd 緊密結合從而保證系統的每一個部分都可以監控，查詢和除錯。產生的 Journal 項目是從 systemd 的不同部分查詢出來的。實際上，systemd 和 journald 是如此緊密耦合以至於拆分開的舉動毫無意義。不過正如所說，這是自由軟體，您可以隨自己願望修改代碼。最後，您認為 systemd 很糟糕的想法是錯誤的。

運行 Journal 會破壞 rsyslog/syslog-ng 嗎？

不會。您可以同時運行 rsyslog 或 syslog-ng 及 journald，syslog 訊息會雙雙記錄在 rsyslog/syslog-ng 和 Journal 中。但是，Journal 將記錄一些純文字的 syslog 所不具備的豐富元資訊。

我的應用程式需要在磁碟儲存傳統的純文字日誌。我可以配置 Journald 產生嗎？

不能。如果您需要這樣做的話，只要和 Journal 同時運行一個傳統的 syslog 實現如 rsyslog， 即可協助您產生想要的檔案。

為什麼 Journal 不產生傳統的記錄檔？

簡單來說，傳統的記錄檔無法索引，並且其速度隨著複雜度按照函數 O(n) 降低。原生的 Journal 檔案格式下關鍵操作速度隨著複雜度按照 O(log(n)) 降低，效能更佳。更多原因請參考上面章節。

我可以串連一個 syslog 協議相容的遠程 RFC 到 Journal 嗎？

在目前您不可以，並且 Journal 也不太可能會預設支援這個。但是編寫一個可行的轉換器或者網關應該不困難。

我在嵌入式裝置上使用 systemd 於是對永久性儲存日誌不感興趣，我可以移除 Journal 嗎？

不可以。但是您可以告訴 systemd 您不需要永久性日誌。通過移除或者一開始就不建立）/var/log/journal 目錄，在這種情況下 journald 僅會將記錄到 /run/log/journal (如同在早期啟動的情況下)。/run 是臨時的並且會在重啟時丟失，和 /var 不同。在此之上您可以將 Journal 使用的最大磁碟空間設定為一個很小的值。

人人都說 UUID 是有問題的。為何還要用 UUID 來表示訊息呢？

UUID 規格的確是奇形怪狀且不必要的複雜。因此我們推薦只要和 UUID 類型4保持一致即可，不用理會 RFC 4122。實際上 UUID 已經在 Linux 上成功的應用了很長時間，所有發行版預設都是依據檔案系統 UUID 來執行掛載的。

但是 UUID 從來沒正常工作過！比如 MAC 位址是重複的並且所有我的 USB 裝置都使用的同一個。為什麼要堅持使用它呢？

我們實際上一直在使用它，比如像上面說的在檔案系統中，它工作的很好。硬體都包含有序號，不少廠商初始化為 1-2-3-4-5，但是它和 UUID 沒什麼關係。裝置序號並不是 UUID，不要混淆！

另外，我們並沒有強制使用它們。如上所述它是完全可選的，並且只需要並賦予到需要後來識別出來的訊息上即可。

但我在代碼中引入了一個 UUID 來標識一個訊息類型，其他人使用了該段代碼做為別的工作的模板，那麼 Journal 就會壞掉了。

不，這不對。為什嗎？很簡單，因為同樣的 128位 ID 將會用來指定同一個錯誤/條件/項目類型，不管來源是什麼。比如同樣的 128位 ID 將會用來標識“在塊裝置上存在壞扇區”，而不管是哪個裝置或磁碟機產生了這個訊息。如果使用者態軟體需要在不同的服務、驅動或裝置之間區分開 Journal 項的話，請使用其他額外的匹配服務/裝置/驅動的 Journal 資訊域。

不過從另一個角度講，您指出的實際上是個好事情。我們特別鼓勵人們在他們的軟體中重用訊息 ID，而不是創造新的。

但是 printf()/printk() 格式化字串是標識訊息類型的更好選擇！

現實並不是這樣的。格式化字串到頭來不過只是人類語言的模板。將人類語言用於訊息類型識別是不可靠的：每個修正的錯誤拼字都會影響訊息類型，並且導致 Journal 用戶端識別訊息錯誤。每次對一個 Journal 訊息進行擴充或者重寫的時候，將會導致 ABI 破壞。讓人類語言變為 ABI 是致命的錯誤。事實上，將所有訊息類型變為 ABI 的方式在經典的Regex匹配條件下風險很大。OTOH 訊息標識可以在改變人類語言字串時保持不變，因此很好的將 ABI 和人類語言分割開了。

你們一點兒都不懂！你們應該使用原始碼檔案名稱和位置作為訊息的標識符！

這並不可行，因為這將使原始碼位置變為 ABI：問一次開發人員在標頭檔中增加一行將導致全部訊息 ID 的改變。這將是個大問題。

誰會來組織和管理 UUID 的命名空間並產生 UUID？Who would organize and manage the UUID namespace and generate UUIDs? 認真點兒，我們不需要更多官僚機制的人！

128 位隨機 ID 的好處之一就是它的命名空間並不需要管理。所有人都可以從 /proc/sys/kernel/random/uuid 裡取出一個隨機 UUID 為他所用。只要需要，開發人員可以產生任意多的 UUID 而不需要詢問任意集中管理體制。UUID 允許我們擁有一個共同點的命名空間而無需官僚機制。

但是 UUID？你是認真的嗎？你是哪個星球來的！？人人都知道像 LANANA 這樣的中介是為應用程式指定全球唯一訊息標識 ID 的理想選擇！

Linux 並不是一個孤島。我們需要在 Journal 中與其他基礎架構中所使用訊息 ID 無縫整合起來。因此我們選擇了有用途的並且已經在他處實踐過的。同樣，UUID 只不過是為了無需集中管理的唯一識別碼。為什麼要在沒必要的時候選擇一個人手不足的官僚的集中註冊中心的？

喏，你應該使用逆序的網域名稱表示訊息類型，像 Java 一樣！

實質上，比較字串要比比較固定長度的 ID 更加複雜。並且，實事求是的說這不能解決命名空間的問題，因為估計有 90% 的訊息類型將在同個命名空間內：org.freedesktop resp. org.kernel.

但是 ASN.1 OID 可以成為很好的訊息類型區分符！

兄弟，沒搞錯吧？

現在我有了更好的主意，不如用 URL 做為類型 ID 吧？

實際上相比逆序網域名稱的方式它並未好多少，不是嗎？

但是如果你們在每個項目上都要產生一個 UUID 的話，很快便會窮盡我的熵池的！

再度一遍博文，很顯然您並沒有仔細閱讀。 128 位的訊息 ID 是由開發人員在開發過程中指定的，並不是在運行時。大多數項目在整個開發過程中幾乎不可能產生超過 30 個，這個數量哪怕在 10 年前的機器的熵池中都是微不足道的。

你們這些使用者態的小屁孩們，先是強迫我在系統中使用 20 個 CPU 進程分組，現在又要強迫我在系統中使用噁心的 UUID?

先不談我們並沒有強迫您使用 20 個進程分組的事實，您幾乎肯定已經在使用 UUID 了，因為您的檔案系統是在啟動過程中依據 UUID 載入的。將這些當作是實現的具體細節，而您並不喜歡它，那麼您就沒必要在訊息中添加它。影響的只是訊息無法被再度識別，除非使用極度複雜的Regex。不過或許這就是您想要的？無論怎樣，我們沒有強迫任何人做任何事。

所以你們是依照發送使用者的 ID 來分割 Journal 項目的了。那麼你怎麼能保證使用者不會偽裝身份呢？

幸運的是，Linux 核心支援 SCM_CREDENTIALS，可以提供我們無法偽造的訊息寄件者資訊。

Journal 檔案格式會標準化嗎？哪裡可以找到磁碟上資料結構的說明？

截至目前我們還沒有打算要將格式其標準化，保留在需要時進行變更的權力。我們會逐步完善磁碟上格式的文檔，但是目前我們不希望能有程式直接讀取、寫入和修改 Journal 檔案。對其的訪問可以通過一個共用庫和命令列程式實現。(不過再一次，這是自由軟體，您隨時可以閱讀原始碼！)

為什麼你們這些人又搞重複發明？為什麼不只把你們想要的增加到已有的 syslog？如果您只想清理日誌格式的話，syslog 足夠了。

有些情況下改進現有方案是一種方式，但是當需要的變化太大時，有正確的原因並且對以前解決方案提供了良好的相容性的重新發明卻是更好的選擇。我們相信我們有著正確的原因，並且我們在努力提供最大可能的相容性。

不，僅僅修複日誌格式沒法帶來很多變革。不僅無法實現最基本的二進位檔案或敏感的結構化日誌，也沒有索引或者存取控制。

是不是 Journal 將完全拋棄 syslog ？

不，首先，syslog API syslog(3) 作為寫入日誌的第一層級介面被支援，並且將持續用作主要的簡單文本日誌 API。但是只要中繼資料(特別是二進位中繼資料)被加入到條目中，便會轉而使用原生的 Journal API。

其次，Journal 是個全新的產物。從另一個方面說，Syslog 是一個工業標準(儘管是定義的相當孱弱，日誌格式幾乎都沒有統一)，並且被廣泛接受，存在於為數眾多的作業系統、應用程式和裝置中。因此，syslog 依然是很重要的並且將繼續存在於許多安裝配置中。Journal 守護進程並不使用 RFC syslog 協議，將來也不太可能會。當需要一個 syslog 相容協議的地方，依然需要使用經典的 syslog 實現方案。為了保證此項工作，我們確保 Journal 的實現可以和本地的 syslog 守護進程協作，且將需要的訊息轉寄給 syslog，使其可以像如同沒有 journald 中介一般的工作。

需要您的加入！

在決定這個設計之前，我們瞭解一些高負荷的日誌使用者，包括那些擁有超過 100 台活躍主機的使用者。我們也和一些可能成為主要 Journal 使用者的工程師聊過。我們對於使用慣例和擴充性問題尤其感興趣。但是，每一個安裝配置都有自己的需求，因此，如果您在上面的設計描述中看到了某個用於您特定需要的重要功能沒有實現的話，我們希望您能和我們去的聯絡。上面的設計著重於日誌記錄的底層。目前我們並不負責特定的 UI，所以如果有這方面的需求話請稍候再留下意見。另外，現在還沒到聖誕節，因此我們無法實現所有願望(請不要失望)，但是我們很在意的去瞭解它們，甚至可以保證至少我們會去考慮它們！先謝過了！

英文原文

訊息來源：Phoronix