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

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

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

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

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

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

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

而我們這樣的小公司就中意這樣的簡單粗暴的方案：?1 個小時搭建整個平臺！日志匯集、聚合、主動報警、漂亮的界面，都有了——?Sentry?。

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

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

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

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

Sentry 團隊很貼心地讓你可以快速建立一個自己的 demo 嘗試它的運用。

拿官方的?saas 快速認識 Sentry ：

注冊好你的賬戶后，會有提示幫助你建立好自己的項目，并選擇想要使用的客戶端平臺或框架（這里以?logback 為例）：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? Stacktrace

? Exception

? Template

? Messages
?

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

默認?Sentry 的 alerts 會發(fā)送郵件（你也可以推送 slack！）。當一個 issue 產(chǎn)生或者一組 issue 產(chǎn)生時，項目相關的成員都會受到郵件。但是并不是每次 issue 有更新就會產(chǎn)生 alert 。

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

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

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

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

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

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

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

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

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

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

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

反爬蟲

十分鐘解決爬蟲問題！超輕量級反爬蟲方案
Python工具分析風險數(shù)據(jù)
當我們在談論前端加密時，我們在談些什么