一、面臨的問題

程序運(yùn)行的日志是一個(gè)必不可少的東西，可能是一些系統(tǒng)信息，比如 gc 的情況;可能是一些正常的模塊處理信息，比如最近更新的配置;還可能是一些在程序運(yùn)行中，我們不希望出現(xiàn)的錯(cuò)誤所帶來的信息。通過日志，可以知道我們的程序是不是在正常地運(yùn)行，看到錯(cuò)誤日志，我們還需要利用日志排查錯(cuò)誤。

我們知道日志如此重要，并樂于記錄日志，然而在發(fā)現(xiàn)并解決問題的過程中，日志并沒有想象中的高效率。

1.文件過于分散

一般會(huì)將不同模塊的日志以文件的形式分開保存。即使是將日志寫在統(tǒng)一的目錄下，不管是系統(tǒng)正常運(yùn)行還是出現(xiàn)問題的時(shí)候都可能需要檢查多個(gè)日志。

2.內(nèi)容過于繁雜

不太同于代碼崇尚簡潔，特別是遇到問題的時(shí)候，日志更是越詳細(xì)越好，巴不得日志能記錄下所有上下文信息和關(guān)聯(lián)的代碼。但是在查看日志的時(shí)候卻往往不得不反復(fù)前后翻看錯(cuò)誤的關(guān)聯(lián)日志信息，同時(shí)還要略過大量無關(guān)信息，還沒開始解決問題腦細(xì)胞就死了好多。

3.解決問題的被動(dòng)性

很可能在程序剛開始運(yùn)行起來的時(shí)候，我們會(huì)檢查一下情況，看看日志是否正常。但是更多的時(shí)候我們根本不會(huì)想去看那些冗長的日志。過了一段時(shí)間，突然有人告訴我們問題出現(xiàn)了，便又懷著沉重的心情慌張地檢查日志開始排查錯(cuò)誤。

二、如何解決

考慮傳統(tǒng)的解決方案，規(guī)定好統(tǒng)一的日志格式，將所有模塊的日志進(jìn)行適配之后統(tǒng)一管理起來，并建立相應(yīng)的日志分類與報(bào)表，在檢查到問題的時(shí)候通過郵件的形式通知運(yùn)維。這樣的解決方案對于小公司來說，需要的時(shí)間和技術(shù)成本還是很大的，真正能提高日志利用的效率，還需要很長的規(guī)劃與不斷的總結(jié)。

而我們這樣的小公司就中意這樣的簡單粗暴的方案： 1 個(gè)小時(shí)搭建整個(gè)平臺(tái)!日志匯集、聚合、主動(dòng)報(bào)警、漂亮的界面，都有了—— Sentry 。

那么 Sentry 到底如何幫助我們有效利用日志發(fā)現(xiàn)并解決程序問題的呢?

1.Sentry 初試

Server 的安裝教程官網(wǎng)已經(jīng)非常詳細(xì)了，如果不要求 HA ，只需要額外確定依賴的 redis 和 postgresql 安裝好了就行。

• 支持多種語言與框架的客戶端

 

Sentry 不但有多種語言的客戶端，還直接支持大量的日志框架，比如 java 的 log4j ，logback 。這就意味著我們之前的代碼幾乎可以不用做任何修改，而僅僅加一點(diǎn)配置即可。

• 官方 saas

 

如果想要快速欣賞一下 Sentry 的芳容，可以現(xiàn)在就嘗試一下官方的 saas (當(dāng)然它是免費(fèi)的)：

Sentry 團(tuán)隊(duì)很貼心地讓你可以快速建立一個(gè)自己的 demo 嘗試它的運(yùn)用。

2.簡單的使用示例

拿官方的 saas 快速認(rèn)識(shí) Sentry ：

注冊好你的賬戶后，會(huì)有提示幫助你建立好自己的項(xiàng)目，并選擇想要使用的客戶端平臺(tái)或框架(這里以 logback 為例)：

