ELK系列--實時日誌分析系統ELK 部署與運行中的問題彙總

時間 2019-11-11

標籤 elk 系列實時日誌分析系統部署運行問題彙總简体版

原文原文鏈接

前記：html

去年測試了ELK，今年測試了Storm，最終由於Storm須要過多開發介入而放棄，選擇了ELK。感謝互聯網上各路大神，目前總算是正常運行了。git

logstash+elasticsearch+kibana的搭建參考：http://wsgzao.github.io/post/elk/。因爲搭建過程比較簡單就不贅述，主要分享幾個坑。github

正文：算法

一、日誌如何獲取

不管是storm方案仍是elk，都涉及這個關鍵問題。爲減小和運維、開發的交叉，儘量獨立、快速，加之當時發現了justniffer這個「神器」，遂決定採用交換機流量鏡像的方式。json

可是在經歷了申請機器、增長網卡以後，痛苦的發現存在掉包問題。一旦流量超過30--40M狂掉包，就別提TCP流還原了。justniffer是調用修改過的libnids，而libnids調用libpacap。所以轉向libpcap優化。安全

看了不少國內外的論文和研究文檔，使用pf-ring會有大幅改善掉包狀況。在同事協助下經歷了N次的源碼調試後，無奈的發現：即便啓用了pf-ring，掉包狀況依然。多是網卡太差了。。。服務器

詢問了青藤雲安全的大牛，他們的包捕獲與流還原技術不賣- -|cookie

因爲涉及justniffer、libpacap、pf_ring的版本對應問題、網卡驅動和源碼調試，上述過程耗時其實很是長，最終的結果讓人心碎，本身能力不夠啊app

無奈放棄流量鏡像，轉而採用在應用服務器上安裝客戶端的作法。若是有童鞋有好的方案，但願能分享，謝謝！運維

二、缺少訪問權限控制

因爲kibana默認沒有設置訪問權限控制，所以，直接訪問url便可訪問。同時elasticsearch也缺少權限控制，提交相關請求便可查看索引、模板，刪除索引。因此須要設置權限保護，分2個層面：

1）阻止未受權的用戶對ELK平臺的訪問

2）爲用戶設置的index訪問權限

詳情參考：http://eligao.com/shield-on-elasticsearch/

三、沒法搜索特殊字符

因爲混雜了kibana、elasticsearch、lunece，致使這個問題比較複雜。谷歌之能夠發現，不少內容都是提到：在kibana中搜索時，搜索特殊符號須要使用轉義符號轉義。可是問題是方法無效！！！

幸得搜索同事指導，加上本身學習，基本搞清楚狀況:

1）Kibana的搜索徹底是傳遞給Elasticsearch處理的，所以問題出在Elasticsearch；

2）在建立索引的時候，Elasticsearch默認的索引模板使用了默認的分析器（analyzer）standard對logstash提交的數據進行分析。，而standard默認的分詞器（tokenizer）是會剔除特殊字符。也就是說，特殊字符在創建索引的過程當中就被剔除了，所以即便使用轉義符號也沒法搜索特殊字符；相關概念解釋見文末說明。

解決方法：

1）定製分析器

官方文檔參考：https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-custom-analyzer.html。

藉助Elasticsearch提供的nGram分詞器，定製了一個單字符分析器。

官網的作法是經過API提交。我偷個懶，直接修改了Elasticsearch的配置文件elasticsearch.yml，在最後增長：

index:

  analysis:

    tokenizer:

      my_ngram_tokenizer:

        type: nGram

        min_gram : 1

        max_gram : 1

        token_chars : []

    analyzer:

      special_analyzer:

          type: custom

          filter: [lowercase]

          tokenizer: my_ngram_tokenizer

修改後，須要重啓Elasticsearch

2）修改默認模板

（不推薦新增索引模板，使用非logstash開頭的索引模板會致使raw字段丟失。若是已經遇到這個問題，參考https://bbrauns1.wordpress.com/2015/06/04/missing-raw-fields-in-logstashkibana-after-new-index-creation/）

注意，經過http://localhost:9200/_template/logstash?pretty獲取的索引模板和咱們須要改的索引模板稍有不一樣，去掉 "logstash" : {及倒數第二個}保存成logstash.json

