日志记录
Relay 将日志生成到规范不正确流 (stderr)，默认状况下具备 INFO 日志记录级别。例如，运行 Relay 后，您也许会见到如下所示输出：
此实例表明具备默认日志记录级别 (INFO) 的信息，您可以编辑该级别以表明大量或更少的信息内容。相关配备日志记录的详细资料，客户程序选择项网页页面上的日志记录一部分。
- https://docs.sentry.io/product/relay/options/#logging
错误提示
默认状况下，Relay 将不正确记录到配备的 logger 中。您可以在 Relay 环境变量中的 Sentry 中为您的新项目开启错误提示：
可以在选择项网页页面上寻找相关可以用选择项以及含意的其他信息。
- https://docs.sentry.io/product/relay/options/#internal-error-reporting
健康体检
Relay 给予了2个 URL 来查验系统状态：
- GET /api/relay/healthcheck/live/: 检测 Relay 是不是已经运作并监视 HTTP 要求。
- GET /api/relay/healthcheck/ready/: 检测 Relay 是不是根据上下游认证并常规运作。
取得成功时，2个节点都回到 200 OK 回应：
指标值
您可以根据将 metrics.statsd key 配备为 ip:port 元组来向 StatsD server 递交统计数据。可以设定为 ip:port 元组。
实例配备
用以配备指标值汇报的选择项记录在选项网页页面上。
- https://docs.sentry.io/product/relay/options/#statsd-metrics
Relay 搜集下列指标值
event.accepted (Counter)
现阶段时间段接纳的信封袋总数。
这表明已取得成功根据速度限定和过滤装置并已发送至上下游的要求。
event.corrupted (Counter)
损坏(不能打印出)事情特性的事情数。
现阶段，这会查验 environment 和 release，我们知道一些 SDK 很有可能会推送毁坏的值。
event.processing_time (Timer)
同歩解决信封袋所耗费的時间(以ms为企业)。
这时序包含 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)
信封袋从接受到进行解决并提交到上下游的总時间(以ms为企业)。
event.wait_time (Timer)
在 Relay 中接受要求(即请求解决逐渐)和 EnvelopeProcessor 中开始同歩解决中间耗费的時间。该标准关键表明事故处理中的库存积压。
event_processing.deserialize (Timer)
将事情从 JSON 字节数反序列化为 Relay 在其上运转的原生态算法设计所耗费的時间(以ms为企业)。
event_processing.filtering (Timer)
在事情上运作入站数据信息过滤装置所耗费的時间(以ms为企业)。
event_processing.pii (Timer)
现阶段事情的数据清理所耗费的時间(以ms为企业)。数据清理最终产生在将事情实例化回 JSON 以前。
event_processing.process (Timer)
在事件上运作事件CPU以开展规范化所花费的時间(以ms为企业)。事件解决产生在过虑以前。
event_processing.rate_limiting (Timer)
查验机构、新项目和 DSN 速率限定所花费的時间(以ms为企业)。
事件第一次被限制网速后，限速会被缓存文件。人物角色进到的事件将在请求序列中更早的被丢弃而且不容易抵达解决序列。
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)
每一次合拼2个 bucket 或两个 metric 时增长。
按 metric 种类和名字标识。
metrics.buckets.merge.miss (Counter)
每一次建立 bucket 时增长。
按 metric 种类和名字标识。
metrics.buckets.parsing_failed (Counter)
从信封袋中分析指标值 bucket 新项目错误的频次。
metrics.buckets.scan_duration (Timer)
扫描仪指标值 bucket 以更新所花费的時间(以ms为企业)。
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)
驱赶落伍和未采用的新项目所花费的总時间(以ms为企业)。
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)
获得要化解的排长队项目配备升级请求所耗费的总時间(以ms为企业)。
Relay 批量更新项目。每一个升级周期时间，Relay 从上下游请求 limits.max_concurrent_queries * cache.batch_size 项目。此指标精确测量此循环系统中全部高并发请求的石英钟時间。
一定要注意，升级循环系统结束后，很有可能会出现大量项目等候升级。这由 project_state.pending 标示。
requests (Counter)
抵达 Relay 的 HTTP 请求数。
requests.duration (Timer)
在 HTTP 回应回到给手机客户端以前解决入站 Web 请求的总延迟时间(以ms为企业)。
这并不相匹配于详细的事件摄入時间。因为不正确数据信息或缓存文件速度限定而未马上回绝的事件请求自始至终回到 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: 可以用时请求的状态码，不然为"-"。