在上一篇文章采集篇的事情做完后，源数据就已经有了，但应该如何上报到存储就是接下来要考虑到的事情。
本文结合我司在传输链路的建设，简述一下期间的一点思考。

基于/proc/[pid]/stat和/proc/stat计算指定进程的cpu利用率

#!/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的内存优化，在上线过程中发生了曲线值异常的问题