一、為什么用Sentry？
隨着平台的規模越來越大，平台的日志散落在各個地方，無法統一管理。而且使用的有多種開發語言(H5,ANDROID,IOS,JAVA,Python)，想規范和統一日志也是比較困難的。日志文件過於分散，日志內容過於繁雜，發現和解決問題被動。為了提高錯誤發現和排查的效率，我們引入Sentry。
Sentry是一個集中式日志管理系統。它具備以下優點：
- 多項目，多用戶,界面友好
- 報警的規則多樣性：可以配置異常出發規則，例如發送郵件，釘釘
- 報警的及時性：不需要自己再去額外集成報警系統，一旦產生了 issue 便以郵件通知到項目組的每個成員。
- 問題關聯信息的聚合：每個問題不僅有一個整體直觀的描繪，聚合的日志信息省略了人工從海量日志中尋找線索，免除大量無關信息的干擾。
- 豐富的上下文：Sentry 不僅豐富還規范了上下文的內容，也讓我們意識到更多的有效內容，提高日志的質量。
- 支持主流語言接口：從Sentry的文檔首頁截下來的一張圖，可以看到它支持目前主流的編程語言。
- issues & events：在相同地方產生的異常會被歸納為一個「Issue」，每次在這個地方產生的異常叫做「Event」。所以在同一個地方觸發兩次異常，仍然只有一個Issue，但是可以在Event頁面看到多個[Event]。
- 聚合策略：Sentry 按照策略將日志事件進行聚合，從而提供一個 issue的events 。這么做就是為了智能地幫助我們組合關聯的日志信息，減少人工的日志信息的提取工作量，關注一個 issue 首先關注這些聚合的事件。但是這個策略分組並不會那么智能，Sentry 主要按照以下幾個方面，優先級從高到低進行日志事件的聚合：Stacktrace、Exception、Template、Messages。
- alerts digest & limit：默認 Sentry 的 alerts 會發送郵件。當一個 issue 產生或者一組 issue 產生時，項目相關的成員都會受到郵件。但是並不是每次 issue 有更新就會產生 alert 。考慮到用戶也不希望被一籮筐的報警郵件給轟炸，因為過多相當於沒有， Sentry 除了對重復的報警進行抑制，還會追加一段時間內更新 issue 的摘要（digest）到下一個報警，這樣，用戶郵件上接收到的信息會充分壓縮，不用苦惱於過多的郵件。另外，每個用戶可以根據自己的喜好自行配置報警的時間間隔。
總之Sentry 還有有很多亮點，比如敏感信息過濾，release版本跟蹤，關鍵字查找，受影響用戶統計，權限管理等（部分可能需要我們通過代碼提供內容）可以通過 Sentry 進行問題分配與跟蹤。Sentry 的 plugin 模塊還可以集成大量的第三方工具如：slack ，jira 。
對我們來說最大的便利就是利用日志進行錯誤發現和排查的效率變高了。但是，我們能不能完全依賴Senry呢？有幾點值得探討：
- 不是日志的替代品
Sentry 的目的是為了讓我們專注於系統與程序的異常信息，目的是提高排查問題的效率，日志事件的量到達一個限制時甚至丟棄一些內容。官方也提倡正確設置 Sentry 接收的日志 level 的同時，用戶也能繼續舊的日志備份。
- 不是排查錯誤的萬能工具
Sentry 是帶有一定策略的問題分析工具，以樣本的形式展示部分原始日志的信息。信息不全面的同時，使用過程中也可能出現 Sentry 聚合所帶來的負面影響，特別是日志記錄質量不夠的情況下。
- 不是傳統監控的替代品
與傳統的監控系統相比，Sentry 更依賴於發出的日志報告，而另外一些隱藏的邏輯問題或者業務問題很可能是不會得到反饋的。
原文鏈接：https://blog.csdn.net/wshl1234567/article/details/100763464