Elasticsearch 100問(1-30)

第1問

問：重啟集群后，出現(xiàn)了unassigned shards, 是什么原因：
答：集群的shard數(shù)量較多手幢，在節(jié)點(diǎn)重啟后松申，由于recovery并發(fā)限制，shard分配次數(shù)超限厘擂，集群就不會(huì)在分配shard了，從而出現(xiàn)unassigned shards; 可以使用api對(duì)shard進(jìn)行重新分配：POST _cluster/reroute?retry_failed=true

第2問

問：使用ES過程中锰瘸，出現(xiàn)bulk reject, 查看日志看到bulk queue滿了刽严，請問這是什么原因？
答：可以通過GET _cat/thread_pool/bulk?s=queue:desc&v查看正在拒絕或者歷史拒絕的個(gè)數(shù)避凝；一般默認(rèn)bulk queue大小是1024舞萄，造成bulk reject的大多數(shù)原因大概有兩種：
(1) shard容量多大，建議每個(gè)shard容量控制在20G-50G管削，shard數(shù)量不能過多倒脓，也不能過少
(2) shard分布不均，可通過調(diào)整index.routing.allocation.total_shards_per_node參數(shù)來解決

第3問

問：磁盤寫滿后含思，清理了一部分?jǐn)?shù)據(jù)崎弃，此時(shí)無法向ES中寫入數(shù)據(jù)，請問是什么原因：
答：磁盤寫滿后含潘，ES會(huì)把集群的block級(jí)別改為read_only_allow_delete, 此時(shí)需要修改該參數(shù)饲做，通過調(diào)用PUT _cluster/settings {cluster. blocks.read_only_allow_delete:"false"}解決，如果出現(xiàn)index level級(jí)別的block賊需要修改對(duì)應(yīng)索引的配置

第4問

問：使用logstash收集日志時(shí)遏弱，如何把logstash默認(rèn)添加的@timestamp字段替換為日志中的時(shí)間盆均？
答：

filter {
    grok {
        match => ["message", "%{TIMESTAMP_ISO8601:logdate}"
    }
    date {
        match => ["logdate", "yyyy-MM-dd HH:mm:ss,SSS"]
        target => "@timestamp"
    }
}

第5問

問：使用logstash收集日志時(shí)，如何修改logstash默認(rèn)添加的@timestamp字段的時(shí)區(qū)為東八區(qū)漱逸？
答：

filter {
  date {
    match => ["message","UNIX_MS"]
    target => "@timestamp"   
  }
  ruby { 
   code=>"event.set('timestamp',event.get('@timestamp').time.localtime + 8*60*60)" 
      }
  ruby {
   code => "event.set('@timestamp',event.get('timestamp'))"
  }
  mutate {
   remove_field => ["timestamp"]
  }
}

第6問

問：調(diào)用_forcemerge API發(fā)現(xiàn)并沒有減少segment的數(shù)量泪姨，請問是什么原因？
答：_forcemerge API執(zhí)行merge是有條件的饰抒，當(dāng)索引數(shù)據(jù)量比較大時(shí)肮砾，經(jīng)過了一定時(shí)間的merge之后，每個(gè)segement都會(huì)比較大循集，如果此時(shí)indexing的速率較低唇敞，merge操作期望可以merge的segment數(shù)量比較大蔗草，而實(shí)際上候選的segment數(shù)量沒有那么大時(shí)咒彤，就不會(huì)觸發(fā)merge操作

第7問

問：聚合查詢越來越慢疆柔，請問是什么原因？
答：需要確認(rèn)進(jìn)行聚合的字段唯一值是否比較多镶柱，唯一值較多的情況下聚合查詢構(gòu)建Global Ordinals會(huì)比較慢旷档，如果索引沒有持續(xù)寫入，構(gòu)建好的Global Ordinals就會(huì)進(jìn)行緩存歇拆，之后的查詢就可以使用緩存中的Global Ordinals鞋屈；但是如果索引在持續(xù)寫入，每當(dāng)?shù)讓拥膕egment發(fā)生變化時(shí)(有新數(shù)據(jù)寫入導(dǎo)致產(chǎn)生新的Segment故觅、Segment Merge)厂庇，就需要重新構(gòu)建Global Ordinals，隨著數(shù)據(jù)量的增大聚合字段的唯一值越來越多输吏，構(gòu)建Global Ordinals越來越慢权旷，所以對(duì)持續(xù)寫入的索引，聚合查詢會(huì)越來越慢贯溅。從業(yè)務(wù)角度進(jìn)行優(yōu)化的方案可以參考：https://cloud.tencent.com/developer/article/1421924

