《運維開發實踐：基于Sentry搭建錯誤日志監控系統》要點：
本文介紹了運維開發實踐：基于Sentry搭建錯誤日志監控系統，希望對您有用。如果有疑問，可以聯系我們。

錯誤日志監控也可稱為業務邏輯監控, 旨在對業務系統運行過程中產生的錯誤日志進行收集歸納和監控告警.似乎有那么點曾相識?沒錯… 就是上一篇文章提到的“APM應用性能監控”.但它又與APM不同,APM系統主要注重應用層的行為分析,收集的更多是運營方向的數據.而sentry所做的是收集應用底層代碼的崩潰信息,便于碼儂們排查代碼異常.簡單來說它就是一個面向技術碼儂的排障工具.

1. 場景描述

隨著運維自動化流程的推進, 各類運維工具和系統也像雨后春筍般涌現. 目前我們自主開發的運維系統的數量已經接近兩位數. 這些系統部署在多臺機器上, 通常還配套一批后臺運行的腳本. web端如果出現異常, 開發人員可以及時得到反饋進行修復. 而腳本因為沒有交互, 可能會出現發生重大故障時才定位到問題的情況.

2.?既有方案

1. 后端和腳本用python內置的日志模塊記錄程序中間狀態, 同時也將兩者的輸出重定向到指定文件, 以獲取未捕獲的異常信息.
2. 同臺服務器上多個系統的日志集中存放到同個目錄
3. 使用rsync定時從多臺服務器中拉取日志文件
4. 對日志文件進行關鍵字匹配, 并將過濾結果通過郵件發送給運維開發人員

最終整合的通知郵件如圖

3.?存在的問題

上面的操作部分解決了腳本運行狀態監控盲區的問題, 但還存在如下問題

1. 無法第一時間感知錯誤
   腳本日志的拉取不是實時的, web端用戶的反饋也往往存在滯后. 出現問題到解決問題的周期太長, 容易導致工作陷入被動.
2. 錯誤信息的獲取相對低效
   用戶反饋和郵件告警包含的錯誤信息非常有限, 最終都不得不在大量的日志中上下翻看關聯的信息. 可能還需要在測試環境下給代碼埋點多獲取一些中間變量數據, 給定位問題帶來很多麻煩.
3. 日志的處理方式不夠靈活
   通常來說, 除了程序運行出錯, 我們還關心其他異常情況, 比如數據污染, 非法請求, 第三方API調用異常等. 如果將此類等同錯誤記錄下來, 很容易造成告警濫發, 而如果不處理此類異常, 久而久之可能導致嚴重的問題. 我們希望同樣的日志內容可以根據場景不同靈活處理
4. 監控覆蓋面有限
   完整的監控應該涵蓋腳本, 后端以及前端三個部分. 特別是我們新的運維系統實現了前后端分離之后, 很多前端的問題無法被統一記錄下來.

鑒于此, 我們了解了一些日志收集和監控方案, 選擇了sentry.

4.?sentry初探

4.1 概覽

sentry是一個現代化的錯誤日志記錄和聚合平臺.支持幾乎所有主流開發語言和平臺, 并提供了現代化UI, 如圖

與ELK, splunk不同, sentry專注于應用程序產生的錯誤日志的聚合和監控. 官方提供了多個語言的SDK.

多達30種集成方式

讓開發者第一時間獲悉錯誤信息, 并方便的整合進自己和團隊的工作流中.

4.2 使用前后對比

為了直觀的展示sentry的強大, 這里模擬一個常見的場景, 如有雷同, 純屬巧合.

4.2.1?場景一

接入sentry前

• 用戶A: 發布功能用不了
• 開發者A: 哪個頁面? 截個圖
• 用戶A: (發截圖)
• 開發者A發現bug可以重現, 登錄服務器查看錯誤日志, 確認程序邏輯無問題, 查看數據庫數據, 發現有臟數據. 聯系開發者B檢查負責更新數據的python腳本C.py.
• 開發者B登錄服務器查看錯誤日志, 發現一個邏輯錯誤導致腳本罷工, 已持續了一個小時. 影響了數千條數據

接入后

• 開發者A,B同時收到郵件告警, 一分鐘前腳本C.py異常退出.
• 開發者B進入sentry后臺查看錯誤信息, 定位問題并將其修復, 再清理受影響的數十條數據.
• 在此過程中沒有用戶受到影響, 無需開發者A介入

4.2.2?場景二

接入sentry前

• 用戶: 提交按鈕點了沒反應
• 開發者: 哪個頁面? 截個圖
• 用戶: (發截圖)
• 開發者: 我這邊沒這個問題, 你打開開發者工具, 切到console面板, 截個圖我看下
• 用戶: 怎么弄??….省略100字
• 開發者拿到相關數據, 確定是代碼問題. 但是js文件經過了壓縮, 無法定位到有問題的代碼. 只能打開本地開發服務器調試.

接入后

