[譯] 2017年日誌生態系統概述

• 原文地址：An Overview of the Logging Ecosystem in 2017
• 原文做者：Matthew Setter
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：TanJianCheng
• 校對者：tmpbook Yuuoniy

2017年日誌生態系統概述

日誌功能，對於現代計算機來講是基本的組件。它能夠幫助開發者調試應用程序，系統管理員和開發運營人員修復服務器中斷的緣由。所以，日誌記錄提供瞭解決問題的信息和上下文環境是相當重要的，不管是在（問題）發生時仍是從歷史上下文中排查問題。

但像計算中的任何東西同樣，日誌的狀態從未停滯不前。現有的概念會過期而後被新的概念所替換，而其餘的一些想法則變成永恆 - 有時會持續好幾年。一樣的模式也適用於工具和服務，不管是商業仍是開源，線上服務或者線下服務。

因此如今咱們處於什麼位置？如今流行的趨勢，工具和哲學是什麼？爲何它們流行？很好，咱們將經過日誌生態的三個元素去探究在2017年年中日誌行業處於什麼位置。

我會具體地討論如下幾個值得注意的地方：

• 哲學
• 最佳方案
• 服務和工具選項

在咱們進入正題以前，我先清楚地說明：我首先將我本身立足於一名開發人員的角度，其次是系統管理員和運營。因此，個人觀點和文中我做出的選擇是有根據地得出結論。請記住這一點。

「目前日誌流行的趨勢，工具和文化是什麼和它們流行的緣由是什麼？」 來自 @settermjd

咱們能夠開始啦。

日誌系統的哲學

我想說的第一部分是日誌原理。在這裏，我會說明兩個哲學：日誌存儲和日誌文化。

日誌記錄應該存在哪裏和如何被保存？

日誌文件是應該直接保存在你組織內部本身管理的服務呢？仍是你使用像 Loggly 這樣的 SaaS，或者存儲數據到其它第三方工具 稍後咱們會介紹 之一？

按照個人理解，最主要的區別是安全性和數據的敏感性的問題。你的組織裏有什麼數據是處於私有狀態的？

若是真的有，你最好本身去研究一種解決方案來記錄日誌，例如 Apache Kafka，或者 一個易伸縮 (formerly ELK) 堆 。若是你的數據不是特別的敏感的話，像 Loggly，Graylog，SumoLogic，和 ElasticSearch 這樣的商業託管解決方案多是一種更好的選擇。

另一種彷佛熱門的談論 在 Hacker News 認爲是日誌效率問題。具體談論的是，咱們是否努力創建和管理內部的日誌解決方案，像基於堆棧的實現方式來提升效率？或者說託管給現成的廠商服務會更有效率？

歷來沒有一個明確，萬全的答案來回答這樣的問題。我一直認爲最統一的解釋就是『看狀況而定』。任何組織和應用都是獨一無二的。對於一個問題有效的解決方案不必定適用於另一個。一我的可能擁有許多資源和經驗能夠用於分配任務。但另一我的不必定有。

因此在2017年，日誌數據如何被存儲這個問題仍然是在日誌生態系統當中的關鍵問題。

sidecar 應用

這是一個被稱爲 sidecar應用 的嶄新（至少對於我來講）概念。若是你之前沒有據說過，那麼告訴你它是與部署容器類應用相關的，一樣地它很是適合基於容器的部署。

Garland Kan 在 Loggly 中把 sidercar 簡潔地描述爲:

將一個應用程序容器和日誌容器進行結合的理念。

他們經過這種方式描述它，Voxxed 提供了更加詳細的解釋：

一個　sidecar　應用是被部署在每個已經開發或者部署服務器/集羣實例的微服務的旁邊。它是概念上依附着"父母"服務，就像三輪摩托車的邊座位依附着三輪摩托車同樣 - 所以而得名。sidecar做爲第二進程和你的程序一塊兒運行並經過暴露相似 REST 的 API 接口(如 HTTP 的 REST )來提供‘平臺基礎設施功能’。

在日誌的上下文環境中，一個額外的容器被加載進了堆空間，同時堆空間是日誌應用存儲的地方以及能夠轉發日誌記錄到像 LogEntries 和 Splunk 外部服務。從個人理解，雖然 sidecar 能適合較小的應用程序，可是比較困難去有效地測量。總的來講，這是很是有趣的概念。

日誌的文化

如今讓咱們看看文化 - 一個具備主動性，很是重要的方面。直接點說，讓我印象深入 來自 Stackify 的一個引用，他是這麼說：

…咱們已經創建了一個『日誌文化』…

我發現這是近年來最好的發展之一，由於沒有一個支持的文化，想法和概念的話，它有可能只是暫時興起。在過去的幾年，當咱們測試在時候，我認爲咱們都接觸過。一開始社區文化老是起很大的做用。可是若是沒有適當的文化支持，當其餘方面的壓力和最後的期限開始堆積的時候，它很快將會被淘汰。

在這篇文章，Stackify 繼續說：

[日誌的文化]開始完成這些目標：

