https://laminar.fun/k8s/2021-09-02-Serverless-way-for-Kubernetes-Log-Alerting.html

[utterances-bot]

OpenFunction - 以 Serverless 的方式实现 Kubernetes 日志告警 | Laminar

概述当我们将容器的日志收集到消息服务器之后，我们该如何处理这些日志？部署一个专用的日志处理工作负载可能会耗费多余的成本，而当日志体量骤增、骤降时亦难以评估日志处理工作负载的待机数量。本文提供了一种基于 Serverless 的日志处理思路，可以在降低该

https://laminar.fun/k8s/2021-09-02-Serverless-way-for-Kubernetes-Log-Alerting.html

[jingb]

老哥 我自己是在公司做FaaS服务相关，最近一直关注你们开源的openFunction 我这边主要是基于fission在做 knative和keda都懂一些 dapr最近在接触，理解不深 按我理解knative是基于镜像，原来跑k8s上面的应用基本不用动都能上，不是一个纯面向FaaS的解决方案 这两天试用了下你们的框架也看了点openFunction-controller的代码，大概能理解一串function的代码是怎么上到knative的 提交了个函数之后会创建个build的任务，把简单逻辑的handler代码糅合到一个外层的框架（不是function-framework吧？从samples项目里面的代码还是不能完全理解function-framework的作用）里面，然后重新打成一个镜像再创建ksvc跑起来，不知道这样理解对不对

结合了你另一篇文章 https://www.laminar.fun/k8s/2021-06-23-FaaS-framework-s-function-handling-approach.html FaaS 框架（平台）的函数处理方式 站的视角非常高但理解起来还是太抽象了一点，希望可以分享多一些这方面设计的内容

[tpiperatgod]

把函数代码转换成应用的就是 function-framework，其他你理解的都是对的。

哈哈，关于设计方面的可以参考之前的 proposal：https://github.com/OpenFunction/OpenFunction/tree/main/docs/proposals

然后我们例会的回放都会上传到 B站，里面都有关于设计的讨论和案例演示：https://space.bilibili.com/438908638?from=search&seid=17544630034518148399&spm_id_from=333.337.0.0

老哥你也可以在微信群里讨论，互相学习哈。

[jingb]

老哥，异步消费的逻辑和设计我是完全看懂了 但这个场景下 Knative Serving有个地方没搞懂 业务接口的声明如下，其实就是完全一个http接口 func LogsHandler(w http.ResponseWriter, r *http.Request) { //逻辑处理 } 关键在于异步场景下是keda的controller根据配置的trigger一直去轮询kafka的topic来触发业务逻辑 而knative serving这种同步暴露的是一个http接口，这里面一直没有找到是由谁去承担监听kafka topic堆积的任务并触发这个接口

[tpiperatgod]

同步函数设计上不会去直接监听消息中间件的事件，只能通过 rest api 方式触发。如果要让消息触发同步函数，可以使用 openfunction 的事件框架，这里有案例：https://github.com/OpenFunction/OpenFunction/blob/main/docs/concepts/OpenFunction-events-framework.md#sample-1-event-source-trigger-synchronization-function

这个文档不是最新的，我最近会更新:sweat_smile:

[jingb]

这两天研究下了当前event这块的内容，确实比较复杂……简单描述下老哥帮忙看看理解对不对 openFunction基于knative serving的函数当前要触发的话，针对这个消费kafka然后处理日志报警的场景，是创建个eventsource然后在sink里面指定ksvc的访问地址，另外指定要消费的kafka的地址，这边openFunction会创建个deployment一直去消费kafka的消息再转发给业务逻辑代码的ksvc EventBus主要处理两个问题 一个是持久化事件保证至少触发一次的模型 一个是针对keda不支持的事件源比方github的一个构建事件，controller这边是把事件源给格式化（cloudevent）之后持久化到nats-stream，然后本身keda的trigger是支持nats-stream的，就可以充分利用到keda带来的弹性伸缩

Trigger这边是为了解决什么问题就一直难以充分理解，基于现有的例子和视频 像这个异步消费kafka日志然后萃取调用告警服务的场景，其实不需要Trigger就可以触发起来

我所理解的serverless，函数的触发都应该是一个个的trigger，Mq Trigger、Cron Trigger、Http Trigger、对象存储Trigger这样 但openFunction关于事件这块的设计确实是比较复杂，可能也是当前能看到的例子比较少，难以深入的理解，看这方面是不是可以多出一些设计考虑方面的文章

[tpiperatgod]

eventsource 和 eventbus 差不多是这个概念，trigger 的话主要是增加了对事件内容的过滤（计划实现中）和对事件的逻辑运算。这里有相关的 proposal：event framework trigger condition，案例可以参考这个：Use Trigger conditions，这部分参考了 argo events 的设计，但是实现上不太一样。

我们已经把 eventsource、trigger 这两个 deployment 改造成由 openfunction 自己来驱动，代码在这里：eventsource function、trigger-function

关于事件框架的 proposal：add event framework。但是现在事件源只有 Kafka 和 Cronjob 。。后面会增加其他的比如边缘的 MQTT，对象存储也是很常用的场景也会优先考虑。

[jingb]

老哥 这套事件体系大体能非常模糊地捋清流程，但依然无法准确理解设计意图，总觉得太复杂了 换个角度说我简单作为一个函数服务的使用者，对触发器粗浅的理解是触发函数的，各类MqTrigger、对象存储Trigger、httptrigger等，而不应该再去关心下层的EventSource、EventBus啦种种 感觉学习成本太高了和函数呈现一个极简的使用方式给开发者的理念有违背 你们这套体系是对标公有云应该是事件总线这类产品嘛？我自己也看了阿里云和腾讯云的事件总线这样的产品，感觉文档太烂了一直讲操作，最佳实践案例基本也没有，难以理解其价值 期待你们多出点文章让普通开发者也能理解这块的价值

[tpiperatgod]

事件驱动作为函数入口是必要存在的，那么从事件的生产者到最后函数（即事件的消费者）就会有这么几个节点需要处理：事件源（EventSource）、事件总线（EventBus）、触发器（Trigger）。我们从整体的角度看是计划把事件框架纳入函数计算平台的范围的（用黑话说就是形成闭环😅），包括我们下一步计划的函数网关（针对同步函数）。所以实现上就会包含老哥你说的不关心的 EventSource 和 EventBus。。

事件框架这部分从原理上其实很好理解，但确实如老哥所说，使用上有些复杂，涉及的配置比较多。我们现在也在考虑更合理的办法，比如新增配置模板的功能，如针对同一个事件源（比如 Kafka 服务器），那么多个 EventSource 就可以共用一套配置，从而降低 EventSource、EventBus 本身的配置难度。这部分我们没有参考公有云产品，首先是参考了 Knative Eventing，但是觉得那个更复杂，就参考了 Argo Events 的设计。不过最后实现起来和 Argo Events 也没啥关系了，只是借用了 CRD 的名称。。不过我觉得是可以把 Argo Events 接到 OpenFunction 上来，提供一种可选项。

我们后面也会结合新的进展发些新的案例或者设计文档，另外老哥如果有建议或者方案可以给我们开 issue 或者提 proposal！开源项目还是得有更多智慧融入进来才行哈哈。