容器時代的日誌處理
摘要：
這是對目前接觸到的日誌處理的一個總結
日誌收集
以前的架構一般是：
app -> stdout/stderr -> 重定向到檔案 -> 定期將檔案整理到某處
後來先進一點：
app -> stdout/stderr -> 重定向到檔案 ->...
這是對目前接觸到的日誌處理的一個總結
日誌收集
以前的架構一般是：
app -> stdout/stderr -> 重定向到檔案 -> 定期將檔案整理到某處
後來先進一點：
app -> stdout/stderr -> 重定向到檔案 -> logstash等檔案處理程式 -> | redis集中收發 | -> logstash收取到某處
再後來：
app -> stdout/stderr -> Docker -> fluentd -> fluentd收取到某處
日誌搜尋
以前一般都是grep，在沒有集中處理日誌的時候，可能還需要配合ansible等工具，多處grep。缺點是得手工執行，另外資料備份是個問題。
現在一般都是ELK鎮場，logstash收到日誌之後，順便解析一下，丟到ElasticSearch中，由Kibana來搜尋。
- 優點是：ElasticSearch一般會配上replica，日誌不會丟掉 - 缺點是：正是因為replica，吃硬碟。另外還有一個缺點，logstash ruby寫的，慢。所以現在收集這一步，改用filebeat了。
日誌歸檔
- 現在都上雲了，用的雲服務進行歸檔儲存。當然，如果要用的日誌（比如最近一個月的），還是會丟到hdfs等處。
沒嘗試過的
- NSQ/Kafka：很多公司用這兩個來傳遞日誌。不過暫時還沒嘗試過，沒有那麼大量級。