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

野區傑西發表於2017-09-13

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
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、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章