今天終于把這個擱置了幾個月沒有解決的問題解決了，真的是找遍了Google、百度文檔，沒有找到一個解決方案，這里分享一下解決辦法。

公司項目使用的是spring cloud，注冊中心使用的Eureka，監控方面經過一番的調研，最終選擇了對微服務監控比較方便的prometheus，由于服務較多，就考慮了服務自發現，經過一番的摸索，發現eureka-consul-adapter依賴可以適配prometheus的consul_sd_config配置。

prometheus整個部署過程雖然遇到的問題不少，但是網上文檔也比較多，都一一解決了。監控起初，并沒有什么異常，grafana各類監控顯示也正常，突然有一天發現服務器根目錄快滿了，于是去排查了下，發現是docker的問題（prometheus用的docker部署的），再進一步排查，發現是prometheus這個容器日志占用了大量的磁盤容量，docker tail -f 看了下，發現全是類似下面的報錯：

prometheus      | level=error ts=2019-11-20T09:54:18.313Z caller=consul.go:477 component="discovery manager scrape" discovery=consul msg="Error refreshing service" service=serviceA tags="unsupported value type" err="Unexpected response code: 503 ({\"timestamp\":1574243658309,\"status\":503,\"error\":\"Service Unavailable\",\"exception\":\"org.springframework.web.context.request.async.AsyncRequestTimeoutException\",\"message\":\"No message available\",\"path\":\"/v1/catalog/service/serviceA \"})"

prometheus      | level=error ts=2019-11-20T09:54:25.314Z caller=consul.go:477 component="discovery manager scrape" discovery=consul msg="Error refreshing service" service=serviceB tags="unsupported value type" err="Unexpected response code: 503 ({\"timestamp\":1574243665310,\"status\":503,\"error\":\"Service Unavailable\",\"exception\":\"org.springframework.web.context.request.async.AsyncRequestTimeoutException\",\"message\":\"No message available\",\"path\":\"/v1/catalog/service/serviceB\"})"

prometheus      | level=error ts=2019-11-20T09:54:25.314Z caller=consul.go:477 component="discovery manager scrape" discovery=consul msg="Error refreshing service" service=serviceC tags="unsupported value type" err="Unexpected response code: 503 ({\"timestamp\":1574243665310,\"status\":503,\"error\":\"Service Unavailable\",\"exception\":\"org.springframework.web.context.request.async.AsyncRequestTimeoutException\",\"message\":\"No message available\",\"path\":\"/v1/catalog/service/serviceC\"})"

然后馬上根據報錯信息訪問了下/v1/catalog/service/serviceC地址，可以正常訪問。

然后又去Google了下相關報錯，盡然只有幾篇相關的文章，還有是重復了，一下就不知所措了，然后去prometheus 技術群請教了一些大神，不過很遺憾，都沒有人遇到過類似的問題，然后去github看了下prometheus consul.go的源代碼，也就是正常訪問consul接口返回的報錯，雖然使用的是eureka-consul-adapter依賴去適配的，但是consul接口訪問都是正常的，前前后后研究了一周，實在沒有找到解決方案。

于是只能從其他方面去解決，首先把docker目錄遷移到了數據盤，然后給docker日志做了大小限制，雖然一直報錯，但是現在不會對磁盤空間造成影響，然后就把這個問題方下了。

過了兩個月左右，也就是最近在部署elasticsearch的時候，無意間又發現了prometheus容器一直報錯，以為出什么問題了（把之前沒處理的事情搞忘記了），然后又去排查原因，找了半天還是和之前一樣沒有結果，這時突然想起之前prometheus技術群里，有人說這個報錯，應該是java端拋出來的，于是仔細一看日志內容果然有個java的報錯：

org.springframework.web.context.request.async.AsyncRequestTimeoutException

大概意思就是，異步請求超時，然后馬上去項目里面找了下看有沒有async的相關設置，很遺憾項目并沒有使用async。

又分析了下，由于prometheus是去請求的consul接口，應該是eureka server 的問題，此時慢慢思路才清醒起來，再一分析，eureka主要就引用了eureka-consul-adapter依賴，只有看一下eureka-consul-adapter.jar的代碼內容就知道的，馬上通過反編譯工具把下載到本地eureka-consul-adapter.jar包打開一看，果然有相關的引用。

于是馬上搜索了下springboot 關于async的超時時間的設置，根據建議在eureka server的配置文件添加了spring.mvc.async.request-timeout=-1，馬上發布測試，果然就沒有了報錯。

現在再回頭去看，其實一開始問題方向就錯了，一直在prometheus方面找問題，其實問題根本就在eureka server，現在再去看grafana eureka的監控視圖，http請求，一直持續的有http-5xx錯誤,而url正是prometheus錯誤日志的path，而這些異常一開始并沒有引起我的注意。

雖然已經沒有超時報錯，但還是需要觀察幾天，這個設置是否對性能和服務是否有影響。

轉載請注明：Prometheus報錯Error refreshing service Unexpected response code: 503解決辦法 - 阿湯博客 http://m.maowutv.com/atang_4306.html