系列

目錄

  • 警報簡介

    • 錯誤 Issue 警報
    • 錯誤和效能指標警報
    • 建立警報
    • 通知
  • 警報型別
    • Issue 警報
    • 指標警報
      • 警報詳情
  • 建立警報
    • Issue 警報配置

      • 環境
      • 團隊
      • 警報名稱
      • “何時(When)”條件：觸發器
      • “如果(If)”條件：過濾器
      • “然後(Then)”條件：動作
        • Issue 所有者
        • 團隊 Slack 通知
      • 動作間隔（速率限制）
      • 專案級警報設定
        • 摘要
    • 指標警報配置
      • 過濾器

        • 環境
        • 事件型別
        • 標籤(Tag) & 屬性(Attribute)
      • 指標（函式 + 時間間隔）
        • 警報函式
        • 時間間隔
      • 閾值
        • 自動解決
      • 動作
      • 規則名稱
      • 團隊
    • 帶有整合的警報路由
      • 整合

        • Slack 警報
        • PagerDuty 警報
        • Microsoft Teams 警報
      • 構建您自己的整合
      • 遺留整合
    • 警報最佳實踐
      • 檢測重要問題
      • 降低警報噪音
        • 已忽略 Issue
      • 路由
  • 通知
    • 工作流通知
    • 部署通知
    • 配額通知
    • 每週報告
  • 個人通知設定
    • 警報

      • 交付方式
    • 工作流
      • 交付方式
      • 取消訂閱
    • Email 路由
    • 每週報告
    • 部署
      • 交付方式
    • 我的活動
公眾號：黑客下午茶

警報簡介

警報提供對程式碼問題和對使用者的影響的實時可見性。有多種型別的警報可用於自定義閾值和整合。

從 sentry.io 的 Alerts 頁面，您可以建立新的警報規則並管理現有規則。 “警報規則(Alert Rules)”選項卡顯示您現有的警報規則，以及它們的當前狀態、專案、團隊和建立日期。 預設情況下，該列表經過篩選，以便僅顯示與您所屬的團隊以及與任何團隊無關的警報。 您可以使用過濾器按鈕更改此設定。

警報(Alerts) 頁面還顯示一個 “歷史(History)” 選項卡，您可以在其中找到指標警報列表，其中包含觸發時間和活動時間等資訊。

錯誤 Issue 警報

只要專案中的任何問題符合指定標準，就會觸發 Issue 警報。您可以為 Issue 級別的更改建立警報，例如：

  • 新 Issue
  • Issue 頻率增加
  • 已解決和忽略的 Issue 變成未解決(unresolved)

您可以在 issue 警報配置中找到 Issue 警報觸發器的完整列表。

錯誤和效能指標警報

當 error 或 transaction 事件違反了指標時，指標警報就會觸發。 使用指標警報來監控您關心的一組有限且已知的指標和元件，例如整個專案中、重要頁面上或具有特定標籤的錯誤頻率或效能指標。

建立警報以監控指標，例如：

  • 專案中的總錯誤(Total errors)
  • 延遲(Latency)：最小值(min)、最大值(max)、平均值(average)、百分位數(percentile)
  • 失敗率(Failure rate)
  • 自定義指標

您可以在指標警報中找到可用指標警報的完整列表。

建立警報

在 sentry.io 中建立新專案時，您可以選擇預設的 issue 警報。 但是，您也可以使用這些最佳實踐作為指南，建立自己的警報以滿足團隊的需求。

通知

除了警報之外，Sentry 還會向您傳送有關各種事項的通知，例如 issue 狀態更改、釋出部署和配額使用情況。 您可以在使用者設定 > 通知(User Settings > Notifications)中微調這些通知以及您的個人警報設定。 在完整文件中瞭解有關通知和調整其關聯設定的更多資訊。

警報型別

您可以建立兩種型別的警報：

  1. Issue alerts：當 issue（一組錯誤事件）符合特定條件時觸發。
  2. Metric alerts：當 error 或 transaction 事件的巨集觀指標超過特定閾值時觸發。

Issue 警報

只要專案中的任何 issue 符合指定標準，就會觸發 Issue 警報。 例如，這些標準可能是重新出現的已解決 issue 或影響許多使用者的 issue。

