生产beeline事故分析

场景分析

• 生产环境用beeline连接hive总是偶尔卡死
• hive健康检查也总是偶尔告警
• hive健康检查失败的同时，beeline连不上hive

• 场景截图如下：
  beeline连接超时

  
  企业微信截图_15313905439815.png

hive健康监控失败 hive健康监控.png

事故分析

• 确定两个事故是由于同一个问题引起的

• 排除metastore server的问题；虽然告警角色是metastore server，原因如下:

  1. 我们集群hive架构图如下：

     
     xhive_remotemetastore.jpg.pagespeed.ic.GNiWf952ue.jpg
  2. 根据以上架构图，我们尝试用hive cli和impala在hive健康告警的时候居然能顺利连上而且服务使用无障碍（基于相同用户，相同权限，各个节点都操作了一次）, 排除了metaStore服务问题

• 我们开始着手查看HiveServer2服务；当时怀疑是hiveServer2的问题，因为hive健康检查无非就是是通过hue权限去创建表，创建分区，删除表，看下这些操作成不成功；而且beeline连接的也是hiveServer2服务

• 查看hiveServer2日志，发现日志报大量以下错误

  
  hiveServer2错误日志.png
  

  看得一脸懵逼，大概意思就是hue通过thrift服务连接hiveServer2去删除表的时候失败。（hive健康检查报的错）

  发现错误有关键字sentry

• 查看sentry日志，因为hiveServer2日志有关键字sentry，虽然sentry一直没报错。也没告警

• 查看sentry日志，发现有大量请求堆积

  
  sentry-thrift.png

  大概意思是，sentry的请求队列满了，不再接受新的请求，注意pool size，active threads，rejected这几个关键字

• 当时推测，是不是因为sentry处理请求的线程池( thrift的threadPool )满了，所以当hive对sentry发起请求的时候，sentry服务拒绝了，然后hive重试了几次不行就放弃了，然后报错

• 找到sentry所在服务器和端口号，于是看了下连8038端口的host和port

#获取端口号8038的socket统计信息，信息做了聚合和排序
 ss | grep 8038 |awk '{print $5}' | awk 'BEGIN{FS=":"} {print $1}' | sort  -n  |uniq -c | sort -r 

8038端口socket情况.png

• 发现162-165这几台机器发送的请求特别多，于是上其中一台机器查看

#参考同事命令，根据端口查看进程
netstat -alntp |grep 8038

查看pid.png

• 上面的图发现有问题的服务不断在请求sentry:8038，根据pid查看服务

  
  根据pid查看服务.png

• 发现是kafka进程不断连接，于是停掉了kafka broker，发现请求确实停下来了

  
  重看sentry连接.png

• hive beeline连不上和健康监控告警的问题解决了

• 遗留问题，这几个问题机器的kafka broker为啥不断请求sentry，而其他的机器kafka broker确没有这样的问题，配置都是统一的