作為開發人員，在產品迭代過程中時常會遇到問題需要分析定位，而在分析和定位過程中一般要借助工具，要是能根據問題的現象就能找到原因，那麼對快速改進產品品質無疑是一種很大的提公升。那麼如何做才能達到這樣的效果呢？我個人認為要把握這兩點：
（1）後端在遇到異常錯誤處理流程時要將狀態碼和簡潔明瞭的描述資訊組合成一條提示資訊反饋給前端，前端收到這條資訊時需要展示給使用者；
（2）前端在處理異常錯誤流程時及時、直接地將也異常錯誤資訊展示出來即可。
有的時候，還不能完全通過問題現象來確定問題的所在，此時可以借助另外一種快速分析定位問題的方式——日誌記錄，通過前端的控制台和後端的日誌輸出，我們也是可以快速定位的，此時就是需要我們如何快速檢索日誌的關鍵字了，否則的話分析過程依舊耗時費力。關於前後端日誌的列印也是有講究和策略的，不能隨隨便便地新增日誌記錄，否則的話即使看到日誌資訊了也沒法判斷是**出錯了。我們一定要注意日誌級別型別，若是只是單純地記錄流程就用info或者debug級別，若是是在某些業務處理流程中需要警告的就要用warn級別，若是遇到錯誤異常情況時就要用error級別；此外，還要注意描述資訊，一定要簡明扼要，能夠傳達錯誤所產生的原因，否則的話這些日誌也僅僅只是日誌，沒有實際的意義價值。我時常看到一些日誌不管三七二十一，都是採用info級別進行記錄，並且描述語句也不通順，少胳膊斷腿的，讓人很難明白其中的意思，好像是怕讓別人知道似的，還有就是單詞書寫一定要正確，不能拼錯，你要是寫錯了，至少說明你工作態度不夠認真，你不懂的單詞可以查詢確認。此外，關於日誌列印，有個建議，就是盡量對輸入的引數進行記錄列印，以及對不同元件服務之間的互動結果進行列印，這樣的好處就是方便後續明確定位生產環境出現的問題，以便清楚是哪方出現了異常。
最後，是關於溝通方面。當問題反饋著反映問題時，反饋方不能簡單粗暴地只說明哪個過程出問題了或者不正確，同時要把問題描述清楚；而處理方一定要弄清問題的具體現象，不明白的地方或者資訊不夠全的地方，一定要及時向反饋著諮詢和確認，要是能夠獲取到他們觸發的條件引數，那麼對我們分析定位問題肯定是有幫助的；要是處理方沒有掌握足夠多有用的資訊或者是反饋方提供的資訊不正確，那麼在沒有及時溝通互動的前提下處理方式會走很多彎路，即費時又費力。
小結一下：對於問題的分析和定位，除了能夠展示乙個人的快速判斷能力，還能提高乙個人對業務的理解能力，更能夠增強乙個人與同事之間的互動能力。
------20191210閃
問題定位切面和日誌上列印請求唯一log標識
這篇部落格主要是針對我們前期部分介面不穩定和有部分介面需要大量業務溝通介面，針對請求引數和返回引數進行列印。部分介面呼叫邏輯鏈過長，不易分析新增同乙個請求的引數新增唯一標識，防止併發比較大情況，找不到同一請求介面的上下文資訊。1 構建乙個註解用於放置在需要列印介面上面 documented targ...
關於批處理不列印日誌的問題
批處理裡面 日誌不列印出來.日誌檔案還是老的.將日誌目錄的使用者設定成啟動應用的使用者,然後情況日誌檔案,還是沒有輸出.只輸出乙個 biz目錄下面 有 run.log 和 err.log 兩個檔案.想了下是不是其他的日誌配置檔案影響 了 後來查詢了下 在ali sms.jar中 將log4j.pro...
關於MapReduce中日誌不列印問題調查
map reduce專案中依賴了其他的專案，而這些專案有的使用了log4j的架構，有的使用了log4j2的架構，導致在hadoop client提交任務後無法顯示進度資訊，給除錯帶來困擾。為了解決這一問題，先嘗試了將log4j公升級到log4j2，後來發現hadoop中使用的是log4j，日誌還是沒...