摘要：對(duì)我們來(lái)說(shuō)最大的便利就是利用日志進(jìn)行錯(cuò)誤發(fā)現(xiàn)和排查的效率變高了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從上面的圖可以發(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 。

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

除了幫我們省掉這些事情，Sentry 提供了更豐富的數(shù)據(jù)來(lái)充實(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ì)信息。

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

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

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

? Stacktrace

? Exception

? Template

? Messages
?

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

默認(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)檫^(guò)多相當(dāng)于沒(méi)有，?Sentry 除了對(duì)重復(fù)的報(bào)警進(jìn)行抑制，還會(huì)追加一段時(shí)間內(nèi)更新 issue 的摘要（digest）到下一個(gè)報(bào)警，這樣，用戶郵件上接收到的信息會(huì)充分壓縮，不用苦惱于過(guò)多的郵件。另外，每個(gè)用戶可以根據(jù)自己的喜好自行配置報(bào)警的時(shí)間間隔。

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

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

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

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

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

雖然?Sentry 讓我們?cè)谑褂萌罩旧系男侍岣吡?，但是有幾點(diǎn)還是需要注意。

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

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

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

Daisy ? 豈安科技框架研發(fā)負(fù)責(zé)人
主導(dǎo)底層框架系統(tǒng)和 Warden java 服務(wù)端的研發(fā)工作。擅長(zhǎng) Java 研發(fā)、分布式系統(tǒng)、監(jiān)控系統(tǒng)以及各類開(kāi)源項(xiàng)目的引入和改造。

反爬蟲

十分鐘解決爬蟲問(wèn)題！超輕量級(jí)反爬蟲方案
Python工具分析風(fēng)險(xiǎn)數(shù)據(jù)
當(dāng)我們?cè)谡務(wù)撉岸思用軙r(shí)，我們?cè)谡勑┦裁?/p>