分布式日志中心开源篇

2020-05-29 00:00:00 数据 自己的 开源 是一个 日志

前面分别聊了

<分布式日志中心国外篇>

<分布式日志中心国内篇>

本篇分享下分布式日志中心的开源产品。

首当其冲的就是ELK,当前很多企业都会采用ELK来搭建自己的日志中心,但是真的能帮他们解决什么问题呢?这个从这么多商业公司也在做这件事情上或多或少能反映一些问题,我想这其中的原因可能有如下3点:

1、ELK使用门槛还是太高,除了安装部署运维,还是使用,比如日志接入,日志解析等。

2、没有贴近客户和业务,缺乏完善的管理视角,单纯是一个日志平台。

3、数据处理欠缺,海量数据管理瓶颈。

其实网络上针对ELK的介绍和原理剖析文章专栏,真心不少,在此就不无巨细的地再嚼舌一次,我从以下几个点简单谈下我的一些观点.

1、ELK当前具备了比较完善的插件开发机制,不管是elasticsearch,或者是Logstash的Input/Filter/Output,还是UI层面的Kibana,都支持用户去开发自定义插件,其实这就形成了一套比较完善的生态,可以让第三方开发者直接参与进来,根据自己的业务和技术场景来做开发。

2、ELK完全开源,截止到2018年,把仅有的付费模块XPack也开源了,只是该付费模块的license许可不同而已,也是谨防当前的一些云厂商玩家坐收渔利有关。

3、ELK产品覆盖度广,特别是开源了xpack以后,对于ML/Graph/Security/APM/SQL等模块来满足一些AIOPS的使用场景。

作为技术同学,可以好好研究下elk源码以及设计思想,目前核心代码量也是至少达到百万之巨,自己也在持续学习中,特别在ELK7.x发布以后,在一些稳定性,zen2集群算法,性能上都有不错改进,在后面的文章会拣一些不错的技术点来和大家分享下。


其实除了ELK以外,还有一家国外的开源产品也是非常值得学习和推荐的,GrayLog2,目前在存储检索这一层直接使用了elasticsearch,但在数据接收,数据管道处理基本都是自己开发的,没有直接使用logstash,同时也有一套自己的控制台,而没有采用kibana,整体的代码质量很高,在数据接收,处理层支持用户开发自定义插件,同时在一些数据处理的抽象上也做的不错,比如Stream抽象,ContentPack支持用户上传,GELF,DSL数据处理等,对于日志采集,提供了一个sidebar,配合控制台帮助你快速接入日志,也支持filebeat/nglog等不同采集工具的管控,总体来说,graylog2为中小企业提供了一个小而美的日志中心工具,个人觉得比较缺陷的是控制台,数据接受,处理都在一个工程中,没有单独分离,且不适合复杂且数据规模海量的大集群日志中心建设,但在一些代码质量和一些抽象设计思路很值得学习。

后说一个ELK技术栈之外的开源产品,那就是grafana下的loki。

一个水平可扩展,高可用性,多租户的日志聚合系统,受到Prometheus的启发。它的设计非常经济高效且易于操作,因为它不会为日志内容编制索引,而是为每个日志流编制一组标签,这又是一个小而美的全栈日志产品,整体来看,目前功能还比较单一。

https://www.zhihu.com/video/1125814402779348992

好了,大致介绍了目前3个开源的全栈日志产品,里面一些具体的设计和技术细节,会在后面的文章逐步分享出来。


本章参考资料:

Loki. Prometheus-inspired logging for cloud natives.grafana.com

相关文章