日志記錄

Relay 將日志生成到標準錯誤流 (stderr)，默認情況下具有 INFO 日志記錄級別。例如，啟動 Relay 后，您可能會看到如下輸出：

INFO  relay::setup > launching relay from config folder .relay 
INFO  relay::setup >   relay mode: managed 
INFO  relay::setup >   relay id: cde0d72e-0c4e-4550-a934-c1867d8a177c 
INFO  relay::setup >   log level: INFO 

此示例顯示具有默認日志記錄級別 (INFO) 的消息，您可以修改該級別以顯示更多或更少的信息。有關配置日志記錄的詳細信息，請參閱選項頁面上的日志記錄部分。

• https://docs.sentry.io/product/relay/options/#logging

錯誤報告

默認情況下，Relay 將錯誤記錄到配置的 logger 中。您可以在 Relay 配置文件中的 Sentry 中為您的項目啟用錯誤報告：

sentry: 
  enabled: true 
  dsn: <your_dsn> 

可以在選項頁面上找到有關可用選項及其含義的更多信息。

• https://docs.sentry.io/product/relay/options/#internal-error-reporting

健康檢查

Relay 提供了兩個 URL 來檢查系統狀態：

• GET /api/relay/healthcheck/live/: 測試 Relay 是否正在運行并監聽 HTTP 請求。
• GET /api/relay/healthcheck/ready/: 測試 Relay 是否通過上游驗證并正常運行。

成功時，兩個端點都返回 200 OK 響應：

{ 
  "is_healthy": true 
} 

指標

您可以通過將 metrics.statsd key 配置為 ip:port 元組來向 StatsD server 提交統計信息。可以設置為 ip:port 元組。

示例配置

metrics: 
  # Endpoint of your StatsD server 
  statsd: 127.0.0.1:8126 
  # Prefix all metric names with this string 
  prefix: mycompany.relay 

用于配置指標報告的選項記錄在選項頁面上。

• https://docs.sentry.io/product/relay/options/#statsd-metrics

Relay 收集以下指標

event.accepted (Counter)

當前時段接受的信封數量。

這表示已成功通過速率限制和過濾器并已發送到上游的請求。

event.corrupted (Counter)

已損壞(不可打印)事件屬性的事件數。

目前，這會檢查 environment 和 release，我們知道某些 SDK 可能會發送損壞的值。

event.processing_time (Timer)

同步處理信封所花費的時間(以毫秒為單位)。

此時序涵蓋 CPU 池中的端到端處理，包括：

• event_processing.deserialize
• event_processing.pii
• event_processing.serialization

在 Relay 處于處理模式時，這還包括以下時序：

• event_processing.process
• event_processing.filtering
• event_processing.rate_limiting

event.protocol (Counter)

命中任何類似 store 的端點的事件數量：Envelope、Store、Security、Minidump、Unreal。

事件在被速率限制、過濾或以任何方式處理之前被計數。

該指標標記為：

version: 事件協議版本號默認為 7。

event.queue_size (Histogram)

隊列中的信封數。

隊列保存在 Relay 中特定時間正在處理的所有信封：

• 當 Relay 收到請求時，它確保提交的數據被包裝在一個信封中。
• 信封接受一些初步處理以確定它是否可以被處理或是否必須被拒絕。
• 一旦做出此決定，創建信封的 HTTP 請求就會終止，如果要進一步處理該請求，則信封將進入隊列。
• 在信封完成處理并被發送到上游后，信封被視為已處理并離開隊列。

隊列大小可以通過 cache.event_buffer_size 配置。

event.queue_size.pct (Histogram)

隊列中的信封數占隊列中可存儲的最大信封數的百分比。

該值的范圍從隊列為空時的 0 到隊列已滿且無法添加額外事件時的 1。隊列大小可以使用 event.queue_size 配置。

event.rejected (Counter)

當前時間段內拒絕的信封數量。

這包括信封因格式錯誤或處理過程中的任何其他錯誤而被拒絕(包括過濾事件、無效負載和速率限制)。

要檢查拒絕原因，請檢查 events.outcomes。

event.size_bytes.raw (Histogram)

從請求中提取后由 Relay 看到的 HTTP 請求正文的大小(以字節為單位)。

• 對于信封請求，這是信封的完整尺寸。
• 對于 JSON 存儲請求，這是 JSON 正文的大小。
• 對于崩潰報告和附件的分段上傳，這是 multipart body 的大小，包括邊界。