• 開發者收到郵件告警, 顯示前端有錯誤日志
• 開發者進入sentry后臺查看錯誤信息, 比如用戶瀏覽器版本, 產生錯誤的頁面url, 代碼調用過程和最終引發錯誤的代碼, 確認問題所在.
• 開發者: 兩分鐘前你提交的工單備注字段的校驗有點問題, 你先把那一欄留空再提交, 稍后我會更新一個hotfix版本, 到時跟你說下.
• 用戶: 好的, 剛想問.

5.?sentry的配置

sentry官方提供了詳細的部署文檔, 網上也可以搜索到中文的安裝教程, 安裝過程不贅述. 想要嘗鮮的小伙伴也可以直接使用sentry官方提供的saas, 免費版支持每天5000個event. 地址是 https://sentry.io

5.1 概念

使用sentry, 需要弄清楚幾個概念:

• event
  直譯是”事件”, 是可操作數據的基本單位. 每一次日志輸出就產生一個event. event并不一定就是錯誤, 如果日志記錄級別設置很低, 那么后臺會產生很多的event, 所以正確的設置日志級別很重要
• issue
  直譯是”工單”或者”問題”, 是同一類event的聚合. 某一個錯誤可能因為重復執行而被記錄多出, 在sentry會自動聚合到一起, 方便處理. 通常我們操作的對象就是issue

• DSN
  DSN即客戶端密鑰, 用來進行客戶端和服務器的通信. DSN是一個url, 包含一個公鑰一個私鑰, 項目標記和服務器地址, 比如https://1703147af2094458bevb1bfadcfa1c2:7e00a1d4cbd745c0b780451c3586d7f4@sentry.io/1545. 這類DSN是私密的, 還有一類是非私密的, 在sentry后臺中顯示為DSN(public), 給前端項目使用.

• Raven
  整個錯誤日志監控系統包括客戶端和服務端, Sentry是服務端的名稱, 客戶端名稱是Raver, 需要兩者配合才能工作.

5.2 配置

sentry服務端的配置主要是名稱, 告警規則等, 至于被監控項目是前端還是后端區別不大.

5.2.1?創建項目

1. 進入sentry系統后臺, 點擊右上角新建項目

1. 命名為[項目名][前|后端], 比如”藍海前端”.
2. 在配置應用框架頁面, 點擊可以查看各個語言或框架的接入文檔(可以忽略這一步)
3. 點擊左上角項目名稱, 進入項目首頁, 可以看到頁面顯示”Waiting for events…”

5.2.2?獲取和測試DSN

1. 在”項目設置”頁, 在左側列表中點擊”客戶端密鑰”, 進入頁面
2. 拷貝DSN, 后端的是DSN, 前端是DSN(public)
3. 以python為例, 執行pip install raven安裝客戶端后, 執行raven test DSN, 如果一切順利, 可以在sentry后臺項目首頁看到新增了一條測試消息

5.2.3 配置警報

1. 在”項目設置”頁面, 在左側列表中點擊”警報”, 進入警報配置頁
2. 點擊規則標簽頁, 可以看到已有一個規則, 當事件首次發生時告警
3. 根據需要修改規則

告警規則的配置相當靈活, 且可以對多個條件進行與或判斷

5.2.4?集成告警

1. 在”項目設置”頁面, 在左側列表中點擊”所有集成”
2. 勾選需要接入的類型,比如Mail

郵件服務器的配置請參考官方文檔, 自己搭建的sentry服務器如果發現集成類型很少, 可以安裝官方或第三方插件進行擴展

在服務端配置結束后, 可以開始配置客戶端.

6.?后端的接入

因為我們的系統主要用python開發, 在此以python為例.

python接入sentry十分簡單. 官方提供了十幾種python環境(框架)下使用sentry的例子, 比如在celery中

from raven import Client from raven.contrib.celery import register_signal, register_logger_signal client = Client(DSN) # register a custom filter to filter out duplicate logs register_logger_signal(client) # The register_logger_signal function can also take an optional argument # `loglevel` which is the level used for the handler created. # Defaults to `logging.ERROR` register_logger_signal(client, loglevel=logging.INFO) # hook into the Celery error handler register_signal(client) # The register_signal function can also take an optional argument # `ignore_expected` which causes exception classes specified in Task.throws # to be ignored register_signal(client, ignore_expected=True)

個人推薦借鑒logging使用的例子, 原因是通常開發者會根據logging模塊定制自己的日志配置, 不直接使用框架內的日志模塊. 如果你在應用程序中只用了logging模塊, 那么接入sentry對已存在的代碼來說是透明的, 無需多加修改.

用logging模塊接入sentry只需兩步:

6.1 安裝客戶端

pip install raven

6.2?初始化配置?

在應用程序的入口文件(tornado中的app.py等)中, 或者自定義的日志模塊中, 插入如下代碼

from raven.handlers.logging import SentryHandler from raven.conf import setup_logging handler = SentryHandler(DSN) handler.setLevel(logging.ERROR) setup_logging(handler)

完成了這兩步操作之后, 就可以像之前那樣使用logging模塊

import logging logger = logging.getLogger(__name__) logger.info(‘This is a test message’)

當上面的代碼被執行時, 除了原有的打log操作之外, raven還會向sentry服務器發送日志內容, 并向標準輸出添加

