目录
  • 前言
  • 一 构架
  • 二 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= - 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: "" 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的资料请关注本网站其它相关文章！

    您可能感兴趣的文章:

    • go编程中go-sql-driver的离奇bug解决记录分析
    • mongodb driver使用代码详解
    • Go每日一库之zap日志库的安装使用指南
    • Go 日志封装实战示例详解
    • uber go zap 日志框架支持异步日志输出
    • Go语言LeetCode题解937重新排列日志文件
    • go zero微服务框架logx日志组件剖析
    • 详解MongoDB Go Driver如何记录日志