如果這個請求包含一個 base64 zlib 壓縮的有效載荷，而沒有正確的 content-encoding 頭，那么這是解壓前的大小。

最大請求 body 大小可以通過 limits.max_envelope_size 進行配置。

event.size_bytes.uncompressed (Histogram)

Relay 在解壓和解碼后看到的請求 body 的大小(以字節為單位)。

JSON 存儲請求可能包含 base64 zlib 壓縮負載，而沒有正確的 content-encoding 頭。在這種情況下，該指標包含解碼后的大小。否則，它總是等于 event.size_bytes.raw。

event.total_time (Timer)

信封從接收到完成處理并提交給上游的總時間(以毫秒為單位)。

event.wait_time (Timer)

在 Relay 中接收請求(即請求處理開始)和 EnvelopeProcessor 中開始同步處理之間花費的時間。該指標主要表示事件處理中的積壓。

event_processing.deserialize (Timer)

將事件從 JSON 字節反序列化為 Relay 在其上運行的原生數據結構所花費的時間(以毫秒為單位)。

event_processing.filtering (Timer)

在事件上運行入站數據過濾器所花費的時間(以毫秒為單位)。

event_processing.pii (Timer)

當前事件的數據清理所花費的時間(以毫秒為單位)。數據清理最后發生在將事件序列化回 JSON 之前。

event_processing.process (Timer)

在事件上運行事件處理器以進行標準化所花費的時間(以毫秒為單位)。事件處理發生在過濾之前。

event_processing.rate_limiting (Timer)

檢查組織、項目和 DSN 速率限制所花費的時間(以毫秒為單位)。

事件第一次被限速后，限速會被緩存。在此之后進入的事件將在請求隊列中更早地被丟棄并且不會到達處理隊列。

event_processing.serialization (Timer)

將事件從其內存表示轉換為 JSON 字符串所花費的時間。

events.outcomes (Counter)

拒絕信封的 outcome 和 reason 的數量。

該指標標記為：

• outcome: 拒絕事件的基本原因。
• reason: 描述導致 outcome 的規則或機制的更詳細的標識符。
• to: 描述 outcome 的目的地。可以是 kafka(處于處理模式時)或 http(在外部 relay 中啟用 outcome 時)。

可能的 outcome 是：

• filtered: 被入站數據過濾器丟棄。reason 指定匹配的過濾器。
• rate_limited: 被組織、項目或 DSN 速率限制丟棄，以及超過 Sentry 計劃配額。reason 包含超出的速率限制或配額。
• invalid: 數據被視為無效且無法恢復。原因表明驗證失敗。

http_queue.size (Histogram)

排隊等待發送的上游請求數。

盡可能使連接保持活動。連接保持打開狀態 15 秒不活動或 75 秒活動。如果所有連接都忙，它們將排隊，這反映在此指標中。

該指標標記為：

• priority: 請求的排隊優先級，可以是 "high" 或 "low"。優先級決定了執行請求的優先順序。

并發連接數可以配置為：

• limits.max_concurrent_requests 連接總數
• limits.max_concurrent_queries 表示并發高優先級請求的數量

metrics.buckets (Gauge)

Relay 的指標聚合器中的 metric bucket 總數。

metrics.buckets.created.unique (Set)

計算創建的唯一 bucket 的數量。

這是一組 bucket 鍵。指標基本上等同于單個 Relay 的 metrics.buckets.merge.miss，但對于確定多個實例正在運行時有多少重復 bucket 可能很有用。

Hash 目前取決于平臺，因此發送此指標的所有 Relay 應在相同的 CPU 架構上運行，否則此指標不可靠。

metrics.buckets.flushed (Histogram)

在所有項目的一個周期中刷新的 metric buckets 總數。

metrics.buckets.flushed_per_project (Histogram)

每個項目在一個周期中刷新的 metric buckets 數。

Relay 定期掃描 metric buckets 并刷新過期的桶。為每個正在刷新的項目記錄此直方圖。直方圖值的計數相當于正在刷新的項目數。

metrics.buckets.merge.hit (Counter)

每次合并兩個 bucket 或兩個 metric 時遞增。

按 metric 類型和名稱標記。

metrics.buckets.merge.miss (Counter)

每次創建 bucket 時遞增。

按 metric 類型和名稱標記。

metrics.buckets.parsing_failed (Counter)

從信封中解析指標 bucket 項目失敗的次數。

metrics.buckets.scan_duration (Timer)

掃描指標 bucket 以刷新所花費的時間(以毫秒為單位)。