第8問

問：在kibana上創(chuàng)建index pattern卡主了拄氯，一直轉(zhuǎn)圈圈，無法創(chuàng)建它浅，是什么原因译柏？
答：首先確認(rèn)下.kibana的索引是否被設(shè)置為只讀了，當(dāng)集群出現(xiàn)過磁盤寫滿時(shí)姐霍，ES會(huì)自動(dòng)把索引設(shè)置block級(jí)別設(shè)置為readonly_allow_delete鄙麦，如果被設(shè)置為只讀，需要修改block級(jí)別PUT .kibana/_settings {"index.blocks.read_only_allow_delete":false}

第9問

問：通過logstash向ES寫入日志報(bào)錯(cuò)："type"=>"illegal_state_exception", "reason"=>"Can't get text on a START_OBJECT, 請問這是什么原因镊折？
答：原因是es對(duì)字段解析錯(cuò)誤黔衡，類型是字符串(keyword或者text)的字段接收到的值為對(duì)象(如json對(duì)象)，出現(xiàn)這種情況腌乡，可以在logstash 配置文件中使用json_encode filter plugin對(duì)原來是對(duì)象的字段轉(zhuǎn)換為字符串盟劫。

第10問

問：查詢dsl中使用了min_score參數(shù)用來限定返回文檔的得分，為什么多次執(zhí)行hit的文檔數(shù)量不一致与纽？
答：主分片和副本分片的差異導(dǎo)致的侣签，底層segment可能不一致，特別是在有文檔被刪除的情況下主分片和副本分片的segment中標(biāo)記刪除的文檔的數(shù)量可能會(huì)不一致(比如主分片進(jìn)行了merge急迂，副本分片沒有進(jìn)行merge)影所，導(dǎo)致最終主分片和副本分片上文檔的得分不同，影響了最終的查詢結(jié)果僚碎；可以在查詢時(shí)指定preference=_primary指定只查詢主分片解決,或者自定義preference解決

第11問

問：completion suggester自動(dòng)補(bǔ)全功能猴娩，在添加seggest inputs時(shí)指定了多個(gè)詞，為什么查詢時(shí)options只返回一項(xiàng)？

創(chuàng)建索引并添加doc：

curl -XPUT "http://localhost:10001/music" -H 'Content-Type: application/json' -d'
{
    "mappings": {
      "_doc":{
        "properties" : {
            "suggest" : {
                "type" : "completion"
            },
            "title" : {
                "type": "keyword"
            }
        }
    }
}}'

curl -XPUT "http://localhost:10001/music/_doc/7?refresh" -H 'Content-Type: application/json' -d'
{
    "suggest" : {
        "input": [ "bat", "bar"]
    }
}'

查詢：

curl -XPOST "http://localhost:10001/music/_search?pretty" -H 'Content-Type: application/json' -d'
{
    "suggest": {
        "song-suggest" : {
            "prefix" : "ba", 
            "completion" : { 
                "field" : "suggest" 
            }
        }
    }
}'

結(jié)果：

...
"options": [
          {
            "text": "bar",
            "_index": "music",
            "_type": "_doc",
            "_id": "7",
            "_score": 1,
            "_source": {
              "suggest": {
                "input": [
                  "bat",
                  "bar"
                ]
              }
            }
          }
        ]
...

答： completion suggester返回的options是文檔級(jí)別的卷中，查詢命中后就會(huì)提前終止矛双，所以只能返回第一個(gè)匹配到的值；解決方法是bat, bar兩個(gè)詞分別放在兩個(gè)doc中

第12問

問：2核4G 3節(jié)點(diǎn)的集群蟆豫，在保證集群性能穩(wěn)定的情況下议忽，最多可以支持多少shard?
答：每個(gè)節(jié)點(diǎn)上可以存儲(chǔ)的分片數(shù)量與可用的堆內(nèi)存大小成正比關(guān)系，分片數(shù)量越多十减，分片的元數(shù)據(jù)占用的內(nèi)存越多栈幸，一般情況下，1GB的堆內(nèi)存對(duì)應(yīng)分片數(shù)量不超過20

第13問

問：請問ES報(bào)這個(gè)錯(cuò)誤是什么原因："caused_by"=>{"type"=>"max_bytes_length_exceeded_exception", "reason"=>"max_bytes_length_exceeded_exception: bytes can be at most 32766 in length; got 33023"}?
答：原因是索引中有字段為keyword類型帮辟，但是寫入時(shí)的該字段的數(shù)據(jù)長度超過了keyword類型的最大長度32766個(gè)字節(jié)速址，可以把該字段的類型設(shè)置為text解決。

