目录

前言一 构架二 zinsearch 安装二 logbeat三 zincsearch 使用经验1 关于删除2 关于日期date类型3 关于检索中时间选项结语

前言

微服务中的日志采集方案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的资料请关注脚本之家其它相关文章！

关键词： 使用经验 采集系统 数据采集 相关文章 性能指标