創作人：朱祝元
審稿人：朱永生
技術架構
- 實體部署：
1master；5 Data；1 Logstash+kibana；3 kafka 3 主 3 從交叉部署
- 應用架構：
項目采用 springboot 作為基礎架構開發分布式應用；
- 實施方案：
通過每個應用伺服器上部署 filebeat，上傳到 kafka；由 kafka 分發消息到 logstash； Logstatsh 寫入日志到 Elasticsearch 叢集；
- 應用目标：
收集 50 台機器的日志，可以及時發現日志中的錯誤日志以及日志對應的上下文。
日志解決方案的演進
階段一、項目上線一切剛開始
每個程式員通過 ssh 将資料 copy 到堡壘機。然後把資料從堡壘機下載下傳到本地處理資料，分析日志；
遇到的問題
- 下載下傳日志到本地，檔案太大難以處理：每個日志檔案大概 500M，這種體量，Windows 上任何文本工具打開都很吃力，還要下載下傳多個檔案，下載下傳速率也有很大影響；
- 遠端伺服器上查找，伺服器關聯多：同一個服務部署的有多個節點，那麼找一個需要的日志就要多個伺服器都執行類似于下面的指令來查找蛛絲馬迹：
more INFO-2020-12-17.0.log |grep -C 5 'scanRecord' 如果遇到關聯的服務日志查詢，還會讓事情的複雜度變的更高。
階段二、測試環境建立ELK環境
實踐過程：
剛開始的時候 1 master+ 3 data；有一個普遍的認知就是，單個 Elasticsearch data 節點的每個分片資料大小：30GB-50GB。因為我們的系統是 4 核 8G 的配置，是以我們采用了下限，也就是每個 Shard 30G。這樣子運作了 3 個月。
采用政策：
按天産生 index，一些 IP，APP 應用名等不需要分詞查詢的字段都禁用了 index (這樣可以節省磁盤)，隻保留一周的日志回溯，3 天的日志 alive 查詢，4 天的日志 close。一周以上的 index 直接 delete ，晚上 12點 定時執行 forcemerge。
遇到瓶頸，系統擴容：
因為随着系統票件量的提升，日志資料逐漸增加。慢慢就會感到系統查詢非常慢，磁盤空間慢慢的無法做到保留一周日志回溯，立馬進行了系統擴容。
擴容後：
系統會自動進行索引分片重配置設定，會把分片均勻的分布到所有的節點上。比如剛開始 3 台 data 節點 6 個分片，平均每個機器會有 2 個分片，那麼系統擴容一倍後，會變成 6 個 data 節點，那麼這 6 個分片，會自動平均分布到 6 個 data 節點上。每個節點有一個 shard。
擴容步驟
修改配置檔案
主要修改所有 Elasticsearch 節點的
elasticsearch.yml
中的 IP 位址，如果一個機器上部署多個節點，記得将端口号加上。
一個機器上部署三個節點執行個體
discovery.zen.ping.unicast.hosts:["192.168.207.43:9300","192.168.207.43:9301","192.168.207.43:9302"] 配合的屬性：
http.port: 9202
transport.tcp.port: 9302 分批啟動ES
- 啟動順序：先啟動 master 節點，再啟動其他類型的節點。
- 啟動指令：
nohup ./bin/elasticsearch > nohup.out 2>&1 &
心路旅程
1、資源并不是充裕的。可以使用 Stack Monitoring 上的磁盤監控功能，随時監控磁盤的剩餘空間。
并且，可以在資料可靠性要求允許的情況下，在索引生命周期管理中，把冷資料的
index.number_of_replicas
設定為 0。
2、最佳的 Kafka 分發效率。如果使用了 Kafka，注意 Kafka 的 Partition 與 Topic 的配置關系，通常來說 Logstash 中 Worker 的數量應該等于或大于 Kafka Partition 的數量，以便于達到最優的分發效率
3、SSD 的取舍。資料量過大。磁盤 IO 也真的能成為瓶頸，對比叢集沒有資料和叢集資料量達到磁盤容量的50%的時候，寫入的速率差别很大。業務需求需要實時查詢的場景能上 SSD 就上SSD。
創作人簡介：
朱祝元，從事 JAVA 企業級應用開發十餘年，獲得 pmp，acp 項目管理認證。有紮實
的企業級開發經驗，以及分布式應用開發架構經驗，參與了千萬級的複雜項目資料場景
業務處理。