日志記錄

Relay 將日志生成到標(biāo)準(zhǔn)錯(cuò)誤流 (stderr)，默認(rèn)情況下具有 INFO 日志記錄級(jí)別。例如，啟動(dòng) Relay 后，您可能會(huì)看到如下輸出：

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 

此示例顯示具有默認(rèn)日志記錄級(jí)別 (INFO) 的消息，您可以修改該級(jí)別以顯示更多或更少的信息。有關(guān)配置日志記錄的詳細(xì)信息，請(qǐng)參閱選項(xiàng)頁(yè)面上的日志記錄部分。

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

錯(cuò)誤報(bào)告

默認(rèn)情況下，Relay 將錯(cuò)誤記錄到配置的 logger 中。您可以在 Relay 配置文件中的 Sentry 中為您的項(xiàng)目啟用錯(cuò)誤報(bào)告：

sentry: 
  enabled: true 
  dsn: <your_dsn> 

可以在選項(xiàng)頁(yè)面上找到有關(guān)可用選項(xiàng)及其含義的更多信息。

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

健康檢查

Relay 提供了兩個(gè) URL 來(lái)檢查系統(tǒng)狀態(tài)：

• GET /api/relay/healthcheck/live/: 測(cè)試 Relay 是否正在運(yùn)行并監(jiān)聽(tīng) HTTP 請(qǐng)求。
• GET /api/relay/healthcheck/ready/: 測(cè)試 Relay 是否通過(guò)上游驗(yàn)證并正常運(yùn)行。

成功時(shí)，兩個(gè)端點(diǎn)都返回 200 OK 響應(yīng)：

{ 
  "is_healthy": true 
} 

指標(biāo)

您可以通過(guò)將 metrics.statsd key 配置為 ip:port 元組來(lái)向 StatsD server 提交統(tǒng)計(jì)信息。可以設(shè)置為 ip:port 元組。

示例配置

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

用于配置指標(biāo)報(bào)告的選項(xiàng)記錄在選項(xiàng)頁(yè)面上。

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

Relay 收集以下指標(biāo)

event.accepted (Counter)

當(dāng)前時(shí)段接受的信封數(shù)量。

這表示已成功通過(guò)速率限制和過(guò)濾器并已發(fā)送到上游的請(qǐng)求。

event.corrupted (Counter)

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

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

event.processing_time (Timer)

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

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

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

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

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

event.protocol (Counter)

命中任何類似 store 的端點(diǎn)的事件數(shù)量：Envelope、Store、Security、Minidump、Unreal。

事件在被速率限制、過(guò)濾或以任何方式處理之前被計(jì)數(shù)。

該指標(biāo)標(biāo)記為：

version: 事件協(xié)議版本號(hào)默認(rèn)為 7。

event.queue_size (Histogram)

隊(duì)列中的信封數(shù)。

隊(duì)列保存在 Relay 中特定時(shí)間正在處理的所有信封：

• 當(dāng) Relay 收到請(qǐng)求時(shí)，它確保提交的數(shù)據(jù)被包裝在一個(gè)信封中。
• 信封接受一些初步處理以確定它是否可以被處理或是否必須被拒絕。
• 一旦做出此決定，創(chuàng)建信封的 HTTP 請(qǐng)求就會(huì)終止，如果要進(jìn)一步處理該請(qǐng)求，則信封將進(jìn)入隊(duì)列。
• 在信封完成處理并被發(fā)送到上游后，信封被視為已處理并離開(kāi)隊(duì)列。

隊(duì)列大小可以通過(guò) cache.event_buffer_size 配置。

event.queue_size.pct (Histogram)

隊(duì)列中的信封數(shù)占隊(duì)列中可存儲(chǔ)的最大信封數(shù)的百分比。

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

event.rejected (Counter)

當(dāng)前時(shí)間段內(nèi)拒絕的信封數(shù)量。

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

要檢查拒絕原因，請(qǐng)檢查 events.outcomes。

event.size_bytes.raw (Histogram)

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