第14問

問：使用filebeat收集日志寫入ES中由驹，報(bào)錯(cuò):"Bulk item insert failed (i=0, status=500): {"type":"string_index_out_of_bounds_exception","reason":"String index out of range: 0"}",請問是什么原因壳繁？
答：當(dāng)filebeat的output.elasticsearch.index配置項(xiàng)有取自上游event中的某個(gè)字段，而某個(gè)event中該字段不存在時(shí)荔棉，想ES寫入數(shù)據(jù)會(huì)報(bào)錯(cuò)闹炉。索引的名稱如果要從event中的某個(gè)字段獲取，需要確保該字段一定會(huì)存在润樱。

第15問

問：ES的_refresh和_flush操作的區(qū)別是什么渣触？
答：refresh調(diào)用了lucene DirectoryReader的 openIfChanged()方法，相當(dāng)于重新打開了indexReader, 使得寫入的數(shù)據(jù)都可以被搜索到壹若；flush操作調(diào)用了luecene IndexWriter的commit()方法嗅钻，把仍在在文件系統(tǒng)緩存中的segment寫入到磁盤中，實(shí)現(xiàn)了數(shù)據(jù)的真正持久化店展，flush同時(shí)還會(huì)觸發(fā)refresh操作养篓。

第16問

問：在ES的script query中，使用doc['my_field'].value和 params['_source']['my_field']赂蕴，兩種方式有什么不同柳弄？
答：使用doc[]的方式會(huì)把字段的所有terms都加載進(jìn)內(nèi)存并且會(huì)被緩存，因此比較消耗內(nèi)存概说，同時(shí)doc[]的方式只支持單值字段碧注；使用_source的方式terms不會(huì)被緩存，相比doc[]的方式較慢糖赔。

第17問

問：ES的刪除操作不是真正的刪除萍丐，那通過什么方式可以獲取到準(zhǔn)確的文檔數(shù)量？
答：通過_cat/count API獲取集群中所有文檔數(shù)量放典，不包含已刪除的文檔逝变；通過{index}/_stats API獲取索引中的文檔數(shù)量基茵，結(jié)果中docs.count值為除了標(biāo)記刪除文檔之外的總的文檔數(shù)，docs.deleted為標(biāo)記刪除的文檔數(shù)壳影。

第18問

問：ES的_search API拱层，當(dāng)不指定索引時(shí)是會(huì)向集群中所有的索引發(fā)起查詢請求嗎？
答：是默認(rèn)行為态贤，最好通過指定索引名稱或者對(duì)多個(gè)索引設(shè)置別名后進(jìn)行查詢舱呻，可以減少不必要的開銷醋火；5.6版本以后增加了分片預(yù)過濾功能悠汽，當(dāng)要查詢的分片數(shù)量超過128并且查詢可能會(huì)被重寫為MatchNoneQuery時(shí)，會(huì)進(jìn)行過濾芥驳，過濾掉不需要的shard柿冲，_search API的返回結(jié)果中的_shards.skipped表示了過濾掉了多少shard。

第19問

問：如果使用scroll批量獲取查詢結(jié)果兆旬，ES執(zhí)行該查詢時(shí)還會(huì)使用node query cache或者shard request cache嗎假抄？
scroll請求不會(huì)用到cache，因?yàn)槭褂胏ache在查詢請求執(zhí)行過程中會(huì)修改search context丽猬，會(huì)破壞掉scroll的context宿饱。

第20問

問：如何實(shí)現(xiàn)字符串的前后通配符匹配，比如輸入bc脚祟，想查詢出abc, abcd, bcd, 但是不能查詢出abdc谬以？
答：使用query_string查詢：

{
    "query":{
        "query_string":{
            "query":"field:*ab*"
        }
    }
}

第21問

問：使用query_string查詢指定的整型字段，查詢的值為正數(shù)時(shí)正常由桌，值為負(fù)數(shù)時(shí)拋異常为黎，如“status:-1”時(shí)會(huì)報(bào)錯(cuò)，怎么解決行您？
答：需要把負(fù)號(hào)轉(zhuǎn)義("status:\-1")或者對(duì)負(fù)數(shù)加引號(hào), 否則會(huì)認(rèn)為負(fù)號(hào)是一個(gè)操作符而解析失敗铭乾。

第22問

問：在kibana中要對(duì)long型的字段進(jìn)行聚合，但是提示不支持娃循，請問這是什么原因炕檩？
答：如果索引是按天創(chuàng)建的，并且一個(gè)index pattern下包含多個(gè)索引捌斧，檢查下索引的mapping捧书，是否之前的索引中字段類型是否是字符串類型，如果不同索引中該字段的類型不一致骤星，則不能對(duì)該字段進(jìn)行聚合经瓷。https://github.com/elastic/kibana/issues/3451

