場景分析
- 生產(chǎn)環(huán)境用beeline連接hive總是偶爾卡死
- hive健康檢查也總是偶爾告警
- hive健康檢查失敗的同時砚嘴，beeline連不上hive
-
場景截圖如下：
beeline連接超時
企業(yè)微信截圖_15313905439815.png
事故分析
確定兩個事故是由于同一個問題引起的
-
排除metastore server的問題壹置；雖然告警角色是metastore server沽讹，原因如下:
-
我們集群hive架構(gòu)圖如下：
xhive_remotemetastore.jpg.pagespeed.ic.GNiWf952ue.jpg - 根據(jù)以上架構(gòu)圖，我們嘗試用hive cli和impala在hive健康告警的時候居然能順利連上而且服務(wù)使用無障礙（基于相同用戶，相同權(quán)限晃酒，各個節(jié)點(diǎn)都操作了一次）, 排除了metaStore服務(wù)問題
-
我們開始著手查看HiveServer2服務(wù)；當(dāng)時懷疑是hiveServer2的問題窄绒，因?yàn)閔ive健康檢查無非就是是通過hue權(quán)限去創(chuàng)建表贝次，創(chuàng)建分區(qū)，刪除表彰导，看下這些操作成不成功蛔翅；而且beeline連接的也是hiveServer2服務(wù)
-
查看hiveServer2日志敲茄，發(fā)現(xiàn)日志報(bào)大量以下錯誤
hiveServer2錯誤日志.png
看得一臉懵逼，大概意思就是hue通過thrift服務(wù)連接hiveServer2去刪除表的時候失敗山析。（hive健康檢查報(bào)的錯）
發(fā)現(xiàn)錯誤有關(guān)鍵字sentry
查看sentry日志堰燎，因?yàn)閔iveServer2日志有關(guān)鍵字sentry，雖然sentry一直沒報(bào)錯笋轨。也沒告警
-
查看sentry日志秆剪，發(fā)現(xiàn)有大量請求堆積
sentry-thrift.png大概意思是，sentry的請求隊(duì)列滿了爵政，不再接受新的請求仅讽，注意pool size，active threads茂卦，rejected這幾個關(guān)鍵字
當(dāng)時推測何什，是不是因?yàn)閟entry處理請求的線程池( thrift的threadPool )滿了，所以當(dāng)hive對sentry發(fā)起請求的時候等龙，sentry服務(wù)拒絕了处渣，然后hive重試了幾次不行就放棄了，然后報(bào)錯
找到sentry所在服務(wù)器和端口號蛛砰，于是看了下連8038端口的host和port
#獲取端口號8038的socket統(tǒng)計(jì)信息罐栈，信息做了聚合和排序
ss | grep 8038 |awk '{print $5}' | awk 'BEGIN{FS=":"} {print $1}' | sort -n |uniq -c | sort -r
- 發(fā)現(xiàn)162-165這幾臺機(jī)器發(fā)送的請求特別多，于是上其中一臺機(jī)器查看
#參考同事命令泥畅，根據(jù)端口查看進(jìn)程
netstat -alntp |grep 8038
-
上面的圖發(fā)現(xiàn)有問題的服務(wù)不斷在請求sentry:8038荠诬，根據(jù)pid查看服務(wù)
根據(jù)pid查看服務(wù).png -
發(fā)現(xiàn)是kafka進(jìn)程不斷連接，于是停掉了kafka broker位仁，發(fā)現(xiàn)請求確實(shí)停下來了
重看sentry連接.png hive beeline連不上和健康監(jiān)控告警的問題解決了
遺留問題柑贞，這幾個問題機(jī)器的kafka broker為啥不斷請求sentry，而其他的機(jī)器kafka broker確沒有這樣的問題聂抢，配置都是統(tǒng)一的
