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

日志记录

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) 的消息，您可以修改该级别以显示更多或更少的信息。有关配置日志记录的详细信息，请参阅选项页面上的日志记录部分。

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

错误报告

默认情况下，Relay 将错误记录到配置的 logger 中。您可以在 Relay 配置文件中的 Sentry 中为您的项目启用错误报告：

  
 
 
   
  
  sentry: 
   
  
    enabled: true 
   
  
    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: 
   
  
    # Endpoint of your StatsD server 
   
  
    statsd: 127.0.0.1:8126 
   
  
    # Prefix all metric names with this string 
   
  
    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)

从缓存中查找项目状态的次数。

这包括对缓存项目和新项目的查找。作为其中的一部分，会触发对过时或过期项目缓存的更新。