作為普通開發，可能都有過這種感受，正在瘋狂的coding運營 測試跑過來，有投訴，線上出問題了、有報警，線上出問題了，內心不免一驚仔細排查後發現：第三方問題，要找第三方解決、網路問題要找網路組解決、配置錯誤，你們運營配置有誤、正常業務錯誤，使用者輸入資料有誤，等等等，一方便耽誤了我們coding改變世界，一方面因為我們去日誌定位問題需要時間，但可能問題在我們這裡並解決不了，白白延長了解決問題的時間。
　　不免抱怨明明日誌裡都有read time out了，你找網路啊、找通道方啊，他們服務掛了，明明通道返回system error這是他們的錯誤啊，你找我能解決嗎？Flume Kafaka elasticsearch 都搞好了你們倒是用啊！！！！，但這能怪運營嗎？你可能覺得system error很簡單，但他們知道嗎？不覺心裡替運營一陣委屈。這明明是你自己挖的坑啊！寫程式碼的時候，我們只是從自己的角度捕獲了異常，記錄了各種出錯堆疊資訊，對我們足夠了，但有時候可能這錯誤第一手並不是我們看到的，一個穩定的產品，大多數的錯誤可能都來自於使用者投訴後運營的反饋，這個時候，如果他們在日誌平臺上看到的不是system error，而是“支付閘道器通道下單，單號：{123231312}，通道方返回錯誤資訊：{system error}”，完美，鍋已經走遠了，這個錯我們不背所以日誌記錄不光是面向程式設計師，也要面向運營，面向產品，面向測試，面向一切可能檢視日誌的人員，要知道，我們的編碼產品是面向使用者的，但我們的日誌是面向我們內部人員的，遠遠不止我們開發自己，所以在實際開發，一套合理的日誌規範至關重要，玩不可玩逼格高，只是定義一堆為了方便資料分析，業務監控等而打印出只有統計程式碼和我們自己看得懂的日誌。
一、不要丟了中文
　　不要認為各種英文和符號才是逼格高，但並不實用，可能程式碼懂、我們懂，但並不一定其他看日誌的同事懂，甚至下一位繼續維護程式碼的程式設計師也看不懂越是簡單易懂的日誌，就會有更多的同事替我們分擔查日誌的問題，想想都輕鬆的不行（奸笑）
二、要有統一明確的規範
　　統一的日誌規範是老生常談的問題，統一規範不但有助於後期日誌的分析統計，更對我們平常查詢錯誤結果一目瞭然，可能相關問題我們輔助運營查一次，解釋一次，以後類似問題，他們就可以自助查詢，去分析，到底應該找哪個部門，哪個同事去解決相關問題，這個規範不是以前的只考慮機器，只考慮錯誤堆疊分析，還要考慮除了開發和日誌分析系統以外的其他同事。良好的規範要包括以下資訊：列印日誌的系統、列印日誌的業務、業務單號、報錯系統名稱（自己系統報錯？渠道報錯？上游系統引數錯誤？）、錯誤資訊，其他的如響應時長、呼叫引數等依據業務去做相關的列印當然還要注意敏感資訊的脫敏處理。

三、簡單易用的日誌平臺

　　日誌寫好了，如果是讓運營去敲命令也太low了吧，而且網際網路公司的業務日誌也很多，系統呼叫複雜，所以必須有一個完善的日誌平臺，去串聯起來系統間的呼叫日誌，現在開源的ELK很方便的，開可以以此進行二次開發那就更好了