Replies: 1 comment
-
通过http-flusher实现与业务系统的对接这个想法很👍 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
iLogtail 数据处理现状
目前iLogtail在processor插件中对于日志处理是一等公民,拥有非常多处理日志的插件,但是针对于指标方面的处理较为缺失。暂时想了几个使用场景。
一些指标方面的功能设想
指标计算
同timestamp下,不同指标之间的四则运算。
在阿里云emr业务下,有比较多类似场景,比如采集到了yarn 队列已用资源以及总资源,计算队列中资源使用百分比作为一个新的指标。
一段时序中,相同指标以及指定tag的聚合计算。
举个例子,计算cpu使用率近10分钟内min/max/avg/sum/count/rate/p90/p95/p99 等。
中心化收集
在大数据场景下,有众多组件采集的指标分散在集群各个node上,有些场景需要将这些分散的指标汇聚到一个中心节点,进行聚合分析。
目前ilogtail有http-server-input和http-flusher两插件,node可以通过http-flusher发送指标到master的http-server-input上进行汇聚。可能需要针对指标场景对这两个插件进行改造。
还有中心化汇聚需要存储,是否要引入一个本地化时序。
规则引擎
前面提及的指标计算和中心化收集在于处理和汇聚数据,最后需要更好的使用数据。
规则引擎可以是一些简单的if else 以及> <等条件表达式的实现。
在一些基于指标做弹性伸缩的业务场景有非常大的前景。举例子通过指标计算或者中心化收集再计算,得到二次计算后的指标,然后通过规则引擎,当新指标满足阈值后就可以通过http-flusher插件调用http接口,做一些告警接口对接或者业务系统弹性伸缩接口对接。
总结
有上述三个功能,就打造了一个在边缘侧的指标收集和处理引擎,可以将一些之前需要flink/spark streaming/kafka streaming等业务场景去掉计算引擎,将业务整体链路缩短,提高稳定性。
Beta Was this translation helpful? Give feedback.
All reactions