Sending message of length xxx to https://xxxx

如果希望向sentry發送更多上下文信息, 可以帶上extra參數

logger.error(‘This is a test message’, extra={‘stack’: True})

最終顯示在后臺的日志信息如圖

包含了日志級別, python環境信息, SDK信息, 棧調用, 前后n次日志輸出, 相關的其他事件等等, 如果是未捕獲的異常或帶上extra參數, 還會顯示中間變量的值, 很方便的定位到出錯的位置和數據, 無需再去代碼埋點.

7.?前端的接入

前端的接入相對來說復雜一些

第一, 需要對sentry服務器的域名進行解析. 內部的系統, 后端監控可以給線上機器添加hosts指定sentry服務器的IP. 而前端, 因為錯誤日志是從用戶瀏覽器發出的, 需要用戶能自動解析sentry服務器的域名

第二, 如果前端項目用到了打包工具, 而通常打包工具會對代碼進行壓縮甚至混淆, 就會出現sentry收集到的日志無法準確定位問題代碼的情況 所幸, sentry支持導入sourcemap自動解析和還原代碼, 讓開發者在后臺能看到development環境一樣詳細的棧調用. (當然如果沒有用打包工具可以忽略這一步)

前端的接入這里以reactjs為例

7.1 安裝依賴

npm i raven-js –save

7.2?嵌入raven

在index.js文件(入口文件)中,

import Raven from ‘raven-js’; # 在適當的地方加入, 盡可能讓它早執行 Raven.config(DSN(public)).install();

其他前端框架的接入請參考官方文檔

https://docs.sentry.io/clients/javascript

7.3?導入sourcemap

提前生成好sourcemap文件, 實測source-map級別可以完美工作, cheap-source-map能定位到, 但顯示不友好. 當然, 最推薦的是cheap-module-source-map

# 安裝 npm i -g sentry-cli-binary # 登錄sentry sentry-cli –url SENTRY_URL login # SENTRY_URL指自建服務或官方saas地址, 執行命令后會訪問API TOKEN創建頁面, 生成一個TOKEN, 拷貝進來, 成功后TOKEN會被保留到系統用戶某個配置目錄下, 后續的請求都會重復使用這個TOKEN # 創建一個release sentry-cli releases -o sentry -p 7d04f2c51f32 new test01 –finalize # 這里的sentry 和7d04f2c51f32 是指 組織名稱和項目名稱, 均指*簡稱*, 與sentry頁面上默認顯示的不同, 需要到配置頁面查看 # 上傳dist目錄下的文件 sentry-cli releases -o sentry -p 7d04f2c51f32 files test01 upload-sourcemaps dist # 刪除舊的release下的所有文件 sentry-cli releases -o sentry -p 7d04f2c51f32 files test01 delete –all # 當然這個命令是不想要release上的文件的時候執行的

注意, 生成的map文件與上傳的相對路徑需要一致. 比如, dist目錄是打包后的文件存放目錄, map文件為sourcemap/[file].map, 則sentry-cli上傳目錄應該是dist, 這樣map文件才會顯示在sentry后臺的~/sourcemap/目錄下.

這樣的webpack配置

devtool = ‘source-map’; output.path: ‘dist’; output.sourceMapFilename = ‘sourcemap/[file].map’;

則對應這樣的命令

sentry-cli releases -o sentry -p 7d04f2c51f32 files test02 upload-sourcemaps dist

另外, sentry-cli提供了一個參數–url-prefix, 可以為上傳的map文件添加前綴, 默認是~/, 有興趣的同學可以試試看

再補充一點, sentry需要根據js文件的sourceMappingURL來解析map文件路徑, 所以sourcemap級別不能用hide-source-map或者類似的.

代碼上傳完畢后, 在版本->工件頁面可以看到該release上的文件, 如圖

最終錯誤日志效果如圖

8.?sentry管理后臺的使用

篇幅所限, sentry后臺的使用簡要講幾點

第一,自定義過濾?

sentry提供了豐富的過濾選項, 默認過濾條件是”Unresolved Issues”, 用戶也可以自己組合過濾條件, 并保存成個人或團隊的默認選項

第二,頁面實時更新?

上圖中間的按鈕可以開啟或關閉issues頁面的實時刷新,

第三,統計和概覽

上圖是系統管理員頁面, 可以看到系統調用, 等待中的任務隊列等的情況, 在個人帳號首頁也能看到項目的統計信息.

9.?需要注意的點

1. 用sentry做錯誤日志監控不能取代原有的日志存儲方案, 只是在日志收集和監控方面做了擴展. 使用sentry應著重利用其實時性和快捷性, 做到快速響應. sentry會清除較舊的日志內容, 這與ELK之類的日志處理系統也有差別.
2. sentry能否用得好還取決于打log的開發者的功力. 如果原始日志記錄缺少關鍵信息或無效信息過多, 再強大的日志分析系統也無能為力. 因此在引入sentry做日志監控的同時, 也要同步加強開發團隊打log的意識, 規范日志級別, 格式和內容

文章來自微信公眾號：運維軍團

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/1963.html