监控系统构建实践之传输篇
在上一篇文章采集篇的事情做完后,源数据就已经有了,但应该如何上报到存储就是接下来要考虑到的事情。
本文结合我司在传输链路的建设,简述一下期间的一点思考。
在上一篇文章采集篇的事情做完后,源数据就已经有了,但应该如何上报到存储就是接下来要考虑到的事情。
本文结合我司在传输链路的建设,简述一下期间的一点思考。
#!/bin/sh
corenum=$(nproc --all)
p=xxx
pid=$(pidof $p)
p_totaltime1=$(awk '{print $14+$15}' /proc/${pid}/stat)
totaltime1=$(awk '{if($1=="cpu"){for(i=2;i<=NF;i++){sum+=$i}}}END{print sum}' /proc/stat)
sleep 3 # 为什么是3, 要得到与top相同的结果
p_totaltime2=$(awk '{print $14+$15}' /proc/${pid}/stat)
totaltime2=$(awk '{if($1=="cpu"){for(i=2;i<=NF;i++){sum+=$i}}}END{print sum}' /proc/stat)
res=$(awk 'BEGIN{print '"($p_totaltime2-$p_totaltime1)*100/($totaltime2-$totaltime1)*$corenum"'}')
echo $res
监控系统这个话题很大。
但一个基本的监控系统归纳起来,无非也就是数据采集、传输、存储、查询这么几个部分。
本文尝试从宏观上分析这几个模块在实践上遇到的一些问题,在我司的最佳实践解法,及本人对各个模块在实践中的一些思考。
原生的open-falcon使用一致性哈希来进行存储的分片。其使用到的一致性哈希算法库是github.com/stathat/consistent
这个库使用了CRC32作为hash算法。CRC32用于一致性哈希时,结果是非常不均匀的。
而且open-falcon只使用500个虚拟节点,统计进到graph的点数速度,标准差结果甚至到了15k+。
更换hash算法成为当务之急。
我们将CRC32 + 500虚拟节点
,变成了murmur3 + 10000虚拟节点
, 看官可能觉得在跑着业务的系统上,难度很高,而实际上整个过程简单的一逼
open-falcon的graph模块占用内存太多, 即发起了graph的内存优化,在上线过程中发生了曲线值异常的问题