內容整理自官方文件
系列
日誌記錄
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) 的訊息，您可以修改該級別以顯示更多或更少的資訊。
有關配置日誌記錄的詳細資訊，請參閱選項頁面上的日誌記錄部分。
錯誤報告
預設情況下，Relay 將錯誤記錄到配置的 logger 中。
您可以在 Relay 配置檔案中的 Sentry 中為您的專案啟用錯誤報告：
sentry:
enabled: true
dsn: <your_dsn>
可以在選項頁面上找到有關可用選項及其含義的更多資訊。
健康檢查
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
用於配置指標報告的選項記錄在選項頁面上。
Relay 收集以下指標
event.accepted (Counter)
當前時段接受的信封數量。
這表示已成功通過速率限制和過濾器並已傳送到上游的請求。
event.corrupted (Counter)
已損壞（不可列印）事件屬性的事件數。
目前，這會檢查environment和release，我們知道某些SDK可能會傳送損壞的值。
event.processing_time (Timer)
同步處理信封所花費的時間（以毫秒為單位）。
此時序涵蓋CPU池中的端到端處理，包括：
event_processing.deserializeevent_processing.piievent_processing.serialization
在 Relay 處於處理模式時，這還包括以下時序：event_processing.processevent_processing.filteringevent_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 2xxresponse_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 2xxresponse_error: 請求已傳送並返回HTTP錯誤。payload_failed: 請求已傳送，但在解釋響應時出錯。send_failed: 由於網路錯誤，無法傳送請求。rate_limited: 請求被限速。invalid_json: 無法將響應解析回JSON。route: 在上游呼叫的端點。status-code: 可用時請求的狀態碼，否則為"-"。