第23問

問：通過bulk api向es寫數(shù)據(jù)時(shí)，報(bào)錯(cuò)failed to execute bulk item (index) BulkShardRequest ...source[n/a, actual length: [4.5kb], max length: 2kb]}], 請問是字段超過了最大長度2kb的限制嗎洞难？
答：日志中打出的max length不是字段的最大長度的意思舆吮，而是超過了2kb就不把具體的doc信息在日志中打出，bulk失敗的信息需要查看日志中后面的異常信息，一般是字段解析失敗或者是bulk隊(duì)列滿導(dǎo)致的色冀。

第24問

問：索引中有一個(gè)字符串型的字段潭袱，需要在kibana中這個(gè)字段求平均值并且展示出來，該怎么實(shí)現(xiàn)呢锋恬？
答：參考https://www.elastic.co/guide/en/kibana/current/scripted-fields.html, 使用script fields屯换。

第25問

問: filebeat 7.x版本，在配置文件中定義了index名稱与学，為什么寫入到es中仍然生成的是filebeat-*之類的索引彤悔？
答: 通過配置setup.ilm.enabled: false解決。索引生命周期管理ilm功能默認(rèn)開啟索守，開啟的情況下索引名稱只能為filebeat-*晕窑，通過setup.ilm.enabled: false進(jìn)行關(guān)閉；如果要使用自定義的索引名稱卵佛，同時(shí)又需要啟用ilm杨赤，可以修改filebeat的模板。

第26問

問: 使用filebeat+es+kibana收集容器中的nginx日志截汪，但是發(fā)現(xiàn)kibana中的message是一整段疾牲，字段都放在一起了，請問這個(gè)該怎么處理衙解？
答: 兩種解決辦法：

(1)nginx日志配置為json格式, filebeat配置文件中指定解析json格式的日志json.keys_under_root: true
(2)仍然使用默認(rèn)的nginx日志格式阳柔，在es中自定義ingest pipeline解析每個(gè)字段，filebeat配置文件中指定使用定義好的pipeline

第27問

問: 請問ES的fielddata和docvalues有什么區(qū)別呢丢郊？
答: fielddata是在堆內(nèi)存的盔沫，docvalues是在堆外內(nèi)存的；docvalues默認(rèn)對(duì)所有not_analyzed字段開啟(index時(shí)生成)枫匾，如果要對(duì)analyzed字段進(jìn)行聚合架诞，就要使用fielddata了(使用時(shí)把所有的數(shù)據(jù)全都加載進(jìn)內(nèi)存)；如果不需要對(duì)analyzed字段進(jìn)行聚合干茉，就可以降低堆內(nèi)存谴忧，Elasticsearch（更快的 GC）和 Lucene（更多的內(nèi)存用于緩存）的性能越好

第28問

問：ES的ik-analyzer分詞插件默認(rèn)會(huì)把英文大寫字母轉(zhuǎn)換為小寫，但是業(yè)務(wù)查詢時(shí)是對(duì)大小寫敏感的角虫，怎么可以做到使用ik-analyzer分詞插件的同時(shí)禁止把大寫字母轉(zhuǎn)換為小寫沾谓？
答：基于ik_smart分詞類型自定義analyzer, 同時(shí)配置參數(shù) "enable_lowercase": false:

{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_ik": {
          "type": "ik_smart",
          "enable_lowercase": false
        }
      }
    }
  }
}

第29問

問：業(yè)務(wù)日志按文件大小滾動(dòng)(最大100MB,滾動(dòng)后壓縮)，使用filbeat收集日志時(shí)戳鹅，發(fā)現(xiàn)在日志滾動(dòng)較快的情況下filebeat沒有釋放掉已經(jīng)被刪除掉的日志文件均驶，導(dǎo)致磁盤使用率較高，請問這個(gè)怎么解決枫虏？
答：可以通過配置close_timeout參數(shù)釋放掉已經(jīng)刪除文件的文件句柄妇穴。

第30問

問：使用filebeat 5.6.4收集nginx日志文件(按天滾動(dòng)爬虱，滾動(dòng)后壓縮)，發(fā)現(xiàn)filebeat data目錄下registry文件越來越大腾它，并沒有清理掉很早日志文件的state信息跑筝，請問這個(gè)怎么解決？
答：通過配置ignore_older和clean_inactive兩個(gè)參數(shù)瞒滴，清理掉registry中無用的文件state信息曲梗。