• 對(duì)于信封請(qǐng)求，這是信封的完整尺寸。
• 對(duì)于 JSON 存儲(chǔ)請(qǐng)求，這是 JSON 正文的大小。
• 對(duì)于崩潰報(bào)告和附件的分段上傳，這是 multipart body 的大小，包括邊界。

如果這個(gè)請(qǐng)求包含一個(gè) base64 zlib 壓縮的有效載荷，而沒(méi)有正確的 content-encoding 頭，那么這是解壓前的大小。

最大請(qǐng)求 body 大小可以通過(guò) limits.max_envelope_size 進(jìn)行配置。

event.size_bytes.uncompressed (Histogram)

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

JSON 存儲(chǔ)請(qǐng)求可能包含 base64 zlib 壓縮負(fù)載，而沒(méi)有正確的 content-encoding 頭。在這種情況下，該指標(biāo)包含解碼后的大小。否則，它總是等于 event.size_bytes.raw。

event.total_time (Timer)

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

event.wait_time (Timer)

在 Relay 中接收請(qǐng)求(即請(qǐng)求處理開(kāi)始)和 EnvelopeProcessor 中開(kāi)始同步處理之間花費(fèi)的時(shí)間。該指標(biāo)主要表示事件處理中的積壓。

event_processing.deserialize (Timer)

將事件從 JSON 字節(jié)反序列化為 Relay 在其上運(yùn)行的原生數(shù)據(jù)結(jié)構(gòu)所花費(fèi)的時(shí)間(以毫秒為單位)。

event_processing.filtering (Timer)

在事件上運(yùn)行入站數(shù)據(jù)過(guò)濾器所花費(fèi)的時(shí)間(以毫秒為單位)。

event_processing.pii (Timer)

當(dāng)前事件的數(shù)據(jù)清理所花費(fèi)的時(shí)間(以毫秒為單位)。數(shù)據(jù)清理最后發(fā)生在將事件序列化回 JSON 之前。

event_processing.process (Timer)

在事件上運(yùn)行事件處理器以進(jìn)行標(biāo)準(zhǔn)化所花費(fèi)的時(shí)間(以毫秒為單位)。事件處理發(fā)生在過(guò)濾之前。

event_processing.rate_limiting (Timer)

檢查組織、項(xiàng)目和 DSN 速率限制所花費(fèi)的時(shí)間(以毫秒為單位)。

事件第一次被限速后，限速會(huì)被緩存。在此之后進(jìn)入的事件將在請(qǐng)求隊(duì)列中更早地被丟棄并且不會(huì)到達(dá)處理隊(duì)列。

event_processing.serialization (Timer)

將事件從其內(nèi)存表示轉(zhuǎn)換為 JSON 字符串所花費(fèi)的時(shí)間。

events.outcomes (Counter)

拒絕信封的 outcome 和 reason 的數(shù)量。

該指標(biāo)標(biāo)記為：

• outcome: 拒絕事件的基本原因。
• reason: 描述導(dǎo)致 outcome 的規(guī)則或機(jī)制的更詳細(xì)的標(biāo)識(shí)符。
• to: 描述 outcome 的目的地?？梢允?kafka(處于處理模式時(shí))或 http(在外部 relay 中啟用 outcome 時(shí))。

可能的 outcome 是：

• filtered: 被入站數(shù)據(jù)過(guò)濾器丟棄。reason 指定匹配的過(guò)濾器。
• rate_limited: 被組織、項(xiàng)目或 DSN 速率限制丟棄，以及超過(guò) Sentry 計(jì)劃配額。reason 包含超出的速率限制或配額。
• invalid: 數(shù)據(jù)被視為無(wú)效且無(wú)法恢復(fù)。原因表明驗(yàn)證失敗。

http_queue.size (Histogram)

排隊(duì)等待發(fā)送的上游請(qǐng)求數(shù)。

