高效利用Sentry追蹤日誌發現問題

面臨的問題

程序運行的日誌是一個必不可少的東西，多是一些系統信息，好比 gc 的狀況；多是一些正常的模塊處理信息，好比最近更新的配置；還多是一些在程序運行中，咱們不但願出現的錯誤所帶來的信息。經過日誌，能夠知道咱們的程序是否是在正常地運行，看到錯誤日誌，咱們還須要利用日誌排查錯誤。

咱們知道日誌如此重要，並樂於記錄日誌，然而在發現並解決問題的過程當中，日誌並無想象中的高效率。

01文件過於分散

通常會將不一樣模塊的日誌以文件的形式分開保存。即便是將日誌寫在統一的目錄下，不論是系統正常運行仍是出現問題的時候均可能須要檢查多個日誌。

02內容過於繁雜

不太同於代碼崇尚簡潔，特別是遇到問題的時候，日誌更是越詳細越好，恨不得日誌能記錄下全部上下文信息和關聯的代碼。可是在查看日誌的時候卻每每不得不反覆先後翻看錯誤的關聯日誌信息，同時還要略過大量無關信息，還沒開始解決問題腦細胞就死了好多。

03解決問題的被動性

極可能在程序剛開始運行起來的時候，咱們會檢查一下狀況，看看日誌是否正常。可是更多的時候咱們根本不會想去看那些冗長的日誌。過了一段時間，忽然有人告訴咱們問題出現了，便又懷着沉重的心情慌張地檢查日誌開始排查錯誤。

如何解決

考慮傳統的解決方案，規定好統一的日誌格式，將全部模塊的日誌進行適配以後統一管理起來，並創建相應的日誌分類與報表，在檢查到問題的時候經過郵件的形式通知運維。這樣的解決方案對於小公司來講，須要的時間和技術成本仍是很大的，真正能提升日誌利用的效率，還須要很長的規劃與不斷的總結。

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

那麼 Sentry 到底如何幫助咱們有效利用日誌發現並解決程序問題的呢？

Sentry 初試

Server 的安裝教程官網已經很是詳細了，若是不要求 HA ，只須要額外肯定依賴的 redis 和 postgresql 安裝好了就行。

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

Sentry 不但有多種語言的客戶端，還直接支持大量的日誌框架，好比 java 的 log4j ，logback 。這就意味着咱們以前的代碼幾乎能夠不用作任何修改，而僅僅加一點配置便可。

官方 saas

若是想要快速欣賞一下 Sentry 的芳容，能夠如今就嘗試一下官方的 saas （固然它是免費的）：

Sentry 團隊很貼心地讓你能夠快速創建一個本身的 demo 嘗試它的運用。

簡單的使用示例

拿官方的 saas 快速認識 Sentry ：

註冊好你的帳戶後，會有提示幫助你創建好本身的項目，並選擇想要使用的客戶端平臺或框架（這裏以 logback 爲例）：

到這裏爲止，咱們就差一步就能夠看到效果了：添加一個依賴和一個 logback 的 appender 到你的項目配置裏，其餘的代碼能夠一點不變，記日誌仍是熟悉的配方。

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

01面板上出現待解決的 issues ：

02收到新 issues 的郵件：

怎麼樣，對 Sentry 已經有了一個直觀的感覺了吧。

Sentry 如何解決問題

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

dsn（data source name）：

示例中是加在 appender 中的標籤。這個就是 Sentry 的實際鏈接地址， Sentry 經過這個來知道到底將日誌發送到哪裏。

issues & events：

從上面的圖能夠發現有 3 個 error 標記的 issue 標籤，實際上代碼裏面發送了 5 條 error 的日誌。這是 Sentry 很重要的一點：

咱們須要看的不是單單一條日誌，而是一類日誌。

一些彙集的日誌才能儘量地反映整個錯誤的狀況，即一個 issue ，而這些有關聯的日誌在 Sentry 這邊就轉化爲這個 issue 的關聯的 events 。

回想一下咱們經過日誌文件來排查錯誤的時候，是否是就是本身耐心地運用肉眼過濾掉一系列無關的日誌，而後大腦中聚合好這些有關聯的日誌，儘量全面地瞭解一個錯誤呢。

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

