transfer组件通过一致性hash调配，应用RPC接口将数据发送给judge组件，由judge组件做告警断定。

在transfer中，对于没有配置告警策略的指标，没有必要存储到judgeQueue，也没有必要发送给judge节点。

Open-falcon的解决是由transfer把所有的指标无脑发给judge，由judge判断该指标是否有告警规定关联。

nightingale作为升级版的Open-falcon，它的解决较为奇妙，它在transfer组件中就做了判断，若指标没有告警规定关联，则就无需存入judgeQueue，也不会发送到judge了，大大减少了网络发送数据量。

基于此，可对Open-falcon的transfer-->judge做肯定的流程优化。

1. Open-falcon的transfer-->judge

transfer将所有的指标无脑发送给judge，由judge做告警规定的断定；
看一下judge的代码，g.FilterMap中存储了metric及其告警规定信息，g.FilterMap的信息由judge申请hbs取得：

//modules/judge/rpc/receiver.gofunc (this *Judge) Send(items []*model.JudgeItem, resp *model.SimpleRpcResponse) error {    remain := g.Config().Remain    now := time.Now().Unix()    for _, item := range items {        exists := g.FilterMap.Exists(item.Metric)    //过滤有metric的数据        if !exists {            continue        }        pk := item.PrimaryKey()        store.HistoryBigMap[pk[0:2]].PushFrontAndMaintain(pk, item, remain, now)    }    return nil}

流程如下图所示：

2. nightingale的transfer-->judge

nightingale在transfer这一层就把无关告警规定的metric都过滤掉了，不再发送给judge。

Transfer接管agent指标的代码入口：

//agent发送数据到transfer，transfer存储到queue// src/modules/transfer/rpc/push.gofunc (t *Transfer) Push(args []*dataobj.MetricValue, reply *dataobj.TransferResp) error {    start := time.Now()    items := make([]*dataobj.MetricValue, 0)    for _, v := range args {        if err := v.CheckValidity(start.Unix()); err != nil {            ......            continue        }        items = append(items, v)    }    ......    if backend.Config.Enabled {        backend.Push2JudgeSendQueue(items)    }    reply.Total = len(args)    reply.Latency = (time.Now().UnixNano() - start.UnixNano()) / 1000000    return nil}

筛选metric到judgeQueue的代码：

  • 先比对endpoint/metric是否关联告警策略；
  • 再比照tag是否匹配；
  • 若两者都匹配，则放入judgeQueue;
// src/modules/transfer/backend/judge.gofunc Push2JudgeSendQueue(items []*dataobj.MetricValue) {    errCnt := 0    for _, item := range items {        //判断是否有关联的endpoint/metric        key := str.PK(item.Metric, item.Endpoint)        stras := cache.StraMap.GetByKey(key)        for _, stra := range stras {            //是否tag匹配            if !TagMatch(stra.Tags, item.TagsMap) {                continue            }            judgeItem := &dataobj.JudgeItem{                Endpoint:  item.Endpoint,                Metric:    item.Metric,                Value:     item.Value,                Timestamp: item.Timestamp,                DsType:    item.CounterType,                Tags:      item.Tags,                TagsMap:   item.TagsMap,                Step:      int(item.Step),                Sid:       stra.Id,                Extra:     item.Extra,            }            q, exists := JudgeQueues.Get(stra.JudgeInstance)            q.PushFront(judgeItem)        }    }    stats.Counter.Set("judge.queue.err", errCnt)}

cache.StraMap是transfer定期从mon-api组件查问失去的；

流程图如下：

3. 对Open-falcon的优化及其优缺点

优化点：

  • 在transfer中，向judgeQueue存入数据之前，查问该endpoint/metric/tags是否关联告警规定，仅有关联的告警规定时才会入队；
  • endpoint/metric/tags关联的告警规定，须要向hbs查问取得；
  • 该优化大大减少了transfer中judgeQueue的内存压力，也大大减少了向judge节点发送的网络数据量；

毛病：

  • transfer中须要引入对hbs的依赖，以保留以后的endpoint/metric/tags关联的告警规定信息；

参考：
1.夜莺监控零碎：https://github.com/didi/night...