盡可能使連接保持活動(dòng)。連接保持打開(kāi)狀態(tài) 15 秒不活動(dòng)或 75 秒活動(dòng)。如果所有連接都忙，它們將排隊(duì)，這反映在此指標(biāo)中。

該指標(biāo)標(biāo)記為：

• priority: 請(qǐng)求的排隊(duì)優(yōu)先級(jí)，可以是 "high" 或 "low"。優(yōu)先級(jí)決定了執(zhí)行請(qǐng)求的優(yōu)先順序。

并發(fā)連接數(shù)可以配置為：

• limits.max_concurrent_requests 連接總數(shù)
• limits.max_concurrent_queries 表示并發(fā)高優(yōu)先級(jí)請(qǐng)求的數(shù)量

metrics.buckets (Gauge)

Relay 的指標(biāo)聚合器中的 metric bucket 總數(shù)。

metrics.buckets.created.unique (Set)

計(jì)算創(chuàng)建的唯一 bucket 的數(shù)量。

這是一組 bucket 鍵。指標(biāo)基本上等同于單個(gè) Relay 的 metrics.buckets.merge.miss，但對(duì)于確定多個(gè)實(shí)例正在運(yùn)行時(shí)有多少重復(fù) bucket 可能很有用。

Hash 目前取決于平臺(tái)，因此發(fā)送此指標(biāo)的所有 Relay 應(yīng)在相同的 CPU 架構(gòu)上運(yùn)行，否則此指標(biāo)不可靠。

metrics.buckets.flushed (Histogram)

在所有項(xiàng)目的一個(gè)周期中刷新的 metric buckets 總數(shù)。

metrics.buckets.flushed_per_project (Histogram)

每個(gè)項(xiàng)目在一個(gè)周期中刷新的 metric buckets 數(shù)。

Relay 定期掃描 metric buckets 并刷新過(guò)期的桶。為每個(gè)正在刷新的項(xiàng)目記錄此直方圖。直方圖值的計(jì)數(shù)相當(dāng)于正在刷新的項(xiàng)目數(shù)。

metrics.buckets.merge.hit (Counter)

每次合并兩個(gè) bucket 或兩個(gè) metric 時(shí)遞增。

按 metric 類型和名稱標(biāo)記。

metrics.buckets.merge.miss (Counter)

每次創(chuàng)建 bucket 時(shí)遞增。

按 metric 類型和名稱標(biāo)記。

metrics.buckets.parsing_failed (Counter)

從信封中解析指標(biāo) bucket 項(xiàng)目失敗的次數(shù)。

metrics.buckets.scan_duration (Timer)

掃描指標(biāo) bucket 以刷新所花費(fèi)的時(shí)間(以毫秒為單位)。

Relay 定期掃描指標(biāo) bucket 并刷新過(guò)期的 bucket。此計(jì)時(shí)器顯示執(zhí)行此掃描并從內(nèi)部緩存中刪除 bucket 所需的時(shí)間。將指標(biāo)桶發(fā)送到上游不在此計(jì)時(shí)器范圍內(nèi)。

metrics.insert (Counter)

針對(duì)插入的每個(gè)指標(biāo)遞增。

按指標(biāo)類型和名稱標(biāo)記。

outcomes.aggregator.flush_time (Timer)

outcome 聚合器刷新聚合 outcomes 所需的時(shí)間。

processing.event.produced (Counter)

放置在 Kafka 隊(duì)列上的消息數(shù)

當(dāng) Relay 作為 Sentry 服務(wù)運(yùn)行并且一個(gè) Envelope 項(xiàng)目被成功處理時(shí)，每個(gè) Envelope 項(xiàng)目都會(huì)產(chǎn)生一條關(guān)于 Kafka 攝取主題的專用消息。

這個(gè)指標(biāo)被標(biāo)記為：

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

消息類型可以是：