Relay 定期掃描指標 bucket 并刷新過期的 bucket。此計時器顯示執行此掃描并從內部緩存中刪除 bucket 所需的時間。將指標桶發送到上游不在此計時器范圍內。

metrics.insert (Counter)

針對插入的每個指標遞增。

按指標類型和名稱標記。

outcomes.aggregator.flush_time (Timer)

outcome 聚合器刷新聚合 outcomes 所需的時間。

processing.event.produced (Counter)

放置在 Kafka 隊列上的消息數

當 Relay 作為 Sentry 服務運行并且一個 Envelope 項目被成功處理時，每個 Envelope 項目都會產生一條關于 Kafka 攝取主題的專用消息。

這個指標被標記為：

• event_type: 向 Kafka 生成的消息類型。

消息類型可以是：

• event: error 或 transaction 事件。錯誤事件發送到 ingest-events，事務發送到 ingest-transactions，帶有附件的錯誤發送到 ingest-attachments。
• attachment: 與錯誤事件關聯的附件文件，發送到 ingest-attachments。
• user_report: 來自用戶反饋對話框的消息，發送到 ingest-events。
• session: release health session 更新，發送到 ingest-sessions。

processing.produce.error (Counter)

在信封已排隊發送到 Kafka 后發生的生產者錯誤數。

例如，這些錯誤包括 "MessageTooLarge" 當 broker 不接受超過特定大小的請求時的錯誤，這通常是由于無效或不一致的 broker/producer 配置造成的。

project_cache.eviction (Counter)

從緩存中驅逐的陳舊項目的數量。

Relay 會以 cache.eviction_interval 配置的固定時間間隔掃描內存項目緩存中的陳舊條目。

可以使用以下選項配置項目狀態的緩存持續時間：

• cache.project_expiry: 項目狀態過期的時間。如果請求在過期后引用了項目，則會自動刷新。
• cache.project_grace_period: 過期后項目狀態仍將用于接收事件的時間。一旦寬限期到期，緩存將被逐出，新請求將等待更新。

project_cache.hit (Counter)

從緩存中查找項目的次數。

緩存可能包含過時或過期的項目狀態。在這種情況下，即使在緩存命中后，項目狀態也會更新。

project_cache.miss (Counter)

項目查找失敗的次數。

立即創建緩存條目，并從上游請求項目狀態。

project_cache.size (Histogram)

當前保存在內存項目緩存中的項目狀態數。

可以使用以下選項配置項目狀態的緩存持續時間:

• cache.project_expiry: 項目狀態計為過期的時間。如果請求在項目過期后引用該項目，它會自動刷新。
• cache.project_grace_period: 到期后項目狀態仍將用于攝取事件的時間。一旦寬限期到期，緩存被逐出，新請求等待更新。

緩存項目的數量沒有限制。

project_state.eviction.duration (Timer)

驅逐過時和未使用的項目所花費的總時間(以毫秒為單位)。

project_state.get (Counter)

從緩存中查找項目狀態的次數。

這包括對緩存項目和新項目的查找。作為其中的一部分，會觸發對過時或過期項目緩存的更新。

相關指標:

project_cache.hit: 用于成功的緩存查找，即使是過時的項目。

• project_cache.miss: 對于導致更新的失敗查找。
• project_state.no_cache (Counter)

使用 .no-cache 請求項目配置的次數。

這有效地計算了使用相應 DSN 發送的信封或事件的數量。對于這些項目狀態請求，對上游的實際查詢可能仍會進行重復數據刪除。

每個 project key 每秒最多允許 1 個此類請求。此指標僅計算允許的請求。

project_state.pending (Histogram)

內存項目緩存中等待狀態更新的項目數。

有關項目緩存的更多說明，請參閱 project_cache.size。

project_state.received (Histogram)

每個批處理請求從上游 返回 的項目狀態數。

如果同時更新多個批次，則會多次報告此指標。

有關項目緩存的更多說明，請參閱 project_cache.size。

project_state.request (Counter)

項目狀態 HTTP 請求的數量。

Relay 批量更新項目。每個更新周期，Relay 從上游請求 limits.max_concurrent_queries 批次的 cache.batch_size 項目。這些請求的持續時間通過 project_state.request.duration 報告。

請注意，更新循環完成后，可能會有更多項目等待更新。這由 project_state.pending 指示。

project_state.request.batch_size (Histogram)

對于每個批處理請求，來自上游的 requested 項目狀態數量。

如果同時更新多個批次，則會多次報告此指標。

