1、性能分析
2、關於收集日志的選擇：logstash/filter
3、Logstash的優化相關配置
4、引入Redis的相關問題
5、Elasticsearch節點優化配置
6、性能檢查
1、性能分析
服務器硬件Linux：****1cpu4GRAM
假設每條日志250Byte。
分析：
①logstash-Linux：1cpu 4GRAM
- 每秒500條日志；
- 去掉ruby每秒660條日志；
- 去掉grok后每秒1000條數據。
②filebeat-Linux：1cpu 4GRAM
- 每秒2500-3500條數據；
- 每天每台機器可處理：24h60min60sec* 3000*250Byte=64,800,000,000Bytes，約64G。
③瓶頸在logstash從Redis中取數據存入ES，開啟一個logstash，每秒約處理6000條數據；開啟兩個logstash，每秒約處理10000條數據（cpu已基本跑滿）；
④logstash的啟動過程占用大量系統資源，因為腳本中要檢查java、ruby以及其他環境變量，啟動后資源占用會恢復到正常狀態。
2、關於收集日志的選擇：****logstash/filter
沒有原則要求使用filebeat或logstash，兩者作為shipper的功能是一樣的。
區別在於：
- logstash由於集成了眾多插件，如grok、ruby，所以相比beat是重量級的；
- logstash啟動后占用資源更多，如果硬件資源足夠則無需考慮二者差異；
- logstash基於JVM，支持跨平台；而beat使用golang編寫，AIX不支持；
- AIX 64bit平台上需要安裝jdk（jre） 1.7 32bit，64bit的不支持；
- filebeat可以直接輸入到ES，但是系統中存在logstash直接輸入到ES的情況，這將造成不同的索引類型造成檢索復雜，最好統一輸入到els 的源。
總結：
logstash/filter總之各有千秋，但是我推薦選擇：在每個需要收集的日志服務器上配置filebeat，因為輕量級，用於收集日志；再統一輸出給logstash，做對日志的處理；最后統一由logstash輸出給es。
3、logstash的優化相關配置
可以優化的參數，可根據自己的硬件進行優化配置：
①pipeline線程數，官方建議是等於CPU內核數
- 默認配置 ---> pipeline.workers: 2；
- 可優化為 ---> pipeline.workers: CPU內核數（或幾倍CPU內核數）。
②實際output時的線程數
- 默認配置 ---> pipeline.output.workers: 1；
- 可優化為 ---> pipeline.output.workers: 不超過pipeline線程數。
③每次發送的事件數
- 默認配置 ---> pipeline.batch.size: 125；
- 可優化為 ---> pipeline.batch.size: 1000。
④發送延時
- 默認配置 ---> pipeline.batch.delay: 5；
- 可優化為 ---> pipeline.batch.size: 10。
總結：
- 通過設置-w參數指定pipeline worker數量，也可直接修改配置文件logstash.yml。這會提高filter和output的線程數，如果需要的話，將其設置為cpu核心數的幾倍是安全的，線程在I/O上是空閑的。
- 默認每個輸出在一個pipeline worker線程上活動，可以在輸出output中設置workers設置，不要將該值設置大於pipeline worker數。
- 還可以設置輸出的batch_size數，例如ES輸出與batch size一致。
- filter設置multiline后，pipline worker會自動將為1，如果使用filebeat，建議在beat中就使用multiline，如果使用logstash作為shipper，建議在input中設置multiline，不要在filter中設置multiline。
Logstash中的JVM配置文件：
Logstash是一個基於Java開發的程序，需要運行在JVM中，可以通過配置jvm.options來針對JVM進行設定。比如內存的最大最小、垃圾清理機制等等。JVM的內存分配不能太大不能太小，太大會拖慢操作系統。太小導致無法啟動。默認如下：
- Xms256m#最小使用內存；
- Xmx1g#最大使用內存。
4、引入Redis的相關問題
filebeat可以直接輸入到logstash（indexer），但logstash沒有存儲功能，如果需要重啟需要先停所有連入的beat，再停logstash，造成運維麻煩；另外如果logstash發生異常則會丟失數據；引入Redis作為數據緩沖池，當logstash異常停止后可以從Redis的客戶端看到數據緩存在Redis中；
Redis可以使用list(最長支持4,294,967,295條)或發布訂閱存儲模式；
Redis做ELK緩沖隊列的優化：
-
bind 0.0.0.0 #不要監聽本地端口；
-
requirepass ilinux.io #加密碼，為了安全運行；
-
只做隊列，沒必要持久存儲，把所有持久化功能關掉：
快照（RDB文件）和追加式文件（AOF文件），性能更好；
save "" 禁用快照；
appendonly no 關閉RDB。
-
把內存的淘汰策略關掉，把內存空間最大
maxmemory 0 #maxmemory為0的時候表示我們對Redis的內存使用沒有限制。
5、Elasticsearch節點優化配置
服務器硬件配置，OS參數：
1）/etc/sysctl.conf 配置
# vim /etc/sysctl.confvm.swappiness = 1 #ES 推薦將此參數設置為 1，大幅降低 swap 分區的大小，強制最大程度的使用內存，注意，這里不要設置為 0, 這會很可能會造成 OOMnet.core.somaxconn = 65535 #定義了每個端口最大的監聽隊列的長度vm.max_map_count= 262144 #限制一個進程可以擁有的VMA(虛擬內存區域)的數量。虛擬內存區域是一個連續的虛擬地址空間區域。當VMA 的數量超過這個值，OOMfs.file-max = 518144 #設置 Linux 內核分配的文件句柄的最大數量# sysctl -p #生效一下
2）limits.conf 配置
# vim /etc/security/limits.confelasticsearch soft nofile 65535elasticsearch hard nofile 65535elasticsearch soft memlock unlimitedelasticsearch hard memlock unlimited
3）為了使以上參數永久生效，還要設置兩個地方：
# vim /etc/pam.d/common-session-noninteractive# vim /etc/pam.d/common-session
添加如下屬性：
session required pam_limits.so
可能需重啟后生效。
Elasticsearch中的JVM配置文件：
-Xms2g
-Xmx2g
- 將最小堆大小（Xms）和最大堆大小（Xmx）設置為彼此相等。
- Elasticsearch可用的堆越多，可用於緩存的內存就越多。但請注意，太多的堆可能會使您長時間垃圾收集暫停。
- 設置Xmx為不超過物理RAM的50％，以確保有足夠的物理內存留給內核文件系統緩存。
- 不要設置Xmx為JVM用於壓縮對象指針的臨界值以上；確切的截止值有所不同，但接近32 GB。不要超過32G，如果空間大，多跑幾個實例，不要讓一個實例太大內存。
Elasticsearch配置文件優化參數：
1）主配置文件
# vim elasticsearch.ymlbootstrap.memory_lock: true #鎖住內存，不使用swap#緩存、線程等優化如下bootstrap.mlockall: truetransport.tcp.compress: trueindices.fielddata.cache.size: 40%indices.cache.filter.size: 30%indices.cache.filter.terms.size: 1024mbthreadpool: search: type: cached size: 100 queue_size: 2000
2）設置環境變量
# vim /etc/profile.d/elasticsearch.sh export ES_HE AP _SIZE=2g #Heap Size不超過物理內存的一半，且小於32G。
集群的優化（我未使用集群）：
- ES是分布式存儲，當設置同樣的cluster.name后會自動發現並加入集群；
- 集群會自動選舉一個master，當master宕機后重新選舉；
- 為防止"腦裂"，集群中個數最好為奇數個；
- 為有效管理節點，可關閉廣播discovery. zen.ping.multicast.enabled: false，並設置單播節點組discovery.zen.ping.unicast.hosts: ["ip1", "ip2", "ip3"]。
6、性能的檢查
檢查輸入和輸出的性能：
Logstash和其連接的服務運行速度一致，它可以和輸入、輸出的速度一樣快。
檢查系統參數：
1）CPU
- 注意CPU是否過載。在Linux/Unix系統中可以使用top-H查看進程參數以及總計。
- 如果CPU使用過高，直接跳到檢查JVM堆的章節並檢查Logstash worker設置。
2）Memory
- 注意Logstash是運行在Java虛擬機中的，所以它只會用到你分配給它的最大內存。
- 檢查其他應用使用大量內存的情況，這將造成Logstash使用硬盤swap，這種情況會在應用占用內存超出物理內存范圍時。
3）I/O監控磁盤I/O檢查磁盤飽和度
- 使用Logstash plugin（例如使用文件輸出）磁盤會發生飽和。
- 當發生大量錯誤，Logstash生成大量錯誤日志時磁盤也會發生飽和。
- 在Linux中，可使用iostat，dstat或者其他命令監控磁盤I/O。
4）監控網絡I/O
- 當使用大量網絡操作的input、output時，會導致網絡飽和。
- 在Linux中可使用dstat或iftop監控網絡情況。
檢查JVM heap：
- heap設置太小會導致CPU使用率過高，這是因為JVM的垃圾回收機制導致的。
- 一個快速檢查該設置的方法是將heap設置為兩倍大小然后檢測性能改進。不要將heap設置超過物理內存大小，保留至少1G內存給操作系統和其他進程。
- 你可以使用類似jmap命令行或VisualVM更加精確的計算JVM heap。