問題產(chǎn)生的根由？不同服務(wù)的日志存在哪里？我們怎么去排查線上問題？
問題場景：我們部署的java服務(wù)可能有幾十個，不同的項目里面他是看不到別的服務(wù)的日志，只有服務(wù)的返回msg消息，相比傳統(tǒng)的單體服務(wù)來說，排查問題和解決問題的原因相對比較復(fù)雜和麻煩，我們傳統(tǒng)的單體項目的日志存txt文本，log文件，但是項目日志的文件太大了，幾個G，十幾個G的時候去打開日志特別慢，很不方便。
那么處理這種日志應(yīng)該怎么做和設(shè)計一個日志搜索呢？
傳統(tǒng)的解決辦法，數(shù)據(jù)庫記錄錯誤日志，es索引寫入，頁面搜索，寫硬盤定時清理，但是日志不僅僅分系統(tǒng)日志，服務(wù)日志，還有業(yè)務(wù)邏輯操作日志，系統(tǒng)日志等，從而加大了我們存儲日志的內(nèi)存空間和復(fù)雜度。
下面給大家講解微服務(wù)下日志怎么使用，怎么查問題。
日志方案：
方案一：分布式日志搜集：ELK+kafka 或者ELK 這是最傳統(tǒng)的方式。
方案二：filebeta+logstatsh+ES+web? 這鐘方式處理的日志一般是網(wǎng)絡(luò)處理，filebeta支持大量批量文件讀取和操作，從而大大加快文件寫入，因為filebeta不存在數(shù)據(jù)會丟失的情況。
方案三：微服務(wù)網(wǎng)關(guān)攔截：統(tǒng)一請求分發(fā)，每一個請求抓取服務(wù)的日志返回和信息，寫入硬盤或者表中，定時數(shù)據(jù)清洗。當(dāng)然實際開發(fā)當(dāng)中沒有這么用，這種方式不推薦。
方案四：阿里云日志搜集：日志服務(wù) SLS (我相信很多企業(yè)目前都是在用阿里的sls，因為用起來比較方便，我們只關(guān)心服務(wù)的部署，阿里云幫我們做日志搜集，其實日志和ELK類似都是走索引寫入查詢)
方案一和方案二 和方案三是目前企業(yè)用的比較多的，當(dāng)然一個是花錢一個是自己搭建的，花錢的肯定用起來方便。
我們今天就實踐操作講解一下阿里云的日志服務(wù) SLS怎么使用和查日志。
看這個圖?來說這個是目前我們生產(chǎn)環(huán)境的sls日志服務(wù)查詢出來一個月的日志量，那一般企業(yè)的日志量我相信過億就不錯了，這個是目前12百個服務(wù)部署到阿里云k8s容器上面。所以日志量很大。
下面我們來看sls日志如何使用操作？
搜索方式支持和數(shù)據(jù)庫一樣的操作，可以模糊查詢和精確查詢?nèi)罩?，不是等值查詢，或和且的方式都可以?/p>
?阿里云日志查詢語法：
查詢語法 (aliyun.com)（可以參考阿里云的語法使用）
我們按照服務(wù)名稱或者ip + id編號，篩選時間或者搜索指定打印指定的日志名稱。
服務(wù)名稱 + 后臺日志搜索??
這里由于有敏感數(shù)據(jù)就不貼出來了，搜索方式是這樣，如果你想要統(tǒng)計分組也是可以的。
服務(wù)名稱 + 后臺日志+ 日志關(guān)鍵詞+like+ 分組
服務(wù)名稱 and api auth-center ?response ?or LIKE memberId GROUP unionId?
基于這種查詢就能查到具體的日志輸出了，如果你要聚合統(tǒng)計，你可以添加預(yù)查詢
?預(yù)查詢的方式就是message: returnMessage? 這樣
上下文瀏覽：
?上下文瀏覽代表是程序從上往下執(zhí)行，那么0的下標(biāo)代表當(dāng)前位置，負數(shù)代表程序上面，正數(shù)代表程序還在往下面執(zhí)行，排查問題的時候每一步都會有記錄，這個很關(guān)鍵。也是能夠快速排查到問題原因的。
當(dāng)然還有一些日志統(tǒng)計，報表的，都可以通過控制臺去處理篩選查看：
?日志聚類：
?
日志智能聚類（LogReduce）功能能將相似度高的數(shù)據(jù)聚合在一起，提取共同日志Pattern（模式），快速掌握日志全貌
主要功能和特性：
- 支持任意格式日志：Log4J、Json、單行（syslog）
- 億級數(shù)據(jù)，秒級出結(jié)果
- 日志經(jīng)任意條件過濾后再Reduce
- 對Reduce后Pattern，根據(jù)signature反查原始數(shù)據(jù)
- 不同時間段Pattern比較
- 動態(tài)調(diào)整Reduce精度
主要應(yīng)用場景：
- DevOps（問題定位、異常檢測、版本回歸等）
- 安全、入侵檢測
計費標(biāo)準(zhǔn)：
開啟“日志聚類”功能后，索引總量會增加原始日志大小的10%
其實開啟過后就是增加指定日志的聚合并且持久化操作，反正費用是不能少的
監(jiān)聽事件查詢：
監(jiān)聽索引字段的事件查詢，主要是以阿里云的字段
?
?
當(dāng)然還有數(shù)據(jù)加工的我就不演示了。
下面我們講重點：其實sls服務(wù)也有查詢不到問題的時候，那是必然的，你說你日志看到了但是沒有看到別的服務(wù)的調(diào)用鏈路，這是關(guān)鍵，每一條執(zhí)行日志都有一個?tid,tid是什么？tid就是鏈路調(diào)用的tranceid和spanId ，微服務(wù)分布式調(diào)用鏈路追蹤請求服務(wù)的時候會傳一個tranceid 從而幫助我們排查問題。
我們可以通過Sleuth + Zipkin 追蹤日志記錄。
我們這里采用Skywaking 。
?
https://github.com/apache/skywalking
感興趣的可以去看看
搜索某一個錯誤的日志?
?
?
原理也是通過tranceId去查詢調(diào)用鏈路，服務(wù)的鏈路。 從而判斷這個服務(wù)的接口是否成功，這樣我們整個鏈路就可以知道哪里出了問題了。 Zipkin也是通過tranceId去查詢?nèi)罩?。原理都是一樣的?/p>
?當(dāng)然也可以java服務(wù)集成日志寫入到es里面進行查詢，通過服務(wù)名稱，渠道，時間，log日志級別做成web頁面查詢也是可以的。文章來源：http://www.zghlxwxcb.cn/news/detail-434472.html
?————沒有與生俱來的天賦，都是后天的努力拼搏（我是小楊，謝謝你的關(guān)注和支持）文章來源地址http://www.zghlxwxcb.cn/news/detail-434472.html
到了這里，關(guān)于JAVA微服務(wù)場景下分布式日志收集排查問題實戰(zhàn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