• event: error 或 transaction 事件。錯(cuò)誤事件發(fā)送到 ingest-events，事務(wù)發(fā)送到 ingest-transactions，帶有附件的錯(cuò)誤發(fā)送到 ingest-attachments。
• attachment: 與錯(cuò)誤事件關(guān)聯(lián)的附件文件，發(fā)送到 ingest-attachments。
• user_report: 來(lái)自用戶反饋對(duì)話框的消息，發(fā)送到 ingest-events。
• session: release health session 更新，發(fā)送到 ingest-sessions。

processing.produce.error (Counter)

在信封已排隊(duì)發(fā)送到 Kafka 后發(fā)生的生產(chǎn)者錯(cuò)誤數(shù)。

例如，這些錯(cuò)誤包括 "MessageTooLarge" 當(dāng) broker 不接受超過(guò)特定大小的請(qǐng)求時(shí)的錯(cuò)誤，這通常是由于無(wú)效或不一致的 broker/producer 配置造成的。

project_cache.eviction (Counter)

從緩存中驅(qū)逐的陳舊項(xiàng)目的數(shù)量。

Relay 會(huì)以 cache.eviction_interval 配置的固定時(shí)間間隔掃描內(nèi)存項(xiàng)目緩存中的陳舊條目。

可以使用以下選項(xiàng)配置項(xiàng)目狀態(tài)的緩存持續(xù)時(shí)間：

• cache.project_expiry: 項(xiàng)目狀態(tài)過(guò)期的時(shí)間。如果請(qǐng)求在過(guò)期后引用了項(xiàng)目，則會(huì)自動(dòng)刷新。
• cache.project_grace_period: 過(guò)期后項(xiàng)目狀態(tài)仍將用于接收事件的時(shí)間。一旦寬限期到期，緩存將被逐出，新請(qǐng)求將等待更新。

project_cache.hit (Counter)

從緩存中查找項(xiàng)目的次數(shù)。

緩存可能包含過(guò)時(shí)或過(guò)期的項(xiàng)目狀態(tài)。在這種情況下，即使在緩存命中后，項(xiàng)目狀態(tài)也會(huì)更新。

project_cache.miss (Counter)

項(xiàng)目查找失敗的次數(shù)。

立即創(chuàng)建緩存條目，并從上游請(qǐng)求項(xiàng)目狀態(tài)。

project_cache.size (Histogram)

當(dāng)前保存在內(nèi)存項(xiàng)目緩存中的項(xiàng)目狀態(tài)數(shù)。

可以使用以下選項(xiàng)配置項(xiàng)目狀態(tài)的緩存持續(xù)時(shí)間:

• cache.project_expiry: 項(xiàng)目狀態(tài)計(jì)為過(guò)期的時(shí)間。如果請(qǐng)求在項(xiàng)目過(guò)期后引用該項(xiàng)目，它會(huì)自動(dòng)刷新。
• cache.project_grace_period: 到期后項(xiàng)目狀態(tài)仍將用于攝取事件的時(shí)間。一旦寬限期到期，緩存被逐出，新請(qǐng)求等待更新。

緩存項(xiàng)目的數(shù)量沒(méi)有限制。

project_state.eviction.duration (Timer)

驅(qū)逐過(guò)時(shí)和未使用的項(xiàng)目所花費(fèi)的總時(shí)間(以毫秒為單位)。

project_state.get (Counter)

從緩存中查找項(xiàng)目狀態(tài)的次數(shù)。

這包括對(duì)緩存項(xiàng)目和新項(xiàng)目的查找。作為其中的一部分，會(huì)觸發(fā)對(duì)過(guò)時(shí)或過(guò)期項(xiàng)目緩存的更新。

相關(guān)指標(biāo):

project_cache.hit: 用于成功的緩存查找，即使是過(guò)時(shí)的項(xiàng)目。

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

使用 .no-cache 請(qǐng)求項(xiàng)目配置的次數(shù)。

這有效地計(jì)算了使用相應(yīng) DSN 發(fā)送的信封或事件的數(shù)量。對(duì)于這些項(xiàng)目狀態(tài)請(qǐng)求，對(duì)上游的實(shí)際查詢可能仍會(huì)進(jìn)行重復(fù)數(shù)據(jù)刪除。

