SpringBoot接入輕量級分佈式日誌框架(GrayLog)

我是3y,一年CRUD經驗用十年的markdown程序員👨🏻‍💻常年被譽爲優質八股文選手

前兩天我不是發了一篇數據鏈路追蹤的文章嘛,在末尾也遺留了TODO運行應用的服務器一般是集羣,日誌數據會記錄到不同的機器上,排查和定位問題只能登錄各個服務器查看。

今天來聊聊這個話題。

00、爲什麼需要分佈式日誌組件?

在文章正式開始之前,我分享下我以前負責過的一個系統,它的架構如下:

每次當我查問題的時候,我可能能把問題初步定位在邏輯層,但爲了能給業務方交代,我需要給證據業務方看(日誌信息就是鐵證)。

一個請求肯定是被這8臺機器內的某一臺處理,但具體是哪一臺,我不知道。所以,我需要上每臺機器上grep一把日誌,然後才能找出對應的日誌證明我的分析。

有的時候,可能接入層也需要一起參與進去,就排查一個問題,人都傻了了(翻看日誌的時間佔用了太久了)。

後來啊,看了同事的騷操作(在item2 編寫腳本:快速登錄堡壘機(免去輸入賬號和密碼信息),根據應用服務器數量來切割窗口並且切換到對應的日誌目錄)。說白了就是一鍵登錄多臺應用服務器。嗯,這查日誌的速度比起以前又快了好多。

再後來,公司運維側又主力推在Web頁面上登錄應用服務器(自動登錄堡壘機),這能省去編寫腳本(支持批量操作)。但從當時的體驗上,沒有用item2訪問得流暢(總感覺卡卡的)。

不過還有問題,因爲我們在很多時候是不知道在info/warn/error哪個文件下。很多時候只能一個一個文件去查,雖然說可以直接通配符一把查,如果日誌過大,帶來停頓時間也挺煩的。

系統一旦被問到業務問題,查日誌的頻率實在是太高了。於是我在某個Q規劃的時候是想自己把日誌信息寫入到搜索引擎,順便學習下搜索引擎的知識。然後這個規劃被組內的某個大佬看到了,在底下評論:要不來試試Graylog

原來組內本身就在維護了一個日誌框架,只是我不知道...於是我接入了Graylog日誌,工作效率槓槓提高了,憑藉這個事情吹了一個Q

自從接入了之後,我就沒登錄過應用服務器了,有次差點連grep都不會寫了。

01、輕量級ELK(Graylog)

說起ELK,即便沒用過肯定也聽說過這玩意了,在後端是真的流行。這次austin接入一個比較輕量級的ELK框架:Graylog

這個框架我感覺蠻好用的,作爲使用方接入起來異常簡單(我估摸運維應該也挺簡單的,很多用Graylog是直接發UDP到Server,不用在機器上裝agent收集日誌)

一圖勝十言

官方文檔:https://docs.graylog.org/docs

據我瞭解,有相當多的企業使用它來查看日誌和業務監控告警,這篇文章我就直接讓你們體驗體驗吧。

02、部署Graylog

老樣子,直接上docker-compose,如果一直跟着我的步伐,應該對着不陌生了。docker-compose.yml的內容其實我也是抄官網的,這裏還是貼下吧(就不用你們翻了)

version: '3'
services:
    mongo:
      image: mongo:4.2
      networks:
        - graylog
    elasticsearch:
      image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2
      environment:
        - http.host=0.0.0.0
        - transport.host=localhost
        - network.host=0.0.0.0
        - "ES_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true -Xms512m -Xmx512m"
      ulimits:
        memlock:
          soft: -1
          hard: -1
      deploy:
        resources:
          limits:
            memory: 1g
      networks:
        - graylog
    graylog:
      image: graylog/graylog:4.2
      environment:
        - GRAYLOG_PASSWORD_SECRET=somepasswordpepper
        - GRAYLOG_ROOT_PASSWORD_SHA2=8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
        - GRAYLOG_HTTP_EXTERNAL_URI=http://ip:9009/ # 這裏注意要改ip
      entrypoint: /usr/bin/tini -- wait-for-it elasticsearch:9200 --  /docker-entrypoint.sh
      networks:
        - graylog
      restart: always
      depends_on:
        - mongo
        - elasticsearch
      ports:
        - 9009:9000
        - 1514:1514
        - 1514:1514/udp
        - 12201:12201
        - 12201:12201/udp
networks:
    graylog:
      driver: bridg

這個文件裏唯一需要改動的就是ip(本來的端口是9000的,我由於已經佔用了9000端口了,所以我這裏把端口改成了9009,你們可以隨意)

嗯,寫完docker-compose.yml文件,直接docker-compose up -d它就啓動起來咯。

啓動以後,我們就可以通過ip:port訪問對應的Graylog後臺地址了,默認的賬號和密碼是admin/admin

隨後,我們配置下inputs的配置,找到GELF UDP,然後點擊Launch new input,只需要填寫Title字段,保存就完事了(其他不用動)。

嗯,到這裏,我們的GrayLog設置就完成了。

03、SpringBoot使用GrayLog

