我是怎么定位問題的？

定位問題

前陣子群里有個(gè)同學(xué)@我，讓我分享下平時(shí)是怎么定位問題的，以及排查問題的思路。

甚至我還看到有的面試題也會(huì)問這種問題（是不是在校驗(yàn)真的做過線上項(xiàng)目？）

最近組內(nèi)來了個(gè)新人實(shí)習(xí)生，正好我前幾天也給他講了我的排查問題步驟，今天來分享下我的經(jīng)驗(yàn)。

這篇文章主要給還未參加工作的小白看的哈。

什么是日志

在初學(xué)的時(shí)候出現(xiàn)了些問題，要在網(wǎng)上提問，大多數(shù)網(wǎng)友都會(huì)讓你把錯(cuò)誤日志發(fā)出來看下，一起定位下原因。

但可能你還不知道什么是「日志」，因?yàn)槠綍r(shí)寫代碼壓根就不打日志，而排查問題try catch{e.printStackTrace();} 又不是不能用，平時(shí)運(yùn)行代碼就在本地環(huán)境下，寫個(gè)錘子日志喲。

使不上，使不上...

所謂的「打日志」，按我的理解就是把系統(tǒng)運(yùn)行過程中，你認(rèn)為在關(guān)鍵的位置，記錄些關(guān)鍵的信息。這些信息會(huì)寫在運(yùn)行程序的機(jī)器本地文件上。

（如果你是本地環(huán)境，那文件就寫在本地的文件系統(tǒng)上）

（如果你是遠(yuǎn)程環(huán)境(一般Linux)，那文件就寫在Linux服務(wù)器上）

程序運(yùn)行時(shí)錯(cuò)誤或異常相關(guān)的信息，自然就是打日志的重點(diǎn)。

但現(xiàn)在日志其實(shí)不止承載著排查問題的角色了，很多數(shù)據(jù)收集都來源于日志?；谶@種「采集數(shù)據(jù)」的日志，又有人給它取了另一個(gè)高大上的名字「打點(diǎn)」。

這里就不細(xì)說了，水很深，這里對(duì)小白而言，是把握不住的。網(wǎng)絡(luò)的東西都是虛擬的，你們要是感興趣，我改天再細(xì)講。

謹(jǐn)慎地記錄日志。生產(chǎn)環(huán)境禁止輸出 debug 日志；有選擇地輸出 info 日志；如果使用 warn 來記錄剛上線時(shí)的業(yè)務(wù)行為信息，一定要注意日志輸出量的問題，避免把服務(wù)器磁盤撐爆，并記得及時(shí)刪除這些觀察日志。

大量地輸出無效日志，不利于系統(tǒng)性能提升，也不利于快速定位錯(cuò)誤點(diǎn)。記錄日志時(shí)請(qǐng)思考：這些日志真的有人看嗎？看到這條日志你能做什么？能不能給問題排查帶來好處？

回到問題本身

系統(tǒng)問題產(chǎn)生，很多時(shí)候都來源于改動(dòng)

發(fā)現(xiàn)系統(tǒng)出現(xiàn)問題，大多數(shù)來自于告警或者業(yè)務(wù)方(客服)反饋

一般遇到線上問題，在排查的時(shí)候，我們就需要考慮：系統(tǒng)最近是否有過改動(dòng)

如果發(fā)布過，那就很可能是近期的發(fā)布導(dǎo)致的。所以，出現(xiàn)問題時(shí)，首先回想下是不是自己最近的發(fā)布改動(dòng)造成的。

較嚴(yán)重的問題，直接回滾，別想著要保留完整的現(xiàn)場(chǎng)，業(yè)務(wù)穩(wěn)定優(yōu)先。

如果不太嚴(yán)重，去看看監(jiān)控有沒有異常突刺。監(jiān)控?zé)o外乎：數(shù)據(jù)庫監(jiān)控、業(yè)務(wù)指標(biāo)監(jiān)控、接口調(diào)用監(jiān)控。

如果較為明顯的錯(cuò)誤，一般監(jiān)控就能看出端倪。

