WRY

Where Are You?
You are on the brave land,
To experience, to remember...

0%

为Fission 添加数据流监控能力

整体思路

为了追踪数据流在Fission的函数与函数和函数与队列之间的流动,需要在Fission的数据流关键组件中,添加监控埋点上报收集到的数据;此外还需要数据流相关的组件提供足够的信息,能够使得数据经过埋点时可以识别出数据的流动情况。

埋点位置选择

  • Router:所有对函数访问的流量都会经过Router组件,所以首选的埋点位置放在了Router中,可以监控到所有目的地是函数的流量情况。
  • Environment:为了收集函数向队列中的推送情况,在Environment中封装了Kafka的send函数,监控函数流向队列的数据流。此外因为MQ Consumer 不方便使用监控上报组件,Environment同时承担了函数消费队列之后向Response 和 Error队列中的推送情况。

信息上报位置

  • Environment:在函数访问其他函数的时候,流量转发到Router之前需要填报上该访问请求是来自于谁。
  • MQ Consumer:在MQ Consumer消费队列调用函数时,流量转发到Router之前,需要填报该请求时哪个消息队列触发的。

追踪的信息

Function 和 MQ Consumer 携带的参数

1
2
X-Fission-Flow-Source: 请求源
X-Fission-Flow-Source-Type: 请求源类型: {func, kafka, nats, azurequeue}

Prometheus Labels

1
2
3
4
5
6
source: 数据来源 格式:"func.{namespace}.{name}" or "{kafka|nats|azurequeue|...}.{topic}"
destination: 数据去向 格式:"func.{namespace}.{name}" or "{kafka|nats|azurequeue|...}.{topic}"
stype: 数据来源的类型
dtype: 数据去向的类型
method: 函数请求的方法
code: 请求结果

实际效果

Screenshot_20200923_192114

参照Istio实现非侵入式的header变更

由于目前需要手动添加header中的信息,每种语言的镜像都需要变更,而且需要用户主动的使用请求函数才能实现header中的信息补全十分的不友好,想过对requests库进行修改,但这种方式也是治标不治本,依旧会存在上述的问题。回想之前对Istio的零星记忆,决定参照Istio中的思想对pod的中的流量进行托管,经过了解,发现了iptables+envoy的模式对流量进行管理。由于对envoy的理解过少,暂时放弃了。

参考内容:

HTTP 自定义标头操作