日志系統
日志系統介紹
基於公司業務逐漸遷移到Kubernetes環境的現實需求。對日志系統的選型應按照對Kubernetes環境的要求進行。
應用程序和系統日志可以幫助我們了解集群內部的運行情況，日志對於我們調試問題和監視集群情況也是非常有用的。而且大部分的應用都會有日志記錄，對於傳統的應用大部分都會寫入到本地的日志文件之中。對於容器化應用程序來說則更簡單，只需要將日志信息寫入到 stdout 和 stderr 即可，容器默認情況下就會把這些日志輸出到宿主機上的一個 JSON 文件之中，同樣也可以通過 docker logs 或者 kubectl logs 來查看到對應的日志信息。
但是，通常來說容器引擎或運行時提供的功能不足以記錄完整的日志信息，比如，如果容器崩潰了、Pod 被驅逐了或者節點掛掉了，我們仍然也希望訪問應用程序的日志。所以，日志系統應該獨立於節點、Pod 或容器的生命周期，這種設計方式被稱為 cluster-level-logging，即完全獨立於 Kubernetes 系統，需要自己提供單獨的日志后端存儲、分析和查詢工具。
一套完成的日志系統應該包含：數據采集，存儲、搜索&分析，可視化&管理三部分。
日志系統選型
對於存儲、搜索&分析這部分選擇的組件是Elasticsearch。Elasticsearch 是一個實時的、分布式的可擴展的搜索引擎，允許進行全文、結構化搜索，它通常用於索引和搜索大量日志數據，也可用於搜索許多不同類型的文檔。使用到的最著名場景就是GitHub。
對於日志系統最主要的調研對象在數據收集和可視化組件兩部分。
日志采集
可選組件為logstash、filebeat、fluentd。
優缺點對比
Logstash <-- java
Logstash是一個開源數據收集引擎，具有實時管道功能。Logstash可以動態地將來自不同數據源的數據統一起來，並將數據標准化到你所選擇的目的地。
優勢
Logstash 主要的有點就是它的靈活性，主要因為它有很多插件，詳細的文檔以及直白的配置格式讓它可以在多種場景下應用。我們基本上可以在網上找到很多資源，幾乎可以處理任何問題。
劣勢
Logstash 致命的問題是它的性能以及資源消耗(默認的堆大小是 1GB)。盡管它的性能在近幾年已經有很大提升，與它的替代者們相比還是要慢很多的。這里有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比。它在大數據量的情況下會是個問題。
另一個問題是它目前不支持緩存，目前的典型替代方案是將 Redis 或 Kafka 作為中心緩沖池：
典型應用場景
因為 Logstash 自身的靈活性以及網絡上豐富的資料，Logstash 適用於原型驗證階段使用，或者解析非常的復雜的時候。在不考慮服務器資源的情況下，如果服務器的性能足夠好，也可以為每台服務器安裝 Logstash 。也不需要使用緩沖，因為文件自身就有緩沖的行為，而 Logstash 也會記住上次處理的位置。
如果服務器性能較差，並不推薦為每個服務器安裝 Logstash ，這樣就需要一個輕量的日志傳輸工具，將數據從服務器端經由一個或多個 Logstash 中心服務器傳輸到 Elasticsearch：
隨着日志項目的推進，可能會因為性能或代價的問題，需要調整日志傳輸的方式(log shipper)。當判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有着准確的估計，這也決定了需要為 Logstash 投入多少硬件資源。
Filebeat <-- Go
作為 Beats 家族的一員，Filebeat 是一個輕量級的日志傳輸工具，它的存在正彌補了 Logstash 的缺點：Filebeat 作為一個輕量級的日志傳輸工具可以將日志推送到中心 Logstash。
在版本 5.x 中，Elasticsearch 具有解析的能力(像 Logstash 過濾器)— Ingest。這也就意味着可以將數據直接用 Filebeat 推送到 Elasticsearch，並讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩沖，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移，如果需要緩沖(例如，不希望將日志服務器的文件系統填滿)，可以使用 Redis/Kafka，因為 Filebeat 可以與它們進行通信。
優勢
Filebeat 只是一個二進制文件沒有任何依賴。它占用資源極少，盡管它還十分年輕，正式因為它簡單，所以幾乎沒有什么可以出錯的地方，所以它的可靠性還是很高的。它也為我們提供了很多可以調節的點，例如：它以何種方式搜索新的文件，以及當文件有一段時間沒有發生變化時，何時選擇關閉文件句柄。
劣勢
Filebeat 的應用范圍十分有限，所以在某些場景下我們會碰到問題。例如，如果使用 Logstash 作為下游管道，我們同樣會遇到性能問題。正因為如此，Filebeat 的范圍在擴大。開始時，它只能將日志發送到 Logstash 和 Elasticsearch，而現在它可以將日志發送給 Kafka 和 Redis，在 5.x 版本中，它還具備過濾的能力。
典型應用場景
Filebeat 在解決某些特定的問題時：日志存於文件，我們希望將日志直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去(grep)它們或者日志是存於 JSON 格式(Filebeat 可以解析 JSON)。或者如果打算使用 Elasticsearch 的 Ingest 功能對日志進行解析和豐富。
將日志發送到 Kafka/Redis。所以另外一個傳輸工具(例如，Logstash 或自定義的 Kafka 消費者)可以進一步豐富和轉發。這里假設選擇的下游傳輸工具能夠滿足我們對功能和性能的要求。
Fluentd <-- Ruby
Fluentd 創建的初衷主要是盡可能的使用 JSON 作為日志輸出，所以傳輸工具及其下游的傳輸線不需要猜測子字符串里面各個字段的類型。這樣，它為幾乎所有的語言都提供庫，這也意味着，我們可以將它插入到我們自定義的程序中。
優勢
和多數 Logstash 插件一樣，Fluentd 插件是用 Ruby 語言開發的非常易於編寫維護。所以它數量很多，幾乎所有的源和目標存儲都有插件(各個插件的成熟度也不太一樣)。這也意味這我們可以用 Fluentd 來串聯所有的東西。
劣勢
因為在多數應用場景下，我們會通過 Fluentd 得到結構化的數據，它的靈活性並不好。但是我們仍然可以通過正則表達式，來解析非結構化的數據。盡管，性能在大多數場景下都很好，但它並不是最好的，和 syslog-ng 一樣，它的緩沖只存在與輸出端，單線程核心以及 Ruby GIL 實現的插件意味着它大的節點下性能是受限的，不過，它的資源消耗在大多數場景下是可以接受的。對於小的或者嵌入式的設備，可能需要看看 Fluent Bit，它和 Fluentd 的關系與 Filebeat 和 Logstash 之間的關系類似。
典型應用場景
Fluentd 在日志的數據源和目標存儲各種各樣時非常合適，因為它有很多插件。而且，如果大多數數據源都是自定義的應用，所以可以發現用 fluentd 的庫要比將日志庫與其他傳輸工具結合起來要容易很多。特別是在我們的應用是多種語言編寫的時候，即我們使用了多種日志庫，日志的行為也不太一樣。
結論
對上上述對比結論：
性能：filebeat < fluentd < logstash
功能：logstash < fluentd < filebeat
通過對公司業務和技術棧的對比選擇的方案為：filebeat收集日志，logstash處理日志。
可視化展示
可選組件為kibana、grafana。
組件介紹
Kibana和Grafana是兩個開源工具，能可視化和推斷大量日志數據內的趨勢。
Kibana： 是一個分析和可視化平台，它可以瀏覽、可視化存儲在Elasticsearch集群上排名靠前的日志數據，並構建儀表盤。
Grafana: 是一個開源儀表盤，主要用於大規模指標數據的可視化展現。
優缺點對比：
日志與度量
Grafana專注於根據CPU和IO利用率之類的特定指標提供時間序列圖表。Grafana無法進行數據的檢索和瀏覽。
Kibana則專注於另一方面，它運行於Elasticsearch的上層，能創建一個復雜的日志分析儀表盤。
基於角色的訪問
Kibana的儀表盤是公開的，沒有進行基於角色的訪問控制。如果需要針對多個用戶設置不同的權限級別，就得增加額外的配置Shield。
Grafana 內置的 RBA 允許你維護用戶和團隊訪問儀表盤的權限。Grafana 的富 API可能用於保存特定儀表表、創建用戶用戶和更新數據源的任務。
儀表盤靈活性
Kibana有大量內置的圖表類型，但它們的控制仍是最初的限制。
Grafana包括更多的選擇，可以更靈活地瀏覽和使用圖表。
數據源的集成
Grafana支持許多不同的存儲后端。Grafana 針對每個數據源都有一個特定的查詢編輯器，它是針對數據源所具備的特性和能力特別定制的。
Kibana 原生集成進了 ELK 棧，這使安裝極為簡單，對用戶非常友好。
結論
Grafana展示數據統計圖形，Kibana看具體數據信息；
Kibana結合Elasticsearch操作簡單集成了絕大多數ES的API，是專業的日志展示應用。
Grafana結合Elasticsearch操作復雜，對不同的應用，如nginx，tomcat 需要制作不通的json，功能不如Kibana全，Grafana只能查詢，不能進行刪改操作，不能查json。
可選方案：
elasticsearch + logstash + filebeat + kibana + kafka 【主推】
elasticsearch + logstash + filebeat + grafana + kafka 【可選】
部署方案
Kubernetes集群中的日志收集解決方案
| 編號 | 方案 | 優點 | 缺點 |
|---|---|---|---|
| 1 | node上部署一個日志收集程序 | 每個node僅需部署一個日志收集程序，消耗資源少，對應用無侵入 | 應用程序日志需要寫到標准輸出和標准錯誤輸出，不支持多行日志 |
| 2 | pod中附加一個日志收集容器 | 低耦合 | 每個pod啟動一個日志收集容器，增加資源消耗 |
| 3 | 應用程序直接推送日志 | 無需額外收集工具 | 侵入應用，增加應用復雜度 |
成果展示
Kibana:
Grafana:
這里，選擇kafka作為消息隊列，配置kafka集群，結合ELFK集群收集應用日志。那么選擇redis還是kafka作為消息隊列呢？從以下三點考慮：
生產初期，Service服務較少，訪問量較少，使用ELFK集群就可以滿足生產需求。但隨着業務量的不斷增加，日志量成倍增長，針對此情況，需要對ELK增加消息隊列，以減輕前端ES集群的壓力。
* 消息推送的可靠性：
Redis 消息推送（基於分布式 Pub/Sub）多用於實時性較高的消息推送，並不保證可靠。
Redis-Pub/Sub 斷電就會清空數據，而使用 Redis-List 作為消息推送雖然有持久化，也並非完全可靠不會丟失。
Kafka 雖然有一些延遲但保證可靠。
* 訂閱功能的分組：
Redis 發布訂閱除了表示不同的 topic 外，並不支持分組。
Kafka 中發布一個內容，多個訂閱者可以分組，同一個組里只有一個訂閱者會收到該消息，這樣可以用作負載均衡。
* 集群資源的消耗：
Redis 3.0之后個有提供集群ha機制，但是要為每個節點都配置一個或者多個從節點，從節點從主節點上面拉取數據，主節點掛了，從節點頂替上去成為主節點，但是這樣對資源比較浪費。
Kafka 作為消息隊列，能充分的運用集群資源，每個應用相當於一個topic，一個topic可擁有多個partition，並且partition能輪詢分配到每個節點上面，並且生產者生產的數據也會均勻的放到partition中，
即使上層只有1個應用kafka集群的資源也會被充分的利用到，這樣就避免了redis集群出現的數據傾斜問題，並且kafka有類似於hdfs的冗余機制，一個broker掛掉了不影響整個集群的運行。