修改上面得到的模板，主要是修改dynamic_templates部分，默認的模板是將全部string類型字段內容進行分析和索引，使用的是默認的standard分析器。同時對raw字段不分詞（如cookie.raw等，是logstash自動生成的）

參考官方文檔：https://www.elastic.co/guide/en/elasticsearch/guide/current/custom-dynamic-mapping.html

    "mappings" : {

      "_default_" : {

        "dynamic_templates" : [ {

          "string_fields" : {

            "mapping" : {

              "index" : "analyzed",

              "omit_norms" : true,

              "type" : "string",

              "fields" : {

                "raw" : {

                  "index" : "not_analyzed",

                  "ignore_above" : 256,

                  "type" : "string"

                }

              }

            },

            "match" : "*",

            "match_mapping_type" : "string"

          }

        }

所以，咱們須要增長指定特定字段，好比：

        {

          "request" : {

            "mapping" : {

              "index" : "analyzed",

              "analyzer" : "special_analyzer",

              "type" : "string",

              "fields" : {

                "raw" : {

                  "index" : "not_analyzed",

                  "ignore_above" : 256,

                  "type" : "string"

                }

              }

            },

            "match" : "request",

            "match_mapping_type" : "string"

          }

        },

表明咱們對request字段內容使用special_analyzer進行分析，同時保留對raw不分析。若是缺乏二次映射，則沒法獲取raw字段，則會對visualize形成影響。

若是不須要對相關字段進行是分詞，則如此配置：

        {

          "cookie" : {

            "mapping" : {

              "index" : "not_analyzed",

              "type" : "string",

              "fields" : {

                "raw" : {

                  "index" : "not_analyzed",

                  "ignore_above" : 256,

                  "type" : "string"

                }

              }

            },

            "match" : "cookie",

            "match_mapping_type" : "string"

          }

        },

3）提交索引模板：

cd /path/to/logstash.json

curl -u user -XPUT localhost:9200/_template/logstash -d @logstash.json

成功後，會返回：{"acknowledged":true}

4）刪除索引，索引模板

查看現有的全部索引：http://localhost:9200/_cat/indices?v

刪除全部索引：curl -u user -XDELETE localhost:9200/index

經過kibana的設置功能，刪除以前創建的index pattern

5）從新添加index pattern

注：配合kibana的搜索語法，使用雙引號""搜索徹底匹配，便可解決搜索特殊字符的問題。若是不帶雙引號，則會搜索字符串中的每一個字符。

四、logstash沒法啓動，提示bind address

緣由：

1）配置目錄下存在多個配置文件，而logstash會加載全部conf格式的文件

解決方案：刪除沒必要要的文件，保留一個conf文件便可

2）進程未結束

解決方案：kill -9 pid 強制結束進程，再啓動服務便可

五、字段沒法解析 _grokparsefailure

kibana沒法解析出相應的字段

緣由：正則存在問題或者日誌不符合正則格式

解決方案：在http://grokdebug.herokuapp.com/上調試正則，同時確保日誌中不存在多餘空格等異常

還有一種常見緣由：空格、空格、空格，重要的事情說三遍！

六、日誌量大，磁盤緊張

日誌量增長很是快，磁盤空間不夠用怎麼辦？能夠經過刪除較早的索引來緩解

所以，logstash的配置文件中最好早設置索引帶有時間後綴：如logstash-%{+YYYY.MM.dd}"

說明：

分析器相關概念：全文搜索引擎會用某種算法對要建索引的文檔進行分析，從文檔中提取出若干Token(詞元)，這些算法稱爲Tokenizer(分詞器)，這些Token會被進一步處理，好比轉成小寫等，這些處理算法被稱爲Token Filter(詞元處理器), 被處理後的結果被稱爲Term(詞)，文檔中包含了幾個這樣的Term被稱爲Frequency(詞頻)。引擎會創建Term和原文檔的Inverted Index(倒排索引)，這樣就能根據Term很快到找到源文檔了。文本被Tokenizer處理前可能要作一些預處理，好比去掉裏面的HTML標記，這些處理的算法被稱爲Character Filter(字符過濾器)，這整個的分析算法被稱爲Analyzer(分析器)。

詳情請參考：http://www.cnblogs.com/buzzlight/p/elasticsearch_analysis.html

後記：

不敢想象若是沒有google，上面的問題還能不能解決，還要多花多少時間。