go單體日志采集zincsearch方案實現

Posted on by

前言

微服務中的日志采集方案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的資料請關註WalkonNet其它相關文章！

推薦閱讀：