每個(gè) project key 每秒最多允許 1 個(gè)此類請(qǐng)求。此指標(biāo)僅計(jì)算允許的請(qǐng)求。

project_state.pending (Histogram)

內(nèi)存項(xiàng)目緩存中等待狀態(tài)更新的項(xiàng)目數(shù)。

有關(guān)項(xiàng)目緩存的更多說(shuō)明，請(qǐng)參閱 project_cache.size。

project_state.received (Histogram)

每個(gè)批處理請(qǐng)求從上游 返回 的項(xiàng)目狀態(tài)數(shù)。

如果同時(shí)更新多個(gè)批次，則會(huì)多次報(bào)告此指標(biāo)。

有關(guān)項(xiàng)目緩存的更多說(shuō)明，請(qǐng)參閱 project_cache.size。

project_state.request (Counter)

項(xiàng)目狀態(tài) HTTP 請(qǐng)求的數(shù)量。

Relay 批量更新項(xiàng)目。每個(gè)更新周期，Relay 從上游請(qǐng)求 limits.max_concurrent_queries 批次的 cache.batch_size 項(xiàng)目。這些請(qǐng)求的持續(xù)時(shí)間通過(guò) project_state.request.duration 報(bào)告。

請(qǐng)注意，更新循環(huán)完成后，可能會(huì)有更多項(xiàng)目等待更新。這由 project_state.pending 指示。

project_state.request.batch_size (Histogram)

對(duì)于每個(gè)批處理請(qǐng)求，來(lái)自上游的 requested 項(xiàng)目狀態(tài)數(shù)量。

如果同時(shí)更新多個(gè)批次，則會(huì)多次報(bào)告此指標(biāo)。

批量大小可以通過(guò) cache.batch_size 配置。有關(guān)項(xiàng)目緩存的更多說(shuō)明，請(qǐng)參閱 project_cache.size。

project_state.request.duration (Timer)

獲取要解決的排隊(duì)項(xiàng)目配置更新請(qǐng)求所花費(fèi)的總時(shí)間(以毫秒為單位)。

Relay 批量更新項(xiàng)目。每個(gè)更新周期，Relay 從上游請(qǐng)求 limits.max_concurrent_queries * cache.batch_size 項(xiàng)目。此指標(biāo)測(cè)量此循環(huán)中所有并發(fā)請(qǐng)求的掛鐘時(shí)間。

請(qǐng)注意，更新循環(huán)完成后，可能會(huì)有更多項(xiàng)目等待更新。這由 project_state.pending 指示。

requests (Counter)

到達(dá) Relay 的 HTTP 請(qǐng)求數(shù)。

requests.duration (Timer)

在 HTTP 響應(yīng)返回給客戶端之前處理入站 Web 請(qǐng)求的總持續(xù)時(shí)間(以毫秒為單位)。

這不對(duì)應(yīng)于完整的事件攝取時(shí)間。由于錯(cuò)誤數(shù)據(jù)或緩存速率限制而未立即拒絕的事件請(qǐng)求始終返回 200 OK。完全驗(yàn)證和規(guī)范化是異步發(fā)生的，由 event.processing_time 報(bào)告。該指標(biāo)標(biāo)記為：

• method: 請(qǐng)求的 HTTP 方法。
• route: 端點(diǎn)的唯一虛線標(biāo)識(shí)符。

requests.timestamp_delay (Timer)

負(fù)載中規(guī)定的時(shí)間戳與接收時(shí)間之間的延遲。

SDK 無(wú)法在所有情況下立即傳輸有效載荷。有時(shí)，崩潰需要在重新啟動(dòng)應(yīng)用程序后發(fā)送事件。同樣，SDK 在網(wǎng)絡(luò)停機(jī)期間緩沖事件以供以后傳輸。該指標(biāo)衡量事件發(fā)生時(shí)間與其到達(dá) Relay 時(shí)間之間的延遲。該指標(biāo)衡量事件發(fā)生時(shí)間與其到達(dá) Relay 時(shí)間之間的延遲。

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

