脚本之 kugou http_code 5xx 突增 排查思路

cat > kugou.sh <<-EOF
cat /cache/logs/fcache_data_backup/20170306*.tmp |grep -E "fanxing.kugou.com|fsweb.kugou.com" |  perl -lne 'BEGIN{$n=0} map {$n += $_} ($_ =~ /"1005 (\d+) \d+"/); END{print $n}' > /tmp/kugou
EOF

pingtai=`dig $domain.cloudglb.com @8.8.8.8 |grep $domain.cloudglb.com|grep  CNAME|awk '{print $5}'|awk -F '.' '{print $1"."$2}'`
dev -all -p $pingtai > /work/caozhi/node.list

for i in `cat /work/caozhi/node.list`;do
    scpp kugou.sh root@$i:/tmp/
done

sudo pssh -h node.list -x '-p12321' -P "sh /tmp/kugou.sh"

for i in `cat node.list`;do
    echo $i;sshp $i cat /tmp/kugou
done > yutong

awk '{if(NR%2 != 0){tt=$0} else {print $0,tt}}' yutong | sort -nr | head -20|nali3

########################
zcat kugou5xx/kugou090723 | awk '$9~/502/{print $NF}' | sort -nr | uniq -c | sort -nr | head | nali3
zcat kugou5xx/kugou090723 | awk '$9~/502/{print $7}' | sort -nr | uniq -c | sort -nr | head
zcat /cache/logs/2016090723_error.log.gz | grep -B6 "502 Bad Gateway" | grep -B1 "http:\/\/" | awk '{print $8,$13,$14,$15,$16}' | sort -nr | uniq -c | sort -nr | head
zcat /cache/logs/2016090723_error.log.gz | grep -B6 "502 Bad Gateway" | grep "http:\/\/" | awk '{print $NF}' | awk -F '/' '{print $3}' | sort -nr | uniq -c | sort -nr | head


zcat /cache/logs/heka-data/20161127/20161127* | awk '$9==0 {print $1}'|sort -nr |uniq -c|sort -nr|head
zcat /cache/logs/heka-data/20161127/20161127* | awk '$9==0 {print $1}' >clientip
scpp  root@211.162.49.148:/root/clientip .
nali3 clientip | awk -F '-' '{print $2$4}' | sort -nr |uniq -c|sort -nr|head

我所在的CDN公司在后台有一个统计5xx数量的实时图表，客户一般会订阅上这个报警，但是后台统计里看不到哪台设备异常，而且这个5xx数量统计不是从web server log里统计出来的，而且单独一套计数器的日志收集回来的。

一般这种情况没有大量的时间去统计web server log，日志量太大。
因此本篇仅提供思路。

脚本的内容就是找出5xx最多的设备，来快速的找到有故障的设备（有时监控不太灵）。。。

最后结果就会按5xx的数量排序，一般只有个别几台特别多，这个方法可以最快的定位到哪台设备有异常，然后登录设备查看实时日志即可。
一般有以下4种情况（绝大部分code是502）：

502 Bad Gateway
作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

1、http code是500的话，一般是盘有问题；
2、这台设备到upstream的上层设备链路异常，有可能是机房问题，还有upstream ip写错的人为失误；如果是某几台5xx特别多，也有可能是某台回源设备网络异常，这时需要看upstream的哪台回源设备；
3、设备负载很高，响应很慢，这个时候就需要调整覆盖解析了；

4、当然也有所有的设备5xx数量都很多的情况，很有可能某个源站网络异常。并且有必要查看web server 的error log，可能里面写着connection timed out 某台设备，以及这个报障域名是否占了error_log里的域名很大比例。（前提是这个cache平台跑的域名流量 差别不是特别多的情况）