Elasticsearch寫入瓶頸導(dǎo)致skywalking大盤空白怎么解決

本篇內(nèi)容主要講解“Elasticsearch寫入瓶頸導(dǎo)致skywalking大盤空白怎么解決”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Elasticsearch寫入瓶頸導(dǎo)致skywalking大盤空白怎么解決”吧!

前言

繼上次skywalking出故障《解析Arthas協(xié)助排查線上skywalking不可用問(wèn)題》不到一個(gè)月，線上skywalking又出毛病了。又是大盤空白，trace列表最近的數(shù)據(jù)都查詢不出來(lái)，但是時(shí)間稍久的數(shù)據(jù)就能查詢出來(lái)，如一天前的數(shù)據(jù)有，一個(gè)小時(shí)前的數(shù)據(jù)就沒有，這個(gè)只是表象，最終查明癥結(jié)是ES的服務(wù)寫入瓶頸，導(dǎo)致寫入寫入數(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大盤沒有數(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的批量寫入失敗線程阻塞了。后從社區(qū)了解到是因?yàn)镋S寫入瓶頸，導(dǎo)致skywalking在批量寫入索引的時(shí)候線程阻塞了。導(dǎo)致阻塞的那段時(shí)間的數(shù)據(jù)都沒有寫到ES，然后查詢是沒有問(wèn)題的，表象就是skywalking的大盤空白也查詢不到近期的數(shù)據(jù)了。

解決方案

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

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

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

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

如果是自建Elasticsearch服務(wù)，在基礎(chǔ)大數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)搜索引擎 Elasticsearch 優(yōu)化和開發(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并沒有提供這種支持。

到此，相信大家對(duì)“Elasticsearch寫入瓶頸導(dǎo)致skywalking大盤空白怎么解決”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！