背景

原生的open-falcon使用一致性哈希来进行存储的分片。其使用到的一致性哈希算法库是github.com/stathat/consistent
这个库使用了CRC32作为hash算法。CRC32用于一致性哈希时，结果是非常不均匀的。
而且open-falcon只使用500个虚拟节点，统计进到graph的点数速度，标准差结果甚至到了15k+。
更换hash算法成为当务之急。

我们将CRC32 + 500虚拟节点，变成了murmur3 + 10000虚拟节点, 看官可能觉得在跑着业务的系统上，难度很高，而实际上整个过程简单的一逼

背景

open-falcon的graph模块占用内存太多, 即发起了graph的内存优化，在上线过程中发生了曲线值异常的问题

背景 服务在开启了pprof的情况下，可以使用如下方式，简单粗暴的的获取gc情况 实现 #!/bin/bash _lastNumGC=0 _first=true while : ; do r=$(curl -s 127.0.0.1:6071/debug/pprof/heap?debug=1 | tail -22) _NumGC=$(echo $r | sed 's/#/\n#/g' | grep "^# NumGC" | awk '{print $NF}') NumGC=$[ ${_NumGC} -

背景

日常工作中，经常需要通过跳板机登录线上机器。
而为了安全起见，系统部的同学又启用了otp，动态生成code
给经常登录线上机器的使用者，带来了很大不便

作为iterm2的使用者，其coprocess的功能，可以实现自动登录，极大减少了手工输入动态密码及个人密码的次数。
什么是iterm2的coprocess，可参见其官方说明 coprocesses

数据采集

先来聊数据的源头，看官可能觉得不就是个agent么，搞好cpu、mem等基础指标的采集，上报上来不就好了，其实不然
首先，作为agent，一个最大的特点就是离中心太远了，远到无法很好的控制它。
尤其前期，不断的更新、迭代、修bug，当你有几十几百台机器时，都不是问题，什么ssh、ansible分分钟就搞定了。
但当你的规模成千上万的时候，就会发现，版本迭代是在是太痛苦了。
而且数量不是唯一的问题，例如你的上报中心地址变了，有网络分区了，有各种各样恶心的场景。