還記得我們austin項目使用的日誌框架嗎?沒錯,就是logback。我們要把日誌數據寫入Graylog很簡單,只需要兩步:

1、引入依賴:

<dependency>
  <groupId>de.siegmar</groupId>
  <artifactId>logback-gelf</artifactId>
  <version>3.0.0</version>
</dependency>

2、在logback.xml配置graylog相關的信息:

<appender name="GELF" class="de.siegmar.logbackgelf.GelfUdpAppender">
  <!-- Graylog服務的地址 -->
  <graylogHost>ip</graylogHost>
  <!-- UDP Input端口 -->
  <graylogPort>12201</graylogPort>
  <!-- 最大GELF數據塊大小(單位:字節),508爲建議最小值,最大值爲65467 -->
  <maxChunkSize>508</maxChunkSize>
  <!-- 是否使用壓縮 -->
  <useCompression>true</useCompression>
  <encoder class="de.siegmar.logbackgelf.GelfEncoder">
    <!-- 是否發送原生的日誌信息 -->
    <includeRawMessage>false</includeRawMessage>
    <includeMarker>true</includeMarker>
    <includeMdcData>true</includeMdcData>
    <includeCallerData>false</includeCallerData>
    <includeRootCauseData>false</includeRootCauseData>
    <!-- 是否發送日誌級別的名稱,否則默認以數字代表日誌級別 -->
    <includeLevelName>true</includeLevelName>
    <shortPatternLayout class="ch.qos.logback.classic.PatternLayout">
      <pattern>%m%nopex</pattern>
    </shortPatternLayout>
    <fullPatternLayout class="ch.qos.logback.classic.PatternLayout">
      <pattern>%d - [%thread] %-5level %logger{35} - %msg%n</pattern>
    </fullPatternLayout>

    <!-- 配置應用名稱(服務名稱),通過staticField標籤可以自定義一些固定的日誌字段 -->
    <staticField>app_name:austin</staticField>
  </encoder>
</appender>

在這個配置信息裏,唯一要改的也只是ip的地址,到這裏接入就完畢了,我們再打開控制檯,就能看到日誌的信息啦。

04、懂點GrayLog

懂點GrayLog查詢語法:這塊我日常來來去去其實就用幾個,我來展示下我平時用的吧。如果覺得不夠,再去官網文檔撈一把就完事了:https://docs.graylog.org/docs/query-language

1、根據字段精確查詢:full_message:"13788888888"

2、查詢錯誤日誌信息:level_name:"ERROR"

3、組合多字段查詢:level_name:"INFO" AND full_message:"13788888888"

在接入的時候,仔細的小夥伴可能會發現我這邊在Input的時候選擇的是GELF,然後在引入Maven依賴的時候也有GELF的字樣。那GELF是啥意思呢?

這塊在官網也有給出對應的解釋:The Graylog Extended Log Format (GELF) is a log format that avoids the shortcomings of classic plain syslog

詳細資料:https://docs.graylog.org/docs/gelf

GELF是一種日誌格式,能避免傳統意義上的 syslogs的一些問題,而我們引入的Maven依賴則是把日誌格式化成GELF格式然後append到GrayLog上。

05 、番外:Swagger

前幾天有個老哥在GitHub給我提了個pull request關於swagger的,我昨天把他merge了,也升級了下swagger的版本。

之前我沒用過swagger類似的文檔工具,就這次pull request我也去體驗了下swagger

在初次的體驗感覺是不錯的:它能把項目的所有接口的文檔信息都能在一個頁面上統一管理,並且就能直接通過樣例參數直接發送請求。通過註解的方式來進行編寫文檔,也不用擔心代碼改了然後忘了更新文檔這事。

但是,後來我配置好對應的參數信息文檔,再在swagger-ui體驗了下,發現是真滴醜,看到這ui我還是階段性放棄吧。

swagger的競品還有好幾個,我看ui貌似都要比swagger好看。不過,austin項目的主要接口就只有一個,我作爲熟練掌握的markdown工程師能輕鬆勝任文檔工作,就沒再繼續體驗別的競品了。

06、總結

之前我好像是在知乎看到過類似的一段話:一個工具或框架使用優秀,就取決於它的入門的難易。如果一個框架要花很長時間才能弄懂,那可能它做得並沒那麼好。

我其實不會經常去研究各種使用的框架它的細節原理,也不會矇頭就去看源碼,沒什麼必要,畢竟它沒出問題啊

像GrayLog這種工具類的框架,如果在公司不是主要的維護者,其實不必太過於糾結他的實現細節,可以從總體上把握他的設計思想。換我建議,真要學習,還得是看它的具體存儲(比如Elasticsearch的原理)

學習就要帶有利益點(學了能提高效率,學了能以後在面試的時候吹牛逼進而漲工資,學了能使自己快樂,學了能裝逼)

都看到這裏了,點個贊一點都不過分吧?我是3y,下期見。

關注我的微信公衆號【Java3y】除了技術我還會聊點日常,有些話只能悄悄說~ 【對線面試官+從零編寫Java項目】 持續高強度更新中!求star!!原創不易!!求三連!!

austin項目源碼Gitee鏈接:gitee.com/austin

austin項目源碼GitHub鏈接:github.com/austin

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章