不只能夠看到咱們主動加上的 message ， stacktrace ， Sentry 還幫咱們加上了一些額外的 tags （咱們也須要本身去定義一些有用的 tags ），儘量多的展示一個 issue 發生前的情況。另一個亮點在右邊，展現了這個 issue 的一些統計信息。

Sampling

Sentry 不是爲了日誌存儲，也不會將全部日誌都記錄下來（畢竟使用關係型數據庫做爲持久化存儲）。每一個發送到 Sentry 的日誌都是一個提供 issue 信息的事件（event），而每一個項目發送到 Sentry 的事件都有一個數量上限，一旦超過這個上限 Sentry 就會忽略掉重複的內容。

Sentry 是咱們全部日誌的一個關於錯誤，問題的分析子集。體如今界面上的 events 信息，也是 Sentry 聚合以後的樣本。

聚合策略

Sentry 按照策略將日誌事件進行聚合，從而提供一個 issue的events 。這麼作就是爲了智能地幫助咱們組合關聯的日誌信息，減小人工的日誌信息的提取工做量，關注一個 issue 首先關注這些聚合的事件。可是這個策略分組並不會那麼智能，Sentry 主要按照如下幾個方面，優先級從高到低進行日誌事件的聚合：
 

•   Stacktrace

•   Exception

•   Template

•   Messages
   

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

alerts digest & limit

默認 Sentry 的 alerts 會發送郵件（你也能夠推送 slack！）。當一個 issue 產生或者一組 issue 產生時，項目相關的成員都會受到郵件。可是並非每次 issue 有更新就會產生 alert 。

考慮到用戶也不但願被一籮筐的報警郵件給轟炸，由於過多至關於沒有， Sentry 除了對重複的報警進行抑制，還會追加一段時間內更新 issue 的摘要（digest）到下一個報警，這樣，用戶郵件上接收到的信息會充分壓縮，不用苦惱於過多的郵件。另外，每一個用戶能夠根據本身的喜愛自行配置報警的時間間隔。

總結

Sentry 還有有不少亮點，好比敏感信息過濾， release 版本跟蹤，關鍵字查找，受影響用戶統計，權限管理等（部分可能須要咱們經過代碼提供內容）能夠經過 Sentry 進行問題分配與跟蹤。Sentry 的 plugin 模塊還能夠集成大量的第三方工具如： slack ， jira 。

對咱們來講最大的便利就是利用日誌進行錯誤發現和排查的效率變高了。

01及時提醒

報警的及時性：不須要本身再去額外集成報警系統，一旦產生了 issue 便以郵件通知到項目組的每一個成員。

02問題關聯信息的聚合

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

03豐富的上下文

Sentry 不只豐富還規範了上下文的內容，也讓咱們意識到更多的有效內容，提升日誌的質量。

最後，徹底依賴Sentry？

雖然 Sentry 讓咱們在使用日誌上的效率提升了，可是有幾點仍是須要注意。

01不是日誌的替代

Sentry 的目的是爲了讓咱們專一於系統與程序的異常信息，目的是提升排查問題的效率，日誌事件的量到達一個限制時甚至丟棄一些內容。官方也提倡正確設置 Sentry 接收的日誌 level 的同時，用戶也能繼續舊的日誌備份（用 logback 的同窗僅僅是保留本身之前的 appender 就好）。

02不是排查錯誤的萬能工具

Sentry 是帶有必定策略的問題分析工具，以樣本的形式展現部分原始日誌的信息。信息不全面的同時，使用過程當中也可能出現 Sentry 聚合所帶來的負面影響，特別是日誌記錄質量不夠的狀況下。

03不是傳統監控的替代品

與傳統的監控系統相比，Sentry 更依賴於發出的日誌報告，而另一些隱藏的邏輯問題或者業務問題極可能是不會獲得反饋的。

做者簡介

Daisy   豈安科技框架研發負責人
主導底層框架系統和 Warden java 服務端的研發工做。擅長 Java 研發、分佈式系統、監控系統以及各種開源項目的引入和改造。

反爬蟲

你會感興趣的內容：

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