Sentry 企业级数据安全解决方案 – Relay 监控 & 指标收集

日志记录

Relay 将日志生成到标准错误流 (stderr)，默认情况下具有 INFO 日志记录级别。例如，启动 Relay 后，您可能会看到如下输出：

INFOrelay::setup>launchingrelayfromconfigfolder.relay
INFOrelay::setup>relaymode:managed
INFOrelay::setup>relayid:cde0d72e-0c4e-4550-a934-c1867d8a177c
INFOrelay::setup>loglevel: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:
#EndpointofyourStatsDserver
statsd:127.0.0.1:8126
#Prefixallmetricnameswiththisstring
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: 可用时请求的状态码，否则为"-"。