在中心化日誌記錄一文中，我介紹了幾個工具，用於解決中心化日誌記錄的問題。但這些工具一般僅能解決這個問題的一部分， 這意味著需要綜合使用幾個工具來構建乙個健壯的解決方案。
你需要解決問題的這幾個主要方面：收集、傳輸、儲存、以及分析。某些特殊的應用場景下，也許還希望具備告警的能力。
收集應用程式以不同的方式產生日誌，一些是通過syslog，其他一些是直接寫到檔案。考慮乙個執行在linux主機上的典型web應用，在/var/log目錄會有十幾個甚至更多的日誌檔案， 如果一些應用指定日誌存放在home目錄或者其他位置，則這些目錄下也是如此。
如果你正在運營乙個基於web的應用，開發人員或者運維同事需要快速地訪問日誌資料以便對線上問題進行排錯，那麼就需要乙個能夠近乎實時監控日誌檔案變化的方案。 如果使用基於日誌拷貝的方式 — 檔案以固定的時間間隔拷貝到一台中心伺服器上，那麼僅能檢查與複製操作頻率相同的新增日誌資料。當站點已經掛掉，而你正在等待相關日誌資料的複製， 那麼一分鐘一次的 rsync cron 任務也許還不夠快。
從另外乙個角度來看，如果需要分析線下日誌資料，計算各種度量指標，或者其他批量的工作，檔案複製的策略也許正合適。
傳輸日誌資料會在多個主機上快速地累積起來。為了高效傳輸日誌資料到中心位置，並保證資料不丟失，可能需要額外的工具。
scribe、flume、heka、logstash、 chukwa、fluentd、nsq、kafka 這些框架正是被設計用於 從乙個主機到另乙個主機可靠地傳輸大量資料。雖然它們都是用於解決資料傳輸問題，但做法卻不相同。
例如，scribe、nsq 以及 kafka，要求客戶端通過它們的api記錄日誌資料， 通常，應用程式**會編寫成直接將日誌寫到這些工具中，這樣能夠減小延遲，提高可靠性。如果你需要的是中心化的日誌檔案資料，那麼就需要跟蹤(tail)日誌檔案變更， 然後將日誌資料通過這些工具各自的api流式寫入。如果產生需要收集的日誌資料的應用由你控制著，一切會高效得多。
logstash、heka、fluentd 以及 flume 則提供許多輸入源方式， 支援本機跟蹤(tailing)檔案變化並可靠地傳輸資料。對於更廣泛的日誌收集來說，是個更合適的選擇。
雖然 rsyslog和syslog-ng 通常被認為是事實上的日誌收集器，但並不是所有應用程式都使用 syslog。
儲存現在可以傳輸日誌資料了，但資料存放在哪呢？中心化的儲存系統需要能夠處理資料隨著時間的增長。每天都會增加一定量的資料儲存，資料量和產生日誌資料的主機和程序數量相關。
如何儲存依賴於以下幾個問題：
需要儲存多長時間 — 如果日誌是用於長期歸檔的目的，並且不需要即時分析，那麼 s3、aws glacier 或磁帶備份 也許是合適的選擇，因為它們對於大量資料的儲存相對比較廉價。如果僅需要幾天或者幾個月的日誌，將資料儲存到某種分布式儲存系統， 如：hdfs、cassandara、 mongodb 或elasticsearch也是不錯的。如果僅需要保留幾個小時的資料用於實時分析，使用redis也可以。
應用場景的資料量 — google一天的日誌資料量肯定遠大於acme運輸物資公司（譯註：原文是acme fishing supplies，正確的應該是acme shipping supplies）一天的日誌。 你選擇的儲存系統當資料量增大時應該允許水平擴充套件。
需要如何訪問日誌 — 某些儲存系統是適於實時甚至批量分析的。aws glacier 或磁碟備份載入乙個檔案就需要花費若干小時，如果需要訪問日誌進行產品排錯，這就不好使了。 如果計畫進行更多的互動式資料分析，將日誌資料儲存到 elasticsearch 或 hdfs 讓你能夠更加有效地使用原始資料。某些日誌資料非常龐大，就只能使用面向批量處理的框架進行分析了。這種情況下事實上的標準方案是 apache hadoop 配合 hdfs。
分析一旦日誌已經存到乙個中心化儲存平台，就需要一種方式來分析日誌。最常見的方式是定期執行乙個面向批量處理的程序。如果日誌是儲存在 hdfs 中， 那麼 hive 或 pig 相比編寫原生mapreduce任務，更易於幫助分析資料。
如果需要乙個用於分析的使用者介面，可以將解析過的日誌資料存到 elasticsearch，然後使用乙個前端方案，如 kibana 或 graylog2來查詢檢查資料。日誌解析可以通過 logstash 或 heka來處理， 應用程式也可以直接以json格式記錄日誌。這種方式允許更加實時、互動式的資料獲取，但不適於大批量的處理。
告警最後乙個元件，有時是可以錦上添花的 — 針對日誌模式或基於日誌資料計算出來的度量指標進行告警。兩種常見用法是：錯誤報告和監控。
多數日誌資料是無關緊要的，但錯誤日誌則通常說明存在問題。讓日誌系統在問題發生時給相關人員傳送郵件或通知，相比讓某個人重複地監視事件，要高效得多。 有幾種服務元件可單獨提**用錯誤日誌記錄的功能，如 sentry 或 honeybadger 。這些服務也可以聚合重複的異常， 方便你獲知錯誤發生的頻率是怎樣的。
另乙個使用案例是監控。例如，你可能有上百個web伺服器，想知道它們是否開始返回500響應狀態碼。如果可以解析web日誌檔案，根據狀態碼記錄乙個度量指標， 當度量指標超過了乙個特定的閾值就可以觸發告警。 riemann 就是被設計用於檢測這種場景的。
希望本文能提供乙個基本模型幫助你針對你的應用環境設計乙個中心化日誌記錄方案。
中心化日誌記錄架構
在中心化日誌記錄一文中，我介紹了幾個工具，用於解決中心化日誌記錄的問題。但這些工具一般僅能解決這個問題的一部分，這意味著需要綜合使用幾個工具來構建乙個健壯的解決方案。你需要解決問題的這幾個主要方面 收集 傳輸 儲存 以及分析。某些特殊的應用場景下，也許還希望具備告警的能力。收集應用程式以不同的方式產...
中心化和去中心化
中心化和去中心化 分布式的架構中，同乙個服務會部署若干服務節點，在面對具體服務請求時，怎麼決定由哪個節點來提供服務，根據實現方案分為中心化和去中心化兩種方式。中心化 在開源中介軟體codis的集群組網中，應用對快取節點的訪問都通過codis的proxy 由 來決定資料儲存到哪個節點上 這種分布式的組...
配置中心化
現實場景 傳統應用打包部署,會在不同的環境配置不同的包,如local環境,dev環境,測試環境,uat環境,生產環境分別製作不同的發布包,每個包裡環境特定配置.每一次部署都要修改配置檔案,提交審核 才能打包,非常的不方便.相信很多朋友和我一樣碰到過這種問題.如果是共用環境,由於環境問題,經常會導致乙...