我們的系統，已經接入阿里云的日志服務很長一段時間了，存了數以TB級別的日志，突然有一天，領導說，我們需要所有訂單的ip信息用于審計訂單的真實性，突然發現日志系統無法一次性查找到我所有需要的信息，讓我很無奈，是我們沒有記錄嗎？那我們遇到了哪些問題呢。

日志級別規范

日志級別我們已經有了較好的規范了

只在必要時打印日志

• 面對不確定因素時(Warning/Info)
• 訂單、支付、物流等核心業務場景(Info)
• 程序運行錯誤(Error)

日志內容及格式：

日志格式：

我們選擇使用json格式來處理日常的日志，比較方便簡潔，格式自由，另外就是使用t制表符分割，然后使用key:value格式來處理，也比較好分隔。

多行日志我們是明確禁止的，必須打成一行，并且非json，我們不予采集，因為多行和非標準的格式給我們帶來了大量的麻煩，日志采集規則實在是難以覆蓋

日志內容：

對于日志內容，其實這是最難做的，也是我非常想要表達的，包括我現在遇到的很多問題，也是由于內容不夠結構化導致的。日志就像我們使用mongodb那樣，除了唯一主鍵，其他的schema可以任意增加刪除，這樣其實給了程序員太多自由空間，必須在某些地方強制要求才可以。

所以我們在這方面做出幾個改進：

使用DB里面的列名，作為日志的key，這樣避免出現同義key，但是接手的人太多，每個人都有自己的命名習慣，導致最終日志無法查詢

對于訂單相關日志，要求同時出現訂單號和用戶id，以便查詢

當出錯時，應該打印出錯所涉及的訂單號和用戶id，如果涉及到支付，應該打印支付渠道和支付網關的返回的訂單號以便審計查詢

在json的值里面不要嵌套其他類似json的內容，例如出現msg: 訂單成功{info:success}這樣的字符，難以解析，難以排查，并且在最終查詢時只能解析部分字符串，對于后面的類json內容無法良好的處理

日志系統的邊界

了解日志系統能力的邊界很重要，我們目前使用阿里云日志系統，功能很強大，但是也有一些限制：

• 索引僅對新內容有效果：可以支持三個月內索引重建，耗費大量時間金錢
• 日志系統可能存在不完整日志情況，不能過分依賴，對于類似審計這樣的需求應該使用DB
• 同上，日志可以輸出良好的報表，但是對于系統消耗也比較大，對于一些訂單詳情，流量，可以選擇接入bi系統來處理，并使用bi的OLAP庫
• 同時在何時時機對研發進行日志系統培訓，讓他們用好日志系統

日志存儲周期

現在很多上了kubernetes和docker，像我們是沒有kubernetes，但是用的docker，本地日志不再長期保存，并且現在的主機數量以及日志數量也是難以支持研發上機查詢，所以我們本地只保存不到1G的日志，其他日志由阿里云直接采集走在日志服務上匯集。

阿里云日志是支持無限期存儲的，目前我們有部分比較重要的日志選擇了永久保存，并定期存儲到阿里云oss。

對原有日志的改造

既然一些問題已經浮出浮出水面，那么我們需要安排研發進行修改，在研發人手不是那么充裕的條件下，我們選擇循序漸進，即：日志問題始終提高警惕，新的日志按照新的研發規范進行，舊的日志，隨時發現隨時提，隨時改，隨著時間推移得到一個良性的日志系統。

本文強烈推薦使用阿里云日志服務

上云必備?www.aliyun.com日志服務_實時日志分析系統_日志管理軟件_網站日志分析工具 - 阿里云?cn.aliyun.com 創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的potainer 日志_日志系统落地：制定日志规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。