go单体日志采集zincsearch方案实现
作者:lambdang
前言
微服务中的日志采集方案ELK(EFK)已经是基本事实标准了,但是单体服务中却没有像ELK这样的成熟采集方案,这与单体性质有关,单体毕竟涉及到服务少,而ELK又是很耗费资源的,单体要是上ELK,可能需要的服务器资源比业务服务器还多,所以单体没有上ELK的。
但是单体也有日志采集需要,毕竟出了问题都要查日志的,如果没有采集系统,就只能靠tail命令不断去找,就算有,一般也是直接放到mysql或者mongodb中,然后直接查库,好点的可能做个查询页面。
下面我要介绍的是个号称ElasticSearch替代方案的zincsearch,这个zincsearch是对标ElasticSearch的,专门解决es的部署困难,资源要求高。这个zincsearch由go语言编写而成,非常容易就跑起来了。
周末有时间正好对zinsearch进行了调研,网上类似的技术文章真的太少了,有的也是官网文档的翻译。
一 构架
zincsearch用官方的话说是一个全文本搜索引擎,而且搜索很快。支持es格式接口,一般ELK中直接filebeat采集数据直接给es,你要使用zincsearch可以直接把它放到filebeat后头,filebeat采集数据给zincsearch。因为单体比较简单,filebeat使用也有一定门槛,我就自己写了一个logfile,专门采集日志,通过接口把数据传给zincsearch,构架如下图。
数据入库后通过zincsearch自带ui界面(类似kibana)就可以检索数据了.
二 zinsearch 安装
我是通过docker安装的,为了方便启动做成了一个docker-compose,配置如下:
docker-compose.yml
version: '3.5' networks: zinnet: driver: ${NETWORKS_DRIVER} services: zinc: ## mqtt 服务 image: zinc:v1 environment: - TZ=${TZ} - DATA_PATH="/data" - ZINC_FIRST_ADMIN_USER=admin - ZINC_FIRST_ADMIN_PASSWORD=123456 - ZINC_PROMETHEUS_ENABLE=true ports: - "4080:4080" volumes: - ${DATA_PATH_HOST}:/data networks: - ${NET_NAME} restart: always
.env
# 设置时区 TZ=Asia/Shanghai # 设置网络模式 NETWORKS_DRIVER=bridge # 宿主机上Mysql Reids数据存放的目录路径 DATA_PATH_HOST = ./data # 网络名称 NET_NAME = zinnet
在目录下创建指定的data目录 运行 docker-compose up -d 即可。
二 logbeat
logbeat是一个我自己写的类似filebeat的采集器,主要原理也是用了一个由tail作用的go库对文件进行监控,当由数据采集上来后进行过滤处理然后发送给zincsearch。
logbeat也是完全由golang编写,项目地址 gitee.com/lambdang/lo… 该项目下载下来编译后进行配置即可使用。
logbeat特点:
- 当zincsearch挂掉后整个采集就阻塞住了,会按照设定的时长进行服务可用性轮询试探,直到zincsearch服务恢复
- 该logbeat支持多文本日志监控,采集后为了减少zincsearch的压力,会顺序进行数据发送。
如果有filebeat经验的人也可以直接用filebeat进行数据采集,zincsearch文档上有filebeat的配置。
配置项如下:
Beat: Files: - Index: api File: ./test.log Hosts: http://localhost:4080 Username: admin Password: "123456" RetrySecond: 300 #重试秒s Log: OutType: all
三 zincsearch 使用经验
1 关于删除
zincsearch是以索引组织数据的,删除目前通过文档只发现了两种方式,一种是根据记录的id进行单个删除,一种是根据索引批量删除该索引下的所有数据,所以数据最好按照天或者月进行索引组织,这样方便以后按照天或者月进行数据删除,毕竟谁的硬盘也不是无穷大的。
之前一直想通过按照搜索进行数据删除,比如给一个时间段,然后进行删除,但是没有发现类似方法,有能这样实现的小伙伴欢迎交流。
2 关于日期date类型
zincsearch索引数据一共有如下几种类型
其中date类型是个特殊的存在
文档中索引的日期类型可以按照实际文本数据设置format。如下图:
但是通过一番摸索发现这个format只是你日志的格式,并不是最终ui界面显示的格式,经过测试,所有date类型数据最终都会转换成”数值“,可能是为了搜索的时候可以比较大小吧,但是显示的时候也是数值,这个就看着很不友好了。
目前我能想到的就觉方案是索引里不要弄date类型,直接弄numeric类型时间戳和text类型的字符串,两个同时弄,即方便时间区间查询也方便查看,也可以根据时间字符串进行查询,毕竟这可是支持全文检索的。谁有更好的方案欢迎交流。
3 关于检索中时间选项
所有数据查询都需要一个时间范围,一般默认是30分钟内,但是你也可以设置一天,一星期,一个月,也可以设置时间段。但是不要以为设置多少时间就能检索出该时间内所有数据,还要看数据量,就是数据左下角那个数值。
这个数值可以设置,这个才是决定最终的数据量的,它设置100,你检索出来的数据只是检索条件中结束时间点开始往前100条数据。所以你时间跨度设置再大,这个数值很小,你查出来数据也很少的。
结语
整体看这套单体采集方案可行性比较高,不会占用太多的资源,也能够对日志进行实时采集。但是毕竟代码都是一天搞出来的,不知道长期测试会有什么问题,下一步打算用这套采集系统做个长期测试看看。
大家用的什么样的日志采集方案欢迎留言交流。
日志只是系统可观测性的一方面,其他还包括,链路,性能指标监控,这些东西在为微服务上都有很好的解决方案,可是单体上却没有,原因无他,就是复杂性,资源高。
以上就是go单体日志采集zincsearch方案实现的详细内容,更多关于go单体日志采集zincsearch的资料请关注脚本之家其它相关文章!