我們的系統(tǒng)，已經(jīng)接入阿里云的日志服務(wù)很長一段時間了，存了數(shù)以TB級別的日志，突然有一天，領(lǐng)導(dǎo)說，我們需要所有訂單的ip信息用于審計訂單的真實性，突然發(fā)現(xiàn)日志系統(tǒng)無法一次性查找到我所有需要的信息，讓我很無奈，是我們沒有記錄嗎？那我們遇到了哪些問題呢。

日志級別規(guī)范

日志級別我們已經(jīng)有了較好的規(guī)范了

只在必要時打印日志

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

日志內(nèi)容及格式：

日志格式：

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

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

日志內(nèi)容：

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

所以我們在這方面做出幾個改進(jìn)：

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

對于訂單相關(guān)日志，要求同時出現(xiàn)訂單號和用戶id，以便查詢

當(dāng)出錯時，應(yīng)該打印出錯所涉及的訂單號和用戶id，如果涉及到支付，應(yīng)該打印支付渠道和支付網(wǎng)關(guān)的返回的訂單號以便審計查詢

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

日志系統(tǒng)的邊界

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

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

日志存儲周期

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

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

對原有日志的改造

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

本文強烈推薦使用阿里云日志服務(wù)

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。