我司监控系统的底层存储架构使用的是 open-falcon，作为非常流行的中小企业监控解决方案，open-falcon非常优秀。

但在我司，指标量一度达到3亿+，且受限于成本等原因。falcon的存储组件就暴露出了一些性能问题。

本文从一个开发者的角度，阐述自本人接手以来对 graph(open-falcon的存储组件) 做过的一些优化工作，欢迎各位指正。

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#!/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虚拟节点, 看官可能觉得在跑着业务的系统上，难度很高，而实际上整个过程简单的一逼