到這里為止，我們就差一步就可以看到效果了：添加一個(gè)依賴和一個(gè) logback 的 appender 到你的項(xiàng)目配置里，其他的代碼可以一點(diǎn)不變，記日志還是熟悉的配方。

配置好依賴和 appender ，運(yùn)行一些寫入日志的代碼后，你就會(huì)收到兩方面的反饋：

(1)面板上出現(xiàn)待解決的 issues ：

(2)收到新 issues 的郵件：

怎么樣，對 Sentry 已經(jīng)有了一個(gè)直觀的感受了吧。

三、Sentry 如何解決問題

我們使用 Sentry 就是為了解決日志利用的低效率問題，那么 Sentry 是怎么幫助我們解決的呢。答案就在幾個(gè)重要的概念中，當(dāng)然 Sentry 有詳盡的官方使用說明和文檔。

• dsn(data source name)：

 

示例中是加在 appender 中的標(biāo)簽。這個(gè)就是 Sentry 的實(shí)際連接地址， Sentry 通過這個(gè)來知道到底將日志發(fā)送到哪里。

• issues & events：

 

從上面的圖可以發(fā)現(xiàn)有 3 個(gè) error 標(biāo)記的 issue 標(biāo)簽，實(shí)際上代碼里面發(fā)送了 5 條 error 的日志。這是 Sentry 很重要的一點(diǎn)：

四、我們需要看的不是單單一條日志，而是一類日志

一些聚集的日志才能盡可能地反映整個(gè)錯(cuò)誤的情況，即一個(gè) issue ，而這些有關(guān)聯(lián)的日志在 Sentry 這邊就轉(zhuǎn)化為這個(gè) issue 的關(guān)聯(lián)的 events 。

回想一下我們通過日志文件來排查錯(cuò)誤的時(shí)候，是不是就是自己耐心地運(yùn)用肉眼過濾掉一系列無關(guān)的日志，然后大腦中聚合好這些有關(guān)聯(lián)的日志，盡可能全面地了解一個(gè)錯(cuò)誤呢。

除了幫我們省掉這些事情，Sentry 提供了更豐富的數(shù)據(jù)來充實(shí)這些 events ，點(diǎn)擊一個(gè) issue ，便會(huì)進(jìn)入這個(gè) issue 的詳細(xì)信息：

不僅可以看到我們主動(dòng)加上的 message ， stacktrace ， Sentry 還幫我們加上了一些額外的 tags (我們也需要自己去定義一些有用的 tags )，盡可能多的展現(xiàn)一個(gè) issue 發(fā)生前的狀況。另外一個(gè)亮點(diǎn)在右邊，展示了這個(gè) issue 的一些統(tǒng)計(jì)信息。

 

(1)Sampling

Sentry 不是為了日志存儲(chǔ)，也不會(huì)將所有日志都記錄下來(畢竟使用關(guān)系型數(shù)據(jù)庫作為持久化存儲(chǔ))。每個(gè)發(fā)送到 Sentry 的日志都是一個(gè)提供 issue 信息的事件(event)，而每個(gè)項(xiàng)目發(fā)送到 Sentry 的事件都有一個(gè)數(shù)量上限，一旦超過這個(gè)上限 Sentry 就會(huì)忽略掉重復(fù)的內(nèi)容。

Sentry 是我們所有日志的一個(gè)關(guān)于錯(cuò)誤，問題的分析子集。體現(xiàn)在界面上的 events 信息，也是 Sentry 聚合之后的樣本。

 

(2)聚合策略

Sentry 按照策略將日志事件進(jìn)行聚合，從而提供一個(gè) issue的events 。這么做就是為了智能地幫助我們組合關(guān)聯(lián)的日志信息，減少人工的日志信息的提取工作量，關(guān)注一個(gè) issue 首先關(guān)注這些聚合的事件。但是這個(gè)策略分組并不會(huì)那么智能，Sentry 主要按照以下幾個(gè)方面，優(yōu)先級從高到低進(jìn)行日志事件的聚合：

1. Stacktrace
2. Exception
3. Template
4. Messages

