如何解決ELK的實用性問題

今天就跟大家聊聊有關如何解決ELK的實用性問題，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

一、ELK實用知識點總結

1、編碼轉換問題

這個問題，主要就是中文亂碼。

input中的codec=>plain轉碼：

codec => plain {          charset => "GB2312" }

將GB2312的文本編碼，轉為UTF-8的編碼。

也可以在filebeat中實現編碼的轉換(推薦)：

filebeat.prospectors: - input_type: log   paths:     - c:\Users\Administrator\Desktop\performanceTrace.txt   encoding: GB2312

2、刪除多余日志中的多余行

if ([message] =~ "^20.*-\ task\ request,.*,start\ time.*") {   #用正則需刪除的多余行             drop {}     }

日志示例：

2018-03-20 10:44:01,523 [33]DEBUG Debug - task request,task Id:1cbb72f1-a5ea-4e73-957c-6d20e9e12a7a,start time:2018-03-20 10:43:59   #需刪除的行 -- Request String :  {"UserName":"15046699023","Pwd":"ZYjyh727","DeviceType":2,"DeviceId":"PC-20170525SADY","EquipmentNo":null,"SSID":"pc","RegisterPhones":null,"AppKey":"ab09d78e3b2c40b789ddfc81674bc24deac","Version":"2.0.5.3"} -- End -- Response String :  {"ErrorCode":0,"Success":true,"ErrorMsg":null,"Result":null,"WaitInterval":30} -- End

3、grok處理多種日志不同的行

日志示例：

2018-03-20 10:44:01,523 [33]DEBUG Debug - task request,task Id:1cbb72f1-a5ea-4e73-957c-6d20e9e12a7a,start time:2018-03-20 10:43:59 -- Request String :  {"UserName":"15046699023","Pwd":"ZYjyh727","DeviceType":2,"DeviceId":"PC-20170525SADY","EquipmentNo":null,"SSID":"pc","RegisterPhones":null,"AppKey":"ab09d78e3b2c40b789ddfc81674bc24deac","Version":"2.0.5.3"} -- End -- Response String :  {"ErrorCode":0,"Success":true,"ErrorMsg":null,"Result":null,"WaitInterval":30} -- End

在logstash filter中grok分別處理3行：

match => {     "message" => "^20.*-\ task\ request,.*,start\ time\:%{TIMESTAMP_ISO8601:RequestTime}" match => {     "message" => "^--\ Request\ String\ :\ \{\"UserName\":\"%{NUMBER:UserName:int}\",\"Pwd\":\"(?<Pwd>.*)\",\"DeviceType\":%{NUMBER:DeviceType:int},\"DeviceId\":\"(?<DeviceId>.*)\",\"EquipmentNo\":(?<EquipmentNo>.*),\"SSID\":(?<SSID>.*),\"RegisterPhones\":(?<RegisterPhones>.*),\"AppKey\":\"(?<AppKey>.*)\",\"Version\":\"(?<Version>.*)\"\}\ --\ \End.*"     } match => {     "message" => "^--\ Response\ String\ :\ \{\"ErrorCode\":%{NUMBER:ErrorCode:int},\"Success\":(?<Success>[a-z]*),\"ErrorMsg\":(?<ErrorMsg>.*),\"Result\":(?<Result>.*),\"WaitInterval\":%{NUMBER:WaitInterval:int}\}\ --\ \End.*" } ... 等多行

4、日志多行合并處理—multiline插件(重點)

示例：

①日志

2018-03-20 10:44:01,523 [33]DEBUG Debug - task request,task Id:1cbb72f1-a5ea-4e73-957c-6d20e9e12a7a,start time:2018-03-20 10:43:59 -- Request String :  {"UserName":"15046699903","Pwd":"ZYjyh727","DeviceType":2,"DeviceId":"PC-20170525SADY","EquipmentNo":null,"SSID":"pc","RegisterPhones":null,"AppKey":"ab09d78e3b2c40b789ddfc81674bc24deac","Version":"2.0.5.3"} -- End -- Response String :  {"ErrorCode":0,"Success":true,"ErrorMsg":null,"Result":null,"WaitInterval":30} -- End

②logstash grok對合并后多行的處理。合并多行后續都一樣，如下：

filter { grok { match => { "message" => "^%{TIMESTAMP_ISO8601:InsertTime}\ .*-\ task\ request,.*,start\ time:%{TIMESTAMP_ISO8601:RequestTime}\n--\ Request\ String\ :\ \{\"UserName\":\"%{NUMBER:UserName:int}\",\"Pwd\":\"(?<Pwd>.*)\",\"DeviceType\":%{NUMBER:DeviceType:int},\"DeviceId\":\"(?<DeviceId>.*)\",\"EquipmentNo\":(?<EquipmentNo>.*),\"SSID\":(?<SSID>.*),\"RegisterPhones\":(?<RegisterPhones>.*),\"AppKey\":\"(?<AppKey>.*)\",\"Version\":\"(?<Version>.*)\"\}\ --\ \End\n--\ Response\ String\ :\ \{\"ErrorCode\":%{NUMBER:ErrorCode:int},\"Success\":(?<Success>[a-z]*),\"ErrorMsg\":(?<ErrorMsg>.*),\"Result\":(?<Result>.*),\"WaitInterval\":%{NUMBER:WaitInterval:int}\}\ --\ \End" } } }

在filebeat中使用multiline插件(推薦)：

①介紹multiline

• pattern：正則匹配從哪行合并;

• negate：true/false，匹配到pattern 部分開始合并，還是不配到的合并。

match：after/before(需自己理解)

• after：匹配到pattern 部分后合并，注意：這種情況末尾一行日志不會被匹配處理;

• before：匹配到pattern 部分前合并(推薦)。

②5.5版本之后(before為例)

filebeat.prospectors: - input_type: log   paths:     - /root/performanceTrace*   fields:     type: zidonghualog   multiline.pattern: '.*\"WaitInterval\":.*--\ End'   multiline.negate: true   multiline.match: before

③5.5版本之前(after為例)

filebeat.prospectors: - input_type: log       paths:       - /root/performanceTrace*       input_type: log        multiline:            pattern: '^20.*'            negate: true            match: after

在logstash input中使用multiline插件(沒有filebeat時推薦)：

①介紹multiline

• pattern：正則匹配從哪行合并;

• negate：true/false，匹配到pattern 部分開始合并，還是不配到的合并。

what：previous/next(需自己理解)

• previous：相當于filebeat 的after;

• next：相當于filebeat 的before。

②用法

input {         file {                 path => ["/root/logs/log2"]                 start_position => "beginning"                 codec => multiline {                         pattern => "^20.*"                         negate => true                         what => "previous"                 }         } }

在logstash filter中使用multiline插件(不推薦)：

不推薦的原因：

• filter設置multiline后，pipline worker會自動降為1;

• 5.5 版本官方把multiline 去除了，要使用的話需下載，下載命令如下：

/usr/share/logstash/bin/logstash-plugin install logstash-filter-multiline

示例：

filter {   multiline {     pattern => "^20.*"     negate => true     what => "previous"   } }

5、logstash filter中的date使用

日志示例：

2018-03-20 10:44:01 [33]DEBUG Debug - task request,task Id:1cbb72f1-a5ea-4e73-957c-6d20e9e12a7a,start time:2018-03-20 10:43:59

date使用：

date {                 match => ["InsertTime","YYYY-MM-dd HH:mm:ss "]                 remove_field => "InsertTime"         }

注：match => ["timestamp" ,"dd/MMM/YYYY H:m:s Z"]

匹配這個字段，字段的格式為：日日/月月月/年年年年 時/分/秒 時區，也可以寫為：match =>  ["timestamp","ISO8601"](推薦)

date介紹：

就是將匹配日志中時間的key替換為@timestamp的時間，因為@timestamp的時間是日志送到logstash的時間，并不是日志中真正的時間。

6、對多類日志分類處理(重點)

在filebeat的配置中添加type分類：

filebeat:   prospectors:     -       paths:         #- /mnt/data/WebApiDebugLog.txt*         - /mnt/data_total/WebApiDebugLog.txt*       fields:         type: WebApiDebugLog_total     -       paths:         - /mnt/data_request/WebApiDebugLog.txt*         #- /mnt/data/WebApiDebugLog.txt*       fields:         type: WebApiDebugLog_request     -       paths:         - /mnt/data_report/WebApiDebugLog.txt*         #- /mnt/data/WebApiDebugLog.txt*       fields:         type: WebApiDebugLog_report

在logstash filter中使用if，可進行對不同類進行不同處理：

filter {    if [fields][type] == "WebApiDebugLog_request" {   #對request 類日志         if ([message] =~ "^20.*-\ task\ report,.*,start\ time.*") {   #刪除report 行                 drop {}         }     grok {         match => {"... ..."}         } }

在logstash output中使用if：

if [fields][type] == "WebApiDebugLog_total" {     elasticsearch {         hosts => ["6.6.6.6:9200"]         index => "logstashl-WebApiDebugLog_total-%{+YYYY.MM.dd}"         document_type => "WebApiDebugLog_total_logs" }

二、對ELK整體性能的優化

1、性能分析

服務器硬件Linux：1cpu4GRAM

假設每條日志250Byte。

分析：

①logstash-Linux：1cpu 4GRAM

• 每秒500條日志;

• 去掉ruby每秒660條日志;

• 去掉grok后每秒1000條數據。

②filebeat-Linux：1cpu 4GRAM

• 每秒2500-3500條數據;

• 每天每臺機器可處理：24h*60min*60sec* 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輸出給els。

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.conf

① vm.swappiness = 1                     #ES 推薦將此參數設置為 1，大幅降低 swap 分區的大小，強制使用內存，注意，這里不要設置為 0, 這會很可能會造成 OOM ② net.core.somaxconn = 65535     #定義了每個端口監聽隊列上限的長度 ③ vm.max_map_count= 262144    #限制一個進程可以擁有的VMA(虛擬內存區域)的數量。虛擬內存區域是一個連續的虛擬地址空間區域。當VMA 的數量超過這個值，OOM ④ fs.file-max = 518144                   #設置 Linux 內核分配的文件句柄的max數量

[root@elasticsearch]# sysctl -p生效一下。

2)limits.conf 配置

vim /etc/security/limits.conf

elasticsearch    soft    nofile          65535 elasticsearch    hard    nofile          65535 elasticsearch    soft    memlock         unlimited elasticsearch    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.yml

bootstrap.memory_lock: true  #鎖住內存，不使用swap #緩存、線程等優化如下 bootstrap.mlockall: true transport.tcp.compress: true indices.fielddata.cache.size: 40% indices.cache.filter.size: 30% indices.cache.filter.terms.size: 1024mb threadpool:     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。

看完上述內容，你們對如何解決ELK的實用性問題有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。