該指標(biāo)標(biāo)記為：

• category: 有效載荷的數(shù)據(jù)類別?？梢允且韵轮唬篹vent、transaction、security 或 session。

responses.status_codes (Counter)

已完成的 HTTP 請(qǐng)求數(shù)。

該指標(biāo)標(biāo)記為：

• status_code: HTTP 狀態(tài)代碼編號(hào)。
• method: 請(qǐng)求中使用的 HTTP 方法(大寫(xiě))。
• route: 端點(diǎn)的唯一虛線標(biāo)識(shí)符。

scrubbing.attachments.duration (Timer)

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

scrubbing.minidumps.duration (Timer)

花在 minidump 清理上的時(shí)間。

這是解析和清理 minidump 所花費(fèi)的總時(shí)間。即使沒(méi)有應(yīng)用 minidump 的 PII 清理規(guī)則，仍將解析并在解析的 minidump 上評(píng)估規(guī)則，此持續(xù)時(shí)間在此處報(bào)告，狀態(tài)為 "n/a"。

這個(gè)指標(biāo)被標(biāo)記為:

• status: Scrubbing status: "ok" 表示清洗成功, "error" 表示清理過(guò)程中出現(xiàn)錯(cuò)誤，最后 "n/a" 表示清理成功但未應(yīng)用清理規(guī)則。

server.starting (Counter)

Relay server 啟動(dòng)的次數(shù)。

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

unique_projects (Set)

表示當(dāng)前時(shí)間片內(nèi)的活動(dòng)項(xiàng)目數(shù)

upstream.network_outage (Gauge)

Relay 相對(duì)于上游連接的狀態(tài)。可能的值為 0(正常操作)和 1(網(wǎng)絡(luò)中斷)。

upstream.requests.duration (Timer)

將請(qǐng)求發(fā)送到上游 Relay 并處理響應(yīng)所花費(fèi)的總時(shí)間。

該指標(biāo)標(biāo)記為：

• result: 請(qǐng)求發(fā)生了什么，具有以下值的枚舉:
• success: 請(qǐng)求已發(fā)送并返回成功代碼 HTTP 2xx
• response_error: 請(qǐng)求已發(fā)送并返回 HTTP 錯(cuò)誤。
• payload_failed: 請(qǐng)求已發(fā)送，但在解釋響應(yīng)時(shí)出錯(cuò)。
• send_failed: 由于網(wǎng)絡(luò)錯(cuò)誤，無(wú)法發(fā)送請(qǐng)求。
• rate_limited: 請(qǐng)求被限速。
• invalid_json: 無(wú)法將響應(yīng)解析回 JSON。
• route: 在上游調(diào)用的端點(diǎn)。
• status-code: 可用時(shí)請(qǐng)求的狀態(tài)碼，否則為"-"。
• retries: 重試次數(shù)存儲(chǔ)桶 0、1、2、很少(3 - 10)、很多(超過(guò) 10)。

upstream.retries (Histogram)

計(jì)算每個(gè)上游 http 請(qǐng)求的重試次數(shù)。

該指標(biāo)標(biāo)記為：

• result: 請(qǐng)求發(fā)生了什么，具有以下值的枚舉:
• success: 請(qǐng)求已發(fā)送并返回成功代碼 HTTP 2xx
• response_error: 請(qǐng)求已發(fā)送并返回 HTTP 錯(cuò)誤。
• payload_failed: 請(qǐng)求已發(fā)送，但在解釋響應(yīng)時(shí)出錯(cuò)。
• send_failed: 由于網(wǎng)絡(luò)錯(cuò)誤，無(wú)法發(fā)送請(qǐng)求。
• rate_limited: 請(qǐng)求被限速。
• invalid_json: 無(wú)法將響應(yīng)解析回 JSON。
• route: 在上游調(diào)用的端點(diǎn)。
• status-code: 可用時(shí)請(qǐng)求的狀態(tài)碼，否則為"-"。