为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 携带的参数

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

Prometheus Labels

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

实际效果

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

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

参考内容:

HTTP 自定义标头操作