內容整理自官方文檔

系列

日志記錄

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.deserialize
  • event_processing.pii
  • event_processing.serialization

    在 Relay 處於處理模式時,這還包括以下時序:
  • event_processing.process
  • event_processing.filtering
  • event_processing.rate_limiting

event.protocol (Counter)

命中任何類似 store 的端點的事件數量:EnvelopeStoreSecurityMinidumpUnreal


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


該指標標記為:

  • 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)

拒絕信封的 outcomereason 的數量。


該指標標記為:

  • 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: errortransaction 事件。錯誤事件發送到 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)

到達 RelayHTTP 請求數。

requests.duration (Timer)

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


這不對應於完整的事件攝取時間。由於錯誤數據或緩存速率限制而未立即拒絕的事件請求始終返回 200 OK。 完全驗證和規範化是异步發生的,由 event.processing_time 報告。

該指標標記為:

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

requests.timestamp_delay (Timer)

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


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


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


該指標標記為:

  • category: 有效載荷的數據類別。可以是以下之一:eventtransactionsecurity 或 session

responses.status_codes (Counter)

已完成的 HTTP 請求數。


該指標標記為:

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

scrubbing.attachments.duration (Timer)

花費在附件清理上的時間。

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

scrubbing.minidumps.duration (Timer)

花在 minidump 清理上的時間。


這是解析和清理 minidump 所花費的總時間。即使沒有應用 minidumpPII 清理規則,仍將解析並在解析的 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: 重試次數存儲桶 012、很少(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: 可用時請求的狀態碼,否則為"-"

Sentry 企業級數據安全解决方案 - Relay 監控 & 指標收集的更多相關文章

  1. Sentry 企業級數據安全解决方案 - Relay 運行模式

    內容整理自官方開發文檔 Relay 可以在幾種主要模式之一下運行,如果您正在配置 Relay server 而不是使用默認設置,那麼事先了解這些模式至關重要. 模式存儲在配置文件中,該文件包含 rel ...

  2. Sentry 企業級數據安全解决方案 - Relay 入門

    內容整理自官方開發文檔 Sentry Relay 通過提供作為應用程序和 sentry.io 之間中間層的獨立服務來提供企業級數據安全性. Relay 專門設計用於: 在將個人身份信息 (PII) 發 ...

  3. zabbix企業級的分布式開源監控解决方案 v5.0 LTS

    目錄 zabbix簡介 服務模塊 客戶端守護進程 監控流程 功能拆解 安裝 zabbix 5.0 LTS 參考官網 zabbix 5.0.12-1.el7 zabbix-server相關優化 1. 字 ...

  4. 從0搭建一個基於 ELK 的日志、指標收集與監控系統

    為了使得私有化部署的系統能更健壯,同時不增加額外的部署運維工作量,本文提出了一種基於 ELK 的開箱即用的日志和指標收集方案. 在當前的項目中,我們已經使用了 Elasticsearch 作為業務的數 ...

  5. 《Hadoop高級編程》之為Hadoop實現構建企業級安全解决方案

    本章內容提要 ●    理解企業級應用的安全顧慮 ●    理解Hadoop尚未為企業級應用提供的安全機制 ●    考察用於構建企業級安全解决方案的方法 第10章討論了Hadoop安全性以及Hado ...

  6. Telegraf和Grafana監控多平臺上的SQL Server-自定義監控數據收集

    問題 在上一篇文章中,我們使用Telegraf自帶的Plugin配置好了的監控,但是自帶的Plugin並不能完全覆蓋我們想要的監控指標,就需要收集額外的自定義的監控數據,實現的方法有: 開發自己的Te ...

  7. Foreman 企業級配置管理解决方案

    Foreman 企業級配置管理解决方案 Foreman 企業級配置管理解决方案 筆記本 puppet foreman 構建運維體系 本文是構建運維體系的其中一個關鍵環節. 什麼是 foreman Fo ...

  8. 探索Windows Azure 監控和自動伸縮系列3 - 啟用Azure監控擴展收集自定義監控數據

    上一篇我們介紹了獲取Azure的監控指標和監控數據: http://www.cnblogs.com/teld/p/5113376.html 本篇我們繼續:監控虛擬機的自定義性能計數器. 隨著我們應用規 ...

  9. [博客遷移]探索Windows Azure 監控和自動伸縮系列3 - 啟用Azure監控擴展收集自定義監控數據

    上一篇我們介紹了獲取Azure的監控指標和監控數據: http://www.cnblogs.com/teld/p/5113376.html 本篇我們繼續:監控虛擬機的自定義性能計數器. 隨著我們應用規 ...

  10. prometheus自定義監控指標——實戰

    上一節介紹了pushgateway的作用.優劣以及部署使用,本機通過幾個實例來重溫一下自定義監控指標是如何使用的. 一.監控容器啟動時間(shell) 使用prometheus已經兩個月了,但從未找到 ...

隨機推薦

  1. 壓縮、解壓縮流GZipStream

    如果要在壓縮過程中檢查錯誤或要與其他操作系統所用程序共享壓縮數據,則要是用GZipStream類.GZipStream類包含是用GZip數據格式進行壓縮和解壓縮文件的方法,該類不能用於解壓縮大於4GB ...

  2. map——映射(message.cpp)

    信息交換 (message.cpp) [題目描述] Byteland戰火又起,農夫John派他的奶牛潜入敵國獲取情報信息. Cow曆盡千辛萬苦終於將敵國的編碼規則總結如下: 1 編碼是由大寫字母組成的 ...

  3. 201521123113《Java程序設計》第14周學習總結

    1. 本周學習總結 1.1 以你喜歡的方式(思維導圖.Onenote或其他)歸納總結多數據庫相關內容. JDBC體系架構: 2. 書面作業 Q1. MySQL數據庫基本操作 1.1 建立數據庫test ...

  4. YourPHP筆記

    http://blog.sina.com.cn/s/blog_7c54793101016qq1.htm 基礎認識: Ø  yourphp安裝為子目錄時不可以以"yourphp"為文 ...

  5. sklearn中的模型評估-構建評估函數

    1.介紹 有三種不同的方法來評估一個模型的預測質量: estimator的score方法:sklearn中的estimator都具有一個score方法,它提供了一個缺省的評估法則來解决問題. Scor ...

  6. CentOS7(64)環境使用rpm命令安裝gcc

    第一步:下載gcc相關的安裝文件下載地址:http://vault.centos.org/7.0.1406/os/x86_64/Packages/ 下載以下文件: cpp-4.8.2-16.el7.x ...

  7. 2019最新最全HUSTOJ本地及雲端服務器搭建(基於騰訊雲服務器)

    在剛接觸ACM的時候,對於那些在線測評的網站很感興趣,就在網上搜索了一下,在Github上發現了一個有趣的項目,然後在 Github 上獲取 了HUST OJ 的開源項目代碼,根據網上的教程踩了無數的 ...

  8. TortoiseSVN 和 VisualSVN

    ylbtech-Miscellaneos:TortoiseSVN 和 VisualSVN 1. TortoiseSVN 百科返回頂部 1-1.百科 TortoiseSVN 是 Subversion 版 ...

  9. WPF Converter 使用複雜參數的方法

    Step 1在WPF的C#代碼文件中給定義複雜類型的變量,並給其賦值:Sample code: List<User>lsUser=....Setp 2在 C#代碼對應的XAML 中將此複雜 ...

  10. Extjs 自定義控件

    // JavaScript Document Ext.namespace('CRM.Panels'); CRM.Panels.UserDetail = Ext.extend(Ext.Panel,{ w ...