錯誤追蹤

擷取您的應用程式所拋出的例外，並歸納成問題，所有方案都提供，免費方案也不例外。它採用 Sentry 的協定，因此您可以沿用手上既有的 SDK，只需改動一行設定。

如何設定

在控制台中建立一個專案並複製它的 DSN，接著把您既有的 SDK 指向它：

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

整個整合就是這樣。任何 Sentry SDK 都能使用——JavaScript、Python、Ruby、Go、PHP、.NET——因為我們用的就是他們的傳輸協定，而不是某種近似的東西。

DSN 裡的金鑰並不是機密。瀏覽器 SDK 會把它打包進頁面程式中，因此它只用來標示一個專案，不授予其他任何權限。請不要寫出任何假定它屬於私密的東西。

錯誤如何變成問題

屬於同一個狀況的事件會歸納成同一個問題。歸納的依據是例外型別、訊息，以及呼叫堆疊的形狀——絕不使用行號，否則只要在檔案開頭加上一行 import，就會把一個問題拆成兩個，讓長期存在的缺陷看起來像是新出現的。

您已經解決、後來又再次發生的問題，會以回歸的形式重新開啟並向您發出警示，而不是默默地在已關閉的問題上再累加一次發生紀錄。

Source map

上傳某個版本的 map，經過壓縮的瀏覽器呼叫堆疊就會變得可讀。請透過 API 從您的建置流程上傳——請參閱 API 參考文件。

map 會先以 debug_id 比對，其次才以版本加檔案名稱比對。它們是在您讀取問題時才套用，而不是在事件抵達時，這帶來一個有用的結果：在錯誤發生之後才上傳的 map，一樣會套用到這些錯誤上。而這通常正是事情發生的順序。

附在事件上的錯誤

當監控開啟一個事件時，它會蒐集您的應用程式在那次中斷被確認期間所拋出的錯誤，並把一份摘要附加在事件本身上。

值得瞭解它為何比事後再去搜尋更有用：那段時間範圍在事件成立的那一刻就不再存在，而錯誤事件有保留期限，會遠早於事件本身到期。因此摘要是在還能蒐集的當下就蒐集下來，之後便隨著事件一起保存。

在代理商帳戶中，摘要的範圍限定在工作區之內，因此某個客戶的事件不會把另一個客戶的呼叫堆疊帶進郵件裡。

來自伺服器與網路設備的日誌

在 Business 及以上方案中，專案也會接收您的機器本來就在寫的日誌：來自 Linux 以及 Cisco 與 Juniper 設備的 syslog、Windows 事件日誌，以及 macOS 統一日誌。將您已經在使用的日誌轉發器指向專案的日誌端點即可，該位址就在專案頁面的 DSN 旁邊。機器本身無須安裝任何東西。

僅儲存錯誤。低於 err 的 syslog 層級、低於 Error 的 Windows 層級，以及 macOS 日誌中稱為 Default 或更低的一切，都會在計數或計費之前被捨棄——因此健康的主機不會產生任何費用，那些不足以呼叫值班人員的警示也不會塞滿您的問題清單。

日誌記錄的歸類方式與例外相同：依發出它的程式與訊息內容歸類，而不是依主機。一次錯誤的發布影響二十台 Web 伺服器，是一個被看到二十次的問題，而不是二十個問題。當設備為自己的訊息命名時，我們依該名稱歸類，因此介面中斷是一個問題，無論它是哪個連接埠。

由於日誌行的重複次數遠多於例外，我們每小時為每個問題保留一個樣本，其餘的只做計數。出現次數與圖表都是精確的；您得不到的，只是第一百筆完全相同的日誌的獨立副本。

配額

每個方案都有每月事件額度——Free 5,000 個，Starter 50,000 個，Pro 250,000 個，Business 1,000,000 個。接收端也會依專案限制速率，而這才是真正會發生的情況：重試迴圈裡的一個例外，否則可能在幾分鐘內燒掉一整個月的配額。

個別事件會依您方案的錯誤保留期保存——Free 七天，Starter 三十天，Pro 六十天，Business 九十天。由這些事件建立起來的問題會比事件活得更久：它們的計數，以及首次與最後一次出現的時間，會一直保留到您方案的歷史保留期為止。

我們不做的事

沒有工作階段重播，沒有效能追蹤，也沒有效能剖析。這就只是例外追蹤，只不過它剛好就在您的可用性監控旁邊，於是「網站正常，卻每分鐘拋出五百個錯誤」是同一個畫面，而不是兩個產品。