如果沒看出端倪又或者說參數(shù)信息不全，那就得上服務(wù)器看日志（可能接了日志收集系統(tǒng)，在某個(gè)分布式日志系統(tǒng)平臺(tái)上看）。但這不重要，反正有地方看請(qǐng)求鏈路信息就好了。

• 如果是自己寫的代碼，那自己也大概能猜出是什么原因造成的了。

• 如果不是自己寫的代碼，找到監(jiān)控的入口，往上游追蹤并看入?yún)?，一般也能定位到問題。

也有的情況下，自身對(duì)某個(gè)系統(tǒng)并不熟悉，代碼都是前人寫的，自己只是來維護(hù)的，業(yè)務(wù)只懂一點(diǎn)點(diǎn)。

這種硬著頭皮也看不懂的，只能debug一步一步看。一般公司都有幾套環(huán)境（線下->預(yù)發(fā)->線上)，一般情況下我們是使用線下環(huán)境debug，但往往線下環(huán)境可能數(shù)據(jù)沒那么全，所以有的時(shí)候也會(huì)到預(yù)發(fā)環(huán)境debug。

所謂的線下環(huán)境或者預(yù)發(fā)環(huán)境debug指的就是遠(yuǎn)程debug。無論是什么環(huán)境，跑的都是同一份代碼，只是這份代碼在不同的機(jī)器上跑，機(jī)器與機(jī)器之間分了隔離環(huán)境，正常的業(yè)務(wù)請(qǐng)求都會(huì)轉(zhuǎn)發(fā)至線上環(huán)境上。

所以，遠(yuǎn)程debug實(shí)際上就是在遠(yuǎn)程機(jī)器上開放端口，本地直連端口進(jìn)行debug。

首先在線下or預(yù)發(fā)環(huán)境下增加端口配置

JAVA_OPTS="${JAVA_OPTS} -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=1043,suspend=n"

idea配置remote鏈接，指明ip和端口即可

基礎(chǔ)設(shè)施

有的時(shí)候出現(xiàn)了問題，明明try catch之后就能定位到問題了，結(jié)果在catch后沒打異常信息，還要重新發(fā)布定位問題...

有的時(shí)候出現(xiàn)了問題，明明加個(gè)告警就能提前發(fā)現(xiàn)，結(jié)果等到業(yè)務(wù)方反饋時(shí)，背了個(gè)故障...

有的時(shí)候出現(xiàn)了問題，明明加個(gè)監(jiān)控就能快速定位問題，結(jié)果看了半天日志，甚至還得人肉計(jì)算QPS和量級(jí)...

有的時(shí)候出現(xiàn)了問題，明明可以通過開發(fā)些小工具來提高定位問題的效率，結(jié)果每次都要查半天，一天都查問題去了...

寫代碼除了實(shí)現(xiàn)功能之外，監(jiān)控告警穩(wěn)定性也是非常重要的一環(huán)，在開發(fā)時(shí)必須要把穩(wěn)定性和維護(hù)性考慮進(jìn)去！

事前預(yù)警，事中快速定位和處理，事后優(yōu)化加強(qiáng)！

• 【對(duì)線面試官】Java注解
• 【對(duì)線面試官】Java泛型
• 【對(duì)線面試官】 Java NIO
• 【對(duì)線面試官】Java反射 && 動(dòng)態(tài)代理
• 【對(duì)線面試官】多線程基礎(chǔ)
• 【對(duì)線面試官】 CAS
• 【對(duì)線面試官】synchronized
• 【對(duì)線面試官】AQS&&ReentrantLock
• 【對(duì)線面試官】線程池
• 【對(duì)線面試官】ThreadLocal
• 【對(duì)線面試官】CountDownLatch和CyclicBarrier
• 【對(duì)線面試官】List
• 【對(duì)線面試官】Map
• 【對(duì)線面試官】SpringMVC
• 【對(duì)線面試官】Spring基礎(chǔ)
• 【對(duì)線面試官】SpringBean生命周期
• 【對(duì)線面試官】Redis基礎(chǔ)
• 【對(duì)線面試官】Redis持久化
• 【對(duì)線面試官】Kafka基礎(chǔ)
• 【對(duì)線面試官】使用Kafka會(huì)考慮什么問題？