要注意的是，如果日志記錄比較隨意，聚合的效果可能不盡如人意。例如：兩個(gè)無關(guān)的事件但是 stacktrace 相同，那么 Sentry 會(huì)將它們分到同一個(gè) issue 下。

(3)alerts digest & limit

 

默認(rèn) Sentry 的 alerts 會(huì)發(fā)送郵件(你也可以推送 slack!)。當(dāng)一個(gè) issue 產(chǎn)生或者一組 issue 產(chǎn)生時(shí)，項(xiàng)目相關(guān)的成員都會(huì)受到郵件。但是并不是每次 issue 有更新就會(huì)產(chǎn)生 alert 。

考慮到用戶也不希望被一籮筐的報(bào)警郵件給轟炸，因?yàn)檫^多相當(dāng)于沒有， Sentry 除了對重復(fù)的報(bào)警進(jìn)行抑制，還會(huì)追加一段時(shí)間內(nèi)更新 issue 的摘要(digest)到下一個(gè)報(bào)警，這樣，用戶郵件上接收到的信息會(huì)充分壓縮，不用苦惱于過多的郵件。另外，每個(gè)用戶可以根據(jù)自己的喜好自行配置報(bào)警的時(shí)間間隔。

五、總結(jié)

Sentry 還有有很多亮點(diǎn)，比如敏感信息過濾， release 版本跟蹤，關(guān)鍵字查找，受影響用戶統(tǒng)計(jì)，權(quán)限管理等(部分可能需要我們通過代碼提供內(nèi)容)可以通過 Sentry 進(jìn)行問題分配與跟蹤。Sentry 的 plugin 模塊還可以集成大量的第三方工具如： slack ， jira 。

對我們來說***的便利就是利用日志進(jìn)行錯(cuò)誤發(fā)現(xiàn)和排查的效率變高了。

1.及時(shí)提醒

報(bào)警的及時(shí)性：不需要自己再去額外集成報(bào)警系統(tǒng)，一旦產(chǎn)生了 issue 便以郵件通知到項(xiàng)目組的每個(gè)成員。

2.問題關(guān)聯(lián)信息的聚合

每個(gè)問題不僅有一個(gè)整體直觀的描繪，聚合的日志信息省略了人工從海量日志中尋找線索，免除大量無關(guān)信息的干擾。

3.豐富的上下文

Sentry 不僅豐富還規(guī)范了上下文的內(nèi)容，也讓我們意識(shí)到更多的有效內(nèi)容，提高日志的質(zhì)量。

六、***，完全依賴Sentry?

雖然 Sentry 讓我們在使用日志上的效率提高了，但是有幾點(diǎn)還是需要注意。

1.不是日志的替代

Sentry 的目的是為了讓我們專注于系統(tǒng)與程序的異常信息，目的是提高排查問題的效率，日志事件的量到達(dá)一個(gè)限制時(shí)甚至丟棄一些內(nèi)容。官方也提倡正確設(shè)置 Sentry 接收的日志 level 的同時(shí)，用戶也能繼續(xù)舊的日志備份(用 logback 的同學(xué)僅僅是保留自己以前的 appender 就好)。

2.不是排查錯(cuò)誤的***工具

Sentry 是帶有一定策略的問題分析工具，以樣本的形式展示部分原始日志的信息。信息不全面的同時(shí)，使用過程中也可能出現(xiàn) Sentry 聚合所帶來的負(fù)面影響，特別是日志記錄質(zhì)量不夠的情況下。

3.不是傳統(tǒng)監(jiān)控的替代品

與傳統(tǒng)的監(jiān)控系統(tǒng)相比，Sentry 更依賴于發(fā)出的日志報(bào)告，而另外一些隱藏的邏輯問題或者業(yè)務(wù)問題很可能是不會(huì)得到反饋的。

【本文是51CTO專欄機(jī)構(gòu)“豈安科技”的原創(chuàng)文章，轉(zhuǎn)載請通過微信公眾號(hào)(bigsec)聯(lián)系原作者】