快捷導(dǎo)航

Elasticsearch寫(xiě)入瓶頸導(dǎo)致skywalking大盤(pán)空白

更新時(shí)間：2022年02月28日 14:34:45 作者：kl

這篇文章主要為大家介紹了Elasticsearch寫(xiě)入瓶頸導(dǎo)致skywalking大盤(pán)空白的解決方案，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步

前言

繼上次skywalking出故障《解析Arthas協(xié)助排查線上skywalking不可用問(wèn)題》不到一個(gè)月，線上skywalking又出毛病了。又是大盤(pán)空白，trace列表最近的數(shù)據(jù)都查詢不出來(lái)，但是時(shí)間稍久的數(shù)據(jù)就能查詢出來(lái)，如一天前的數(shù)據(jù)有，一個(gè)小時(shí)前的數(shù)據(jù)就沒(méi)有，這個(gè)只是表象，最終查明癥結(jié)是ES的服務(wù)寫(xiě)入瓶頸，導(dǎo)致寫(xiě)入寫(xiě)入數(shù)據(jù)的線程阻塞導(dǎo)致的。下面是排錯(cuò)過(guò)程以及解決方案說(shuō)明。

問(wèn)題定位

工具還是那個(gè)工具Arthas，不了解的可以翻閱我之前的博文，這里不多說(shuō)明Arthas。不過(guò)這次我們應(yīng)用了一個(gè)新的進(jìn)階指令thread，它可以查看當(dāng)前線程信息，查看線程的堆棧。當(dāng)skywalking大盤(pán)沒(méi)有數(shù)據(jù)時(shí)，使用如下指令：

thread -b

THREAD -B, 找出當(dāng)前阻塞其他線程的線程

有時(shí)候我們發(fā)現(xiàn)應(yīng)用卡住了，通常是由于某個(gè)線程拿住了某個(gè)鎖，并且其他線程都在等待這把鎖造成的。為了排查這類問(wèn)題， arthas提供了thread -b，一鍵找出那個(gè)罪魁禍?zhǔn)?。最后得到如下的結(jié)果：

如上圖，相信大家已經(jīng)看到問(wèn)題所在了，重點(diǎn)在紅色字體箭頭指向的部分，不得不說(shuō)Arthas做的太棒了。癥結(jié)就是ES的批量寫(xiě)入失敗線程阻塞了。后從社區(qū)了解到是因?yàn)镋S寫(xiě)入瓶頸，導(dǎo)致skywalking在批量寫(xiě)入索引的時(shí)候線程阻塞了。導(dǎo)致阻塞的那段時(shí)間的數(shù)據(jù)都沒(méi)有寫(xiě)到ES，然后查詢是沒(méi)有問(wèn)題的，表象就是skywalking的大盤(pán)空白也查詢不到近期的數(shù)據(jù)了。

解決方案

臨時(shí)方案，SKYWALKING參數(shù)調(diào)優(yōu)

skywalking寫(xiě)入ES的操作是使用了ES的批量寫(xiě)入接口。我們可以調(diào)整這些批量的維度。盡量降低ES索引的寫(xiě)入頻率，如：

elasticsearch:
    clusterNodes: 192.168.20.221:9200 indexShardsNumber: 2 indexReplicasNumber: 0 # Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html bulkActions: 4000 # Execute the bulk every 2000 requests bulkSize: 40 # flush the bulk every 20mb flushInterval: 30 # flush the bulk every 10 seconds whatever the number of requests concurrentRequests: 2 # the number of concurrent requests receiver-register: default:
receiver-trace: default:
    bufferPath: ../trace-buffer/ # Path to trace buffer files, suggest to use absolute path bufferOffsetMaxFileSize: 500 # Unit is MB bufferDataMaxFileSize: 1000 # Unit is MB bufferFileCleanWhenRestart: false

調(diào)整bulkActions默認(rèn)2000次請(qǐng)求批量寫(xiě)入一次改到4000次。批量刷新從20M一次到40M一次。這種配置調(diào)優(yōu)確實(shí)生效了，重啟服務(wù)后兩三天了都沒(méi)有出現(xiàn)過(guò)ES寫(xiě)入阻塞的問(wèn)題。不過(guò)這種設(shè)置只是暫時(shí)的，你只能期望流量不突發(fā)，或者應(yīng)用不增加。一旦遇到突發(fā)流量和應(yīng)用的增加，ES寫(xiě)入瓶頸還是會(huì)凸顯出來(lái)。而且參數(shù)設(shè)置過(guò)大帶來(lái)了一個(gè)新的問(wèn)題，就是數(shù)據(jù)寫(xiě)入延時(shí)會(huì)比較大，一次服務(wù)交互發(fā)生的trace隔好久才能在skywalking頁(yè)面上查詢到。所以最終解決方案是優(yōu)化ES的寫(xiě)入性能。

最終方案-優(yōu)化ES的寫(xiě)入性能

如果是自建Elasticsearch服務(wù)，在基礎(chǔ)大數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)搜索引擎 Elasticsearch 優(yōu)化和開(kāi)發(fā),博文里分享了很多可調(diào)優(yōu)配置的參數(shù)。不過(guò)我們這邊綜合運(yùn)維人力和支出方面的考慮，決定采用阿里云提供的Elasticsearch，不過(guò)這帶來(lái)了一個(gè)新的問(wèn)題，阿里云的ES服務(wù)不論內(nèi)外網(wǎng)都需要Http Basic認(rèn)證，但是目前的skywalking并沒(méi)有提供這種支持。

結(jié)語(yǔ)

skywalking是一款非常不錯(cuò)的開(kāi)源apm產(chǎn)品，很多功能特性甚至可以和商業(yè)的apm產(chǎn)品一爭(zhēng)高下，比如trace查詢等功能。我們線上的skywalking沒(méi)有全面鋪開(kāi)去接入應(yīng)用，但是問(wèn)題還是發(fā)生了不少，希望這些線上的踩坑排坑經(jīng)驗(yàn)?zāi)軒?lái)更多的參考價(jià)值。關(guān)于Elasticsearch 帶Http Basic 認(rèn)證skywalking不支持的問(wèn)題，將在下文詳描述去解決

以上就是Elasticsearch寫(xiě)入瓶頸導(dǎo)致skywalking大盤(pán)空白的詳細(xì)內(nèi)容，更多關(guān)于Elasticsearch寫(xiě)入skywalking空白的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: