分散式日誌元件GrayLog入門

Java3y發表於2022-03-15

我是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

相關文章