在“警報規則(Alert Rules)”選項卡中，這些警報由 issues 圖示標識，預設情況下，它們顯示在警報列表的底部。（如果您有多個指標警報，這可能會將您的 issue 警報從列表的第一頁推出。）

在問題警報中，Sentry 每次收到新事件時都會評估配置的警報條件。警報條件包括三個部分：

  1. 觸發器(Triggers)指定您想要監控的活動型別，或何時(When)應觸發警報。
  2. 過濾器(Filters)通過僅在 issue 符合指定標準時觸發警報來幫助控制 issue 噪音。
  3. 然後，Actions 指定當滿足觸發條件並且過濾器匹配時應該發生什麼。

指標警報

指標警報會告訴您指標何時超過閾值，例如專案中錯誤數量的激增，或效能指標的變化，例如延遲(latency)、Apdex、故障率(failure rate)或吞吐量(throughput)。

指標警報監控 error 和 transaction 事件的巨集觀指標。指標獲取一組事件並使用函式（例如 count() 或 avg()）計算一段時間內應用於事件屬性的聚合值。 建立指標警報時，您可以按屬性(attributes)和標籤(tags)過濾事件，這對於聚合未分組為單個 issue 的事件特別有用。

這些警報使用 Critical 和 Warning 觸發器來衡量嚴重性。 警報的當前狀態是處於活動狀態的最高嚴重性觸發器(highest severity trigger)，可以是以下三個值之一：警告(Warning)、嚴重(Critical)或已解決(Resolved)。每當警報的狀態發生變化時，Sentry 都會通知您。

建立警報時，所有顯示的警報型別（“Issues”除外）均可用於建立指標警報：

  • Number of Errors(錯誤數)
  • Users Experiencing Errors(出現錯誤的使用者)
  • Throughput(吞吐量)
  • Transaction Duration(transaction 時長)
  • Apdex
  • Failure Rate(失敗率)
  • Largest Contentful Paint(最大內容繪製)
  • First Input Delay(首次輸入延遲)
  • Cumulative Layout Shift(累積佈局偏移)
  • Custom Metric(自定義指標)

警報詳情

