我是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" >
<!-- Graylog服務的地址 -->
<graylogHost>ip</graylogHost>
<!-- UDP Input埠 -->
<graylogPort>12201</graylogPort>
<!-- 最大GELF資料塊大小（單位：位元組），508為建議最小值，最大值為65467 -->
<maxChunkSize>508</maxChunkSize>
<!-- 是否使用壓縮 -->
<useCompression>true</useCompression>
<encoder >
<!-- 是否發送原生的日志資訊 -->
<includeRawMessage>false</includeRawMessage>
<includeMarker>true</includeMarker>
<includeMdcData>true</includeMdcData>
<includeCallerData>false</includeCallerData>
<includeRootCauseData>false</includeRootCauseData>
<!-- 是否發送日志級別的名稱，否則默認以數字代表日志級別 -->
<includeLevelName>true</includeLevelName>
<shortPatternLayout >
<pattern>%m%nopex</pattern>
</shortPatternLayout>
<fullPatternLayout >
<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
更多的文章可往：文章的目錄導航轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/443451.html
標籤：其他