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