警報詳細資訊(Alert Details)頁面預設顯示過去 24 小時的指標警報規則的歷史記錄，但可以使用“顯示(Display)”下拉選單修改時間段。 觸發警報時，單擊您收到的通知會將您帶到此頁面，該頁面顯示警報處於活動狀態的時間段。 該頁面還包括詳細資訊，例如警報規則條件、警報的當前狀態以及警報在每種狀態（Critical、``Warning或Resolved`）中花費的時間摘要。

警報詳細資訊(Alert Details)頁面還包括與指標相關的可疑 issue 或 transaction 的列表，以幫助更快地查明根本問題。您可以檢視可能導致觸發警報的原因，然後在 Discover 中開啟該指標以查詢更多資訊。

建立警報

建立警報所需的最低角色是 member。具有 manager 或 owner 許可權的 Sentry 使用者可以在設定 > 常規設定 > 讓成員建立和編輯警報(Settings > General Settings > Let Members Create and Edit Alerts)中更改最低角色要求。

要建立警報：

  1. 導航到警報(Alerts)並單擊 “Create Alert Rule”。
  2. 選擇您的專案。
  3. 選擇您希望收到警報的內容。 選擇 “Issues” 會建立 issue 警報，而選擇任何其他選項會建立 metric 警報。

  4. 單擊“設定條件(Set Conditions)”。
  5. 在警報配置頁面，設定告警條件：

Issue 警報配置

Sentry 提供了多個配置選項來根據您組織的需要建立 issue 警報。

環境

指定哪些環境(environment)將使用此特定警報規則。此控制元件過濾事件中的環境標籤。 例如，此過濾器很有用，因為您應用於生產警報的緊迫性和工作流程可能不同於您應用於源自 QA 環境的警報的緊急程度和工作流程。

此處的 “Environment” 下拉列表具有與全域性 “Environment” 下拉列表中所選專案可用的相同環境（不包括隱藏環境）。 選擇 “All Environments” 相當於沒有環境過濾器。

團隊

您可以選擇要與警報關聯的團隊，以便該團隊的成員可以編輯警報。 請注意，只有當您是團隊成員時才能進行此關聯。 如果未選擇任何團隊，則任何人都可以編輯警報。

警報名稱

為您的警報指定一個描述性名稱，例如受影響的團隊和警報的主題。 例如，“前端延遲(Frontend Latency)”、“後端故障率(Backend Failure Rate)”或“計費 Apdex(Billing Apdex)”。

“何時(When)”條件：觸發器

“When” 條件或觸發器指定您希望針對該 issue 監控哪種型別的活動：

  • 首次出現
  • 將狀態從已解決(resolved)更改為未解決(unresolved)
  • 將狀態從忽略(ignored)更改為未解決(unresolved)
  • 在一個時間間隔內看到超過一定次數
  • 在一個時間間隔內被超過一定數量的唯一使用者看到
  • 某個 issue 在 {time} 內影響了超過 {X}% 的會話
    • 受影響的會話百分比是一個近似值，計算為 issue 頻率與專案中會話數的比率
    • 僅當過去一小時的會話數超過 50 時才會觸發基於百分比的警報

觸發器(Triggers)是可選的。如果不選擇觸發器，則預設認為滿足 “When” 條件。也就是說，所有的事件都滿足這個條件。

在 Issue States & Triage 中瞭解有關 issue 狀態的更多資訊。

“如果(If)”條件：過濾器

Sentry 在滿足 “When” 條件後檢查 “if conditions” 或過濾器，這些通過過濾掉不符合您指定標準的問題來幫助控制 noise。 您可以過濾issue 或事件屬性。如果指定了事件過濾器，它只會檢查觸發警報的事件，例如：

  • issue 位元定持續時間更舊或新。
  • 該 issue 至少發生了 {X} 次。
  • issue 已分配給{no one/a team/a member}。
  • 該事件來自最新 release。
  • 事件的 {attribute} {matches} {value}。 匹配型別：等於(equals)、不等於(does not equal)、開始於(starts with)、結束於(ends with)、包含(contains)、不包含(does not contain)、已設定(is set)或未設定(is not set)。
  • 事件的 {tag} {matches} {value}。 匹配型別：等於(equals)、不等於(does not equal)、開始於(starts with)、結束於(ends with)、包含(contains)、不包含(does not contain)、已設定(is set)或未設定(is not set)。
  • 事件的級別 {matches} {level}。匹配型別：等於(equal to)、小於(less than)或等於(equal to)、或大於(greater than)或等於(equal to)。

瞭解更多關於標籤(tags)和事件屬性(event attributes)的資訊。

“然後(Then)”條件：動作

“Then conditions”或動作，指定滿足觸發器和過濾條件時應該發生的事情：

瞭解有關通過整合路由警報的更多資訊。

Issue 所有者

Issue 所有者可以在觸發警報時收到通知（僅限電子郵件）。

對於早期採用者，這些通知是通過電子郵件或 Slack 接收的，具體取決於問題所有者的通知設定。

如果未配置或未找到 issue 所有者，則不會發送通知或將其傳送給所有專案成員，具體取決於 [專案]>設定>問題所有者([Project]>Settings>Issue Owners) 中的以下設定。

團隊 Slack 通知

團隊可以配置 Slack channel 來接收警報通知。這可以通過在所需的 Slack channel 中鍵入 /sentry link team 來完成。要在 sentry.io 中檢視團隊關聯的 Slack 頻道，請導航到 設定>團隊>[團隊]>通知(Settings>Teams>[Team]>Notifications)。

動作間隔（速率限制）

動作間隔(action interval)或速率限制(rate limit)控制針對特定問題觸發警報規則的頻率。如果警報條件與問題匹配，Sentry 只執行在速率限制期限內尚未針對該問題執行的動作。例如，如果一個問題在一分鐘的時間內多次滿足警報條件，但是您的頻率閾值是一分鐘，那麼您只會收到一次警報。

可用的間隔是：

  • 分鐘：5, 10, 30, 60
  • 小時：3, 12, 24
  • 天：7, 30

專案級警報設定

在 [專案] > 設定 > 警報([Project] > Settings > Alerts) 中，您可以配置警報電子郵件主題模板和摘要設定。擁有 owner、manager 或管理員許可權(admin permissions)及以上許可權的 Sentry 使用者可以更改這些預設通知設定。

摘要

摘要功能僅適用於 issue 警報電子郵件（不是通過整合傳送的通知），並且與動作間隔(action interval)不同，它限制為專案傳送的警報電子郵件總數。此專案級設定允許您控制警報的最小和最大交付間隔。

指標警報配置

Sentry 提供了多個配置選項來根據您組織的需要建立指標警報。

過濾器

以下過濾器組轉換為 Discover 查詢，顯示在警報配置頁面頂部的圖表中。

環境

指定哪些環境將使用此特定警報規則。此控制元件過濾事件中的 environment 標籤。 例如，此過濾器很有用，因為您應用於生產警報的緊迫性和工作流程可能不同於您應用於源自 QA 環境的警報的緊急程度和工作流程。

此處的 “Env:” 下拉列表與全域性 “Environment” 下拉列表中所選專案的可用環境相同（不包括隱藏環境）。 選擇 “全部(All)” 相當於沒有環境過濾器。

事件型別

對於某些指標警報，您可以在“事件(Events)”下拉列表中設定要收到警報的事件型別：

  • event.type:error OR event.type:default
  • event.type:default
  • event.type:error
  • event.type:transaction
標籤(Tag) & 屬性(Attribute)

在提供的欄位中新增過濾器以縮小您將收到警報的範圍，例如 URL、標籤或其他事件屬性。

指標（函式 + 時間間隔）

根據您選擇的警報型別，您可以選擇要應用的函式和引數。在其他情況下，該功能內置於警報中，並且不顯示設定。 例如，如果您選擇“受影響的使用者數(Number of Users Affected)”，則轉換為函式 count_unique(user.id)。 由於編輯此函式會改變警報的性質，因此它不可編輯，因此被隱藏。

警報函式
  • count()
  • count_unique(...)
  • avg(...)
  • percentile(...)
  • failure_rate()
  • apdex(...)
  • count()
  • p50()
  • p75()
  • p95()
  • p99()
  • p100()
時間間隔

選擇評估指標的時間段。您的選擇範圍從一分鐘到一天。 Sentry 每分鐘評估指定的視窗。 例如，如果您指定一個小時時間視窗，Sentry 會評估：

  • At 3:00pm: 2:00pm - 3:00pm
  • At 3:01pm: 2:01pm - 3:01pm
  • At 3:02pm: 2:02pm - 3:02pm
  • ...

閾值

閾值是幫助定義警報觸發器的數值。這些數值被標記為：

  • Critical(嚴重)
  • Warning(警告)
  • Resolved(已解決)

您必須設定 “Warning” 閾值，使其在 “Critical” 閾值之前觸發。當 Sentry 評估警報時，警報的狀態會更新為匹配的最高嚴重性觸發器。如果您未設定 “Resolved” 閾值，警報將在不再違反 “Critical” 或 “Warning” 條件時自動解決。您還可以手動解決警報。

自動解決

預設情況下，當指定的指標不再違反 “Critical” 或 “Warning” 條件時，會自動解決指標警報。 但是，您可以設定不同的解析度閾值。例如，假設您的應用程式的正常錯誤級別低於 2000/分鐘，並且您希望在超過 5000/分鐘 時收到警報。您可能希望警報僅在錯誤級別回到 2000/分鐘 以下時 resolve，而不是 5000/分鐘。通過以這種方式設定 “Resolved” 閾值，如果錯誤級別回落到僅 4000/分鐘，即使它低於警報閾值，您也會認為這是有問題的，警報將不會 resolve。

動作

動作定義了您和您的團隊將如何收到警報：

瞭解有關通過整合路由警報的更多資訊。

規則名稱

為您的警報指定一個描述性名稱，例如受影響的團隊和警報的主題。例如，“前端延遲(Frontend Latency)”、“後端故障率(Backend Failure Rate)”或“計費 Apdex(Billing Apdex)”。

團隊

您可以選擇要與警報關聯的團隊，以便該團隊的成員可以編輯此警報。 請注意，只有當您是團隊成員時才能進行此關聯。如果未選擇任何團隊，則任何人都可以編輯警報。

帶有整合的警報路由

通過定製警報規則並整合您已經使用的工具，您可以在需要的時候when、地點where(以及是否if)收到警報，而不會受到干擾。警報通知可以路由到 Slack，多個支援的整合，以及通過 webhooks 定製整合。在建立警報規則時，您可以使用這些整合來配置通知誰以及如何通知。

整合

Sentry 的整合為您提供了通過 Slack、PagerDuty 和 Microsoft Teams 等常用應用程式路由警報的選項。 您可以在 設定 > 整合(Settings > Integrations) 中找到這些整合，併為整個組織安裝它們。

Slack 警報

Sentry 組織 owner 或 manager 可以在其 Sentry 帳戶中安裝和配置 Slack 整合。 配置整合後，issue 警報規則中將提供以下動作：向 {workspace} Slack 工作區傳送通知至 {channel} 並在通知中顯示標籤 {tags}。在指標警報中，您的 Slack 團隊將在 action 下拉列表之一中可用。

此 alert action 允許您將警報通知路由到 Slack 工作區中的選定頻道（使用 # 字首）或直接訊息中的特定使用者（使用 @ 字首）。

然後，一旦您收到 Slack 通知，您可以使用 “Resolve”、“Ignore” 或 “Assign” 按鈕直接從 Slack 更新 sentry.io 中的問題。

PagerDuty 警報

Sentry 組織 owner 或 manager 可以在其 Sentry 帳戶中安裝和配置 PagerDuty 整合。 配置整合後，issue 警報規則中將提供以下動作：向 PagerDuty 帳戶 {account} 和服務 {service} 傳送通知。在指標警報中，您的 PagerDuty 帳戶將在 action 下拉列表之一中可用。

Microsoft Teams 警報

Sentry 組織 owner 或 manager 可以在其 Sentry 帳戶中安裝和配置 Microsoft Teams。 配置整合後，issue 警報規則中將提供以下動作：向 {team} 團隊傳送通知至 {channel(s)}。 在指標警報中，您的 Microsoft 團隊將在 action 下拉列表之一中可用。

構建您自己的整合

如果您想將警報通知路由到 Sentry 沒有開箱即用整合的其他解決方案，您可以使用 Integration Platform。 整合平臺為外部服務提供了一種使用 REST API 和 Webhook 與 Sentry SaaS 服務互動的方法。

如果您想從不同的監控系統彙總警報或編寫自定義規則以更智慧地路由警報，則向 webhook 傳送警報也很有幫助。

當您建立新的整合並在其上啟用“Alert Rule Action”選項時，當您選擇在 issue 警報規則建立期間通過整合 action 傳送通知時，您的整合將顯示為服務。在指標警報中，您的整合在 action 下拉列表之一中可用。

遺留整合

遺留整合(也稱為外掛)是 Sentry 的擴充套件，打包為 Python 庫，並在專案級進行配置。要向遺留整合傳送警報，請選擇 “Send a notification via an integration” 或 “Send a notification to all legacy integrations” 動作。您不能將指標警報路由到遺留整合。

警報最佳實踐

警報在正確的時間通知正確的人非常重要。向太多人傳送太多通知可能會導致這些通知被忽略。 以下最佳實踐將幫助您建立或微調警報以最大程度地減少警報噪音，同時仍會告訴您需要了解的內容。

檢測重要問題

頻率(Frequency) ：通常，您會設定警報以在錯誤超過特定頻率時觸發，但頻率並不是一切：如果低頻錯誤位於應用程式的更重要部分，則它可能比高頻錯誤更重要。

受影響的使用者(Users affected)：有時極少數使用者會產生大量錯誤，因此提醒受影響的使用者可能比錯誤頻率更重要。然而，並非所有在 Sentry 中有使用者計數的錯誤實際上都可能是面向使用者的，反之亦然。 如果您過濾這些型別的問題，您就可以避免收到非使用者面臨的錯誤的警報。

標籤(Tags)：使用標籤對錯誤進行分類。例如，您可以過濾自動捕獲的 url 標籤以識別關鍵業務頁面，或過濾自定義標籤（如 customer_type）以更重要地處理這些警報。您可以在 [專案] > 設定 > 標籤([Project] > Settings > Tags) 下找到專案中可用的標籤列表。 該列表是該專案事件中遇到的所有標籤 key（預設和自定義）的聚合。

降低警報噪音

這些最佳實踐可幫助您減少 issue 警報可能產生的噪音，但不適用於指標警報。

看到相同的警報(Seeing the same alerts)：如果您反覆看到以前看過的警報，請嘗試將您的 issue 警報過濾為過去幾天建立的問題，使用 The issue is older or newer than... 過濾器。

瞬態警報(Transient alerts)：要過濾掉僅快速連續發生幾次且不再發生的 transient issues，請在您的 issue 警報中使用 Issue has happened at least {X} times 過濾器。

限制為最新版本(Limit to latest release)：使用 The event is from the latest release 過濾器將您的 issue 警報僅應用於最新版本。

使用“For Review”列表(Use the “For Review” list)：新 issue 和未解決的 issue 通常是您想知道的，但它們會產生很多噪音。Sentry 問題列表中的 “For Review” 選項卡會顯示這些問題，因此您可以使用電子郵件和整合來發出更高緊急性的警報，同時確保這些低緊急性問題不會被忽視。我們建議每天檢視一次 “For Review” 列表。此列表顯示：

  • 新 Issue
  • 迴歸（issue 從 “Resolved”->“Unresolved” 更改狀態）
  • 滿足忽略條件的 issue（issue 狀態從 Ignored -> Unresolved）
已忽略 Issue

您可以忽略 issue 以減少噪音，但是，當滿足警報條件時，忽略的問題不會觸發警報；它們反而變成 unresolved 並出現在“For Review”列表中。因此，如果您擔心遺漏這些問題，請使用 An issue changes state from ignore to unresolved 觸發器建立問題警報。

路由

問題所有者(Issue owners) ：使用 issue owners 讓 Sentry 自動向合適的人傳送警報，並減輕配置負擔。 您可以在 [專案] > 設定 > 問題所有者( [Project] > Settings > Issue Owners) 中配置所有權規則。 當沒有匹配的所有者時，警報預設傳送給所有專案成員。 如果這太寬泛，並且您希望特定所有者作為後備，請以 *:<owner> 之類的規則結束您的所有權規則。

不同優先順序的傳送方式(Delivery methods for different priorities) ：使用不同的傳送方式來區分不同優先順序的告警。例如，您可以像這樣從最高優先順序路由到最低優先順序：

  • 高優先順序：頁面（PagerDuty 或 OpsGenie）
  • 中等優先順序：聊天應用（Slack）
  • 低優先順序：Email

問題列表中的 “For Review” 選項卡是您可以在不接收任何警報的情況下檢查優先順序最低的問題的位置。

構建整合：如果您想將警報通知路由到 Sentry 還沒有開箱即用整合的解決方案，您可以使用 Integration Platform。建立整合時，它將在 alert actions 選單中可用。您可能希望將自己的整合用於：

  • 向原生不支援的整合傳送警報
  • 聚合來自不同監控系統的警報
  • 在 webhook 處理程式中編寫自定義規則以更智慧地路由警報

通知

Sentry 向您傳送有關工作流活動、釋出部署和配額使用情況的通知，以及每週報告。 這些通知讓您瞭解：

  • 工作流(Workflow)：涉及使用者操作和 issue 狀態更改的活動。這包括 issue 解決、分配、評論和迴歸等活動。
  • 部署(Deploy)：當您提交的版本被部署時。
  • 配額(Quota)：接近配額、超出配額和尖峰保護。
  • 每週報告(Weekly Reports)：您組織的 Sentry 活動摘要。

您可以在 使用者設定 > 通知(User Settings > Notifications) 中管理這些通知。

工作流通知

Sentry 傳送工作流通知，讓您瞭解 issue 狀態更改。 工作流與幫助您管理問題的動作相關，例如更改 issue 的狀態或對其發表評論。預設情況下，Sentry 通過電子郵件將這些通知傳送給訂閱該問題的成員（有關如何確定訂閱，請參見下文）。 傳送工作流通知：

  • 問題已解決(Issue Resolved)：當您的程式碼中發現新 issue 時，它處於 Unresolved 狀態。 當專案團隊成員通過在 sentry.io 中手動更改其狀態或提交修復程式或由於專案的自動解決功能（如果已配置）解決 issue 時，issue 狀態將更改為已解決。
  • 迴歸(Regressions)：當 issue 的狀態從 “Resolved” 變回 “Unresolved” 時，就會發生迴歸。 將向所有專案團隊成員傳送一封電子郵件。
  • 評論(Comments)：當團隊成員在 issue 詳細資訊頁面的 “Activity” 選項卡中新增新評論時。
  • 分配(Assignment)：當一個問題被分配或未分配時。
  • 使用者反饋(User Feedback)：當一個 issue 有新的使用者反饋時。
  • 事件處理問題(Event Processing Problems)：當您傳送給 Sentry 的錯誤事件處理出現問題時。

當您訂閱 issue 時，您會收到工作流通知，並且您通過以下方式訂閱問題：

  • 單擊 issue 上的訂閱鈴鐺(subscribe bell)圖示
  • 參與與 issue 相關的提交
  • 對 issue 發表評論或新增書籤
  • 在 issue 中提及您或您的團隊
  • 您或您的團隊被分配到該 issue

這些通知可能與為專案配置的警報有一些重疊。

部署通知

Sentry 向已提交已部署版本的使用者傳送部署通知。在部署文件中瞭解更多資訊。

配額通知

在以下情況下，Sentry 會向組織的所有所有者傳送配額通知：

  • 組織的 80% 的錯誤、事務和附件量已耗盡。
  • 錯誤或事務超過了組織的配額，其中包括按需容量

您無法更改或禁用這些通知。在完整的配額文件中瞭解更多資訊。

每週報告

Sentry 每週一通過電子郵件傳送每週報告。報告包含您組織在上週的 Sentry 活動摘要。

個人通知設定

您可以在您的帳戶設定中調整您的個人工作流程並部署通知以及您的個人 issue 警報設定。通過導航到 使用者設定 > 通知(User Settings > Notifications) 來管理您的通知。您無法配置配額通知。

警報

此設定不會影響配置為明確傳送到您的電子郵件的警報。

在通知中，您可以全域性開啟和關閉 issue 警報通知。

您還可以通過選擇 “Default” 、“On” 或 “Off” 來對每個專案的警報通知進行微調。如果您選擇 “Default”，專案的設定將與您的全域性設定相同。

交付方式

您可以通過從以下選項中進行選擇來決定在何處接收個人警報通知：

  • 傳送到 Email
  • 傳送到 Slack
  • 傳送到 Email 和 Slack

如果您的組織安裝了 integration 並且您的 Slack 身份已連結到您的 Sentry 帳戶，則 Slack 僅可用作交付方式。

工作流

工作流通知的全域性設定是：

  • Always(總是)
  • Only On Issues I Subscribe To(僅在我訂閱的問題上)
  • Never(從不)

您可以通過選擇以上三個選項之一或 “Default” 來針對每個專案微調您的工作流程通知。如果您選擇 “Default”，專案的設定將與您的全域性設定相同。

交付方式

您可以通過從以下選項中進行選擇來決定在何處接收個人工作流通知：

  • 傳送到 Email
  • 傳送到 Slack
  • 傳送到 Email 和 Slack

如果您的組織安裝了整合並且您的 Slack 身份已連結到您的 Sentry 帳戶，則 Slack 僅可用作交付方式。

取消訂閱

要退出特定問題的工作流通知，請單擊問題頁面頂部的訂閱鈴鐺圖示。

Email 路由

電子郵件路由控制每個專案的通知傳送到的電子郵件地址。這些通知預設為您在設定 Sentry 帳戶時提供的電子郵件地址。此設定允許您基於每個專案將電子郵件路由到備用電子郵件地址。

每週報告

報告包含您組織在上週的 Sentry 活動摘要。您可以通過為每個組織開啟或關閉報告來微調您的每週報告。

部署

部署通知的全域性設定是：

  • On
  • Only On Deploys With My Commits(僅在我提交的部署上)
  • Off

您可以通過選擇上述三個選項之一或 “Default” 來對每個組織的部署通知進行微調。如果您選擇 “Default”，組織的設定將與您的全域性設定相同。

交付方式

您可以通過從以下選項中進行選擇來決定在何處接收個人工作流通知：

  • 傳送到 Email
  • 傳送到 Slack
  • 傳送到 Email 和 Slack

如果您的組織安裝了整合並且您的 Slack 身份已連結到您的 Sentry 帳戶，則 Slack 僅可用作交付方式。

我的活動

使用切換開關來控制您是否收到有關以下內容的通知：

  • 您在使用 sentry.io 時的動作
  • 您已解決的無人認領 issue 的任何更改
公眾號：黑客下午茶