記錄全部的東西。儘量地多記錄一些有關聯性的，有上下文信息的日誌記錄。更加的智能化而不是更復雜。鞏固和彙集咱們的日誌記錄到一箇中心區域，開放給全部開發者和便於提取。並且，分析異常的日誌信息找到新的途徑，主動去優化產品。

這段話有一些很優秀的觀點，其中兩個比較特別的見解值得去了解。

儘量多記錄日誌

與前幾年我所看到的和所經歷的相反，這個表達在於多記錄日誌，至少 -- 這些信息都是有連續性的。這個說法與 Sumologic 在 2017 年 4 月寫的日誌所說的緊密相連：

你的日誌記錄就應該像是在講一個故事。

對於我來講，這種作法是很是有意思並且可讓你看到結果的發展。

當我不肯定咱們是否應該記錄下它們的理由，咱們擁有越多（具備上下文聯繫）信息，對咱們處理那些突發的問題就會越有利。

保存在一箇中心區域，對全部開發者都開放

每一個人均可以集中使用這些日誌信息，是另一個使人振奮的發展，甚至看見愈發的強大。

當信息被保存在一箇中心區域，它能夠更容易發揮做用。每一個人均可以去訪問它 - 查看它 - 這樣作提升了肯定日誌內容的責任，以及更快的解決問題的須要。若是信息被隱藏起來，那麼問題更容易被掩蓋或者被埋葬。

我願意相信當這兩個理念被實現（儘量多記錄和記錄在中心位置），那麼咱們的應用的質量會提升和故障會減小，這樣會極大知足用戶和開發體驗。

Sign up

最佳方案

如今我想考慮今年我從學習中得出的最佳方案中的一個重點問題：咱們創做日誌內容是偏向於可讀性或利於高效解析?

彷佛人類更擅長於處理沒有邏輯，沒有組合或者沒有擁有標準格式的數據，計算機卻不能。相反，人類不擅長處理大量的數據可是計算機卻能夠。因此，咱們面臨着一個挑戰：咱們建立日誌是在以人爲優，便於大衆工做仍是以有利於電腦程序處理爲優先條件，其次是使之具備可讀性？

我發現，除非你只記錄少許的信息，不然咱們最好專一於處理效率之上，儘量考慮執行環境而不是可讀性。

可是一個有效率，內容豐富的日誌目錄應該是怎麼樣的？ Dan Reichart（從 SumoLogic）提供了，一個虛構的機票預訂服務，做爲一個例子：

2017-04-1009:50:32-0700-dan12345-10.0.24.123-GET- /checkout/flights/ -credit.payments.io-Success-2-241.98複製代碼

簡而言之，入口的每個元素都被 " - " 分隔開,排序後獲得如下結果：

1. 日誌時間戳
2. 購物者的用戶名
3. 用戶的IP地址
4. 請求的方法
5. 請求的資源
6. 請求的網管或者路徑
7. 請求的狀態
8. 機票購買數量
9. 機票合計

若是咱們僅有這些信息，那麼咱們只能知道部分的故事。可是若是經過保存全部的信息，而這些信息能夠很好的被壓縮存儲，那麼咱們處於一個咱們獲得解決問題所需信息的位置。這些日誌記錄是簡潔的，具備可讀性，像講述一個故事和聽從一個標準，可預測的模式。還有其餘的表達方式，這只是其中之一。

服務 & 工具的選項

如今，讓咱們經過觀察一些目前提供日誌服務市場的廠商來完成這個課題。這些當中是託管的Saas和自我託管的解決方案的混合。其中一些使人注意，目前愈來愈強大的廠商已經存在好些時候了。它們包括如下公司像 Loggly，Graylog，Splunk，ElasticSearch， LogEntries， Logz.io，LogStash，SumoLogic，和 Retrace 。

雖然它們都有具備像搜索和分析，主動檢測，建立結構化和非結構化數據，自定義解析規則，和實時指示界面等特徵，可是他們還在建立本身的核心功能，並擴展它們產品和特徵集。

它們的訂價模式也有很大的不一樣，包括免費的選擇版本，價格在90美圓左右的標準計劃和高達200美圓的企業套餐。

但在2017年，商業化不會是惟一的選擇。一些開源工具也逐漸成熟起來。事實上，Linux基金會第三季度的 開放雲報告指南 中有兩個比較引人注意：Fluentd 統一日誌層的數據收集器，和 LogStash，服務端數據處理管道。其餘值得考慮的開源工具是 syslog-ng， LOGalyze，和 Apache Flume。

鑑於此，取決於你的經驗，需求和預算，今年你的選擇是很是充足的。將來將會有大量的選項可讓你選擇到最符合你的需求的開源工具。

結論

咱們總結了在2017關於日誌系統大致上幾個關鍵的因素。

咱們瞭解過了目前的哲理，例如日誌記錄應該存在哪裏以及如何被存儲，和 sidercar 應用的概念。咱們討論過了在一個組織內日誌記錄的文化對於日誌記錄的成功是多麼重要。還有更多上下文的日誌記錄是如何比少的要更好。最後咱們瞭解了幾個市場上關鍵廠商。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。