前言
微服务中的日志采集方案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的资料请关注编程网其它相关文章！