批量大小可以通過 cache.batch_size 配置。有關項目緩存的更多說明，請參閱 project_cache.size。

project_state.request.duration (Timer)

獲取要解決的排隊項目配置更新請求所花費的總時間(以毫秒為單位)。

Relay 批量更新項目。每個更新周期，Relay 從上游請求 limits.max_concurrent_queries * cache.batch_size 項目。此指標測量此循環中所有并發請求的掛鐘時間。

請注意，更新循環完成后，可能會有更多項目等待更新。這由 project_state.pending 指示。

requests (Counter)

到達 Relay 的 HTTP 請求數。

requests.duration (Timer)

在 HTTP 響應返回給客戶端之前處理入站 Web 請求的總持續時間(以毫秒為單位)。

這不對應于完整的事件攝取時間。由于錯誤數據或緩存速率限制而未立即拒絕的事件請求始終返回 200 OK。完全驗證和規范化是異步發生的，由 event.processing_time 報告。該指標標記為：

• method: 請求的 HTTP 方法。
• route: 端點的唯一虛線標識符。

requests.timestamp_delay (Timer)

負載中規定的時間戳與接收時間之間的延遲。

SDK 無法在所有情況下立即傳輸有效載荷。有時，崩潰需要在重新啟動應用程序后發送事件。同樣，SDK 在網絡停機期間緩沖事件以供以后傳輸。該指標衡量事件發生時間與其到達 Relay 時間之間的延遲。該指標衡量事件發生時間與其到達 Relay 時間之間的延遲。

僅捕獲延遲超過 1 分鐘的有效載荷。

該指標標記為：

• category: 有效載荷的數據類別。可以是以下之一：event、transaction、security 或 session。

responses.status_codes (Counter)

已完成的 HTTP 請求數。

該指標標記為：

• status_code: HTTP 狀態代碼編號。
• method: 請求中使用的 HTTP 方法(大寫)。
• route: 端點的唯一虛線標識符。

scrubbing.attachments.duration (Timer)

花費在附件清理上的時間。這表示評估附件清理規則和附件清理本身所花費的總時間，而不管是否應用了任何規則。請注意，未能解析的 minidumps(scrubbing.minidumps.duration 中的 status="error")將作為普通附件進行清理并計入此內容。

scrubbing.minidumps.duration (Timer)

花在 minidump 清理上的時間。

這是解析和清理 minidump 所花費的總時間。即使沒有應用 minidump 的 PII 清理規則，仍將解析并在解析的 minidump 上評估規則，此持續時間在此處報告，狀態為 "n/a"。

這個指標被標記為:

• status: Scrubbing status: "ok" 表示清洗成功, "error" 表示清理過程中出現錯誤，最后 "n/a" 表示清理成功但未應用清理規則。

server.starting (Counter)

Relay server 啟動的次數。

這可用于跟蹤由于崩潰或終止而導致的不需要的重啟。

unique_projects (Set)

表示當前時間片內的活動項目數

upstream.network_outage (Gauge)

Relay 相對于上游連接的狀態。可能的值為 0(正常操作)和 1(網絡中斷)。

upstream.requests.duration (Timer)

將請求發送到上游 Relay 并處理響應所花費的總時間。

該指標標記為：

• result: 請求發生了什么，具有以下值的枚舉:
• success: 請求已發送并返回成功代碼 HTTP 2xx
• response_error: 請求已發送并返回 HTTP 錯誤。
• payload_failed: 請求已發送，但在解釋響應時出錯。
• send_failed: 由于網絡錯誤，無法發送請求。
• rate_limited: 請求被限速。
• invalid_json: 無法將響應解析回 JSON。
• route: 在上游調用的端點。
• status-code: 可用時請求的狀態碼，否則為"-"。
• retries: 重試次數存儲桶 0、1、2、很少(3 - 10)、很多(超過 10)。

upstream.retries (Histogram)

計算每個上游 http 請求的重試次數。

該指標標記為：

• result: 請求發生了什么，具有以下值的枚舉:
• success: 請求已發送并返回成功代碼 HTTP 2xx
• response_error: 請求已發送并返回 HTTP 錯誤。
• payload_failed: 請求已發送，但在解釋響應時出錯。
• send_failed: 由于網絡錯誤，無法發送請求。
• rate_limited: 請求被限速。
• invalid_json: 無法將響應解析回 JSON。
• route: 在上游調用的端點。
• status-code: 可用時請求的狀態碼，否則為"-"。