spring cloud分布式日誌鏈路跟蹤

首先要明白一點，為什麼要使用鏈路跟蹤？

當我們微服務之間呼叫的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。

它還有乙個好處：當我們在企業中，可能每個人都負責乙個服務，我們可以通過日誌來檢查自己所負責的服務不會出錯，當呼叫其它服務時，這時候出現錯誤，那麼就可以判定出不是自己的服務出錯，從而也可以發現責任不是自己的。

基於微服務之間的呼叫開始，如果看不懂的小夥伴，請先參考我上篇部落格：spring cloud中微服務之間的呼叫以及eureka的自我保護機制

首先，我們先在project-solr和project-shopping-mall裡加配置：

logging:

path: d:\work\logs\project-solr #列印存放日誌的路徑
level:
com.gaofei: info #包名下日誌的級別

logging:

path: d:\work\logs\project-shopping-mall #列印存放日誌的路徑
level:
com.gaofei: info #包下面日誌級別

在project-solr裡的constroller裡：

@restcontroller//這裡使此constroller中所有的方法返回的不是頁面

public classsolrsearchconstroller 
}

@controller

public classpagecontroller 
}

在這裡如果沒有logs後面的目錄它會自動建立

點開兩個日誌檔案：

這裡因為我執行重新整理了3次，所以執行了3次，而兩個日誌裡也對應了三次

如果其中一條報錯那麼也很快可以找到答案，並且知道哪個日誌裡報錯，也就對應了哪個服務報錯

那麼問題來了，如果我們在開發中，一天可能會執行n次，那麼其中某次執行報錯，我們就要在n次呼叫時來找對應的服務，那麼怎麼辦，我們不可能一一對應查詢

這時候我們可以進行鏈路追蹤，只需要在對應的伺服器build.gradle加上spring cloud sleuth依賴

//分布式鏈路依賴

compile group: 'org.springframework.cloud', name: 'spring-cloud-starter-sleuth'

之後執行，開啟存放的日誌：

這裡我執行重新整理了n次，那麼怎麼在另乙個服務找到對應的呼叫呢？大家仔細看一下紅塊中的鏈路是不是對應相應的服務

我隨便拿乙個進行查詢

通過查詢可以發現，可以找到對應的鏈路，那麼也就是每次執行都會出現乙個鏈路，可以來查詢相應服務的操作是否執行成功，那麼這也就是鏈路追蹤

SpringCloud 分布式配置

我們一般把配置檔案寫在專案中直接獲取相關引數 spring cloud config實現的配置中心預設採用git來儲存配置資訊，所以使用spring cloud config構建的配置伺服器，天然就支援對微服務應用配置資訊的版本管理，並且可以通過git客戶端工具來方便的管理和訪問配置內容。1.配置倉...

springcloud分布式配置中心

本文是對內容做些應用 1.bootstrap.properties檔案內容 必須與配置中心中的檔案字首一致 開啟健康檢查 需要spring boot starter actuator依賴 eureka.client.healthcheck.enabled true 續約更新時間間隔 預設30秒 eu...

SpringCloud 分布式知識學習

target elementtype.type retention retentionpolicy.runtime documented inherited enablediscoveryclient enablecircuitbreaker 乙個註解引用三個註解，標示這是springboot應用 ...