Sentry 企业级数据安全解决方案 - Relay 操作指南


本篇回顾了我们在自托管外部使用 Relay 时的操作指南,即在您的硬件上运行的 Relay 并将事件转发到 sentry.io。

注意事项

  • 我们建议使用官方提供的 Docker 镜像(getsentry/Relay)运行 Relay,该镜像位于 DockerHub 上,并带有 Git 修订标识符,而不是从源代码构建。
    • https://hub.docker.com/r/getsentry/relay/
  • 我们建议至少运行两个 Relay 实例(容器),并在它们前面使用反向代理(例如 HAProxy 或 Nginx),以提高可用性并简化 Relay 更新。
    • https://www.haproxy.org/
    • https://nginx.org
  • 要监控您的 Relay 设置,请配置 日志记录, 指标, 和 健康检查。
    • https://docs.sentry.io/product/relay/monitoring/#logging
    • https://docs.sentry.io/product/relay/monitoring/#metrics
    • https://docs.sentry.io/product/relay/monitoring/#health-checks

系统要求和建议

以下建议假设 Relay 在 Docker 中运行。

资源建议
CPU
  • 必需: x86-64 (amd64) CPU 架构

  • 多核 CPU

内存
  • 建议每个 Relay 容器至少有 2GB 的 RAM。

网络
  • 带宽:确保您有足够的容量来接收和转发计划的数据量。默认情况下,Relay 会将所有上游请求压缩到 sentry.io,但压缩率可能会因提交事件的类型和形状而异。

  • 延迟:Relay 可以容忍网络延迟达到某个点。但是建议确保到上游的往返时间保持低于 5 秒。

存储
  • Relay 当前不需要磁盘存储。

Relay 是一个多线程应用程序,它试图利用所有可用的 CPU 内核。因此,Sentry 强烈建议在多核 CPU 上运行 Relay。如果您的设置预计每秒处理 100 个以上的请求,我们建议在至少四 (4) 个 CPU 内核上运行 Relay。默认情况下,每个 Relay 实例将使用可用内核的总数来调整其线程池的大小。通过配置 limits.max_thread_count 来调整此行为。

示例配置

此示例配置设置基本日志记录和指标设置,以及更改默认并发级别。

  1. ---
  2. relay:
  3. # The upstream hostname is taken from any of your DSNs.
  4. # Go to your Project Settings, and then to "Client Keys (DSN)" to see them.
  5. upstream: https://___ORG_INGEST_DOMAIN___.
  6. host: 0.0.0.0
  7. port: 3000
  8. logging:
  9. level: info
  10. format: json
  11. metrics:
  12. statsd: 127.0.0.1:8126
  13. prefix: relay
  14. limits:
  15. # Base size of various internal thread pools. Defaults to the number of logical CPU cores
  16. max_thread_count: 8

有关所有可用选项的详细说明,请参阅配置选项页面。

性能调优

Relay 提供了多种配置选项。与其他选项相比,更改某些选项对 Relay 的行为的影响更大。以下列表列出了当您想要根据组织的环境和工作负载调整 Relay 时应首先检查的几个选项:

  • limits.max_concurrent_requests (default: 100)

您的 Relay 实例可以发送到上游 (Sentry) 的并发请求数。如果您的事件量或 Sentry 的连接延迟很高,您可以增加此值以获得额外的吞吐量,尽管增加的代价是额外的网络连接。

  • cache.event_buffer_size (default: 1000)

在开始拒绝新事件之前,Relay 可以在其本地队列中缓冲多少事件。例如,当网络问题阻止 Relay 将接收到的消息转发到 Sentry 时,增加此值也会增加 Relay 的潜在内存消耗。

  • cache.event_expiry (in seconds, default: 600)

在丢弃事件之前,Relay 可以将缓冲的事件保留在内存中的时间。如果您预计 Relay 可能需要在内存中保留事件的时间比默认值长,则可以增加此值。

  • cache.project_expiry (in seconds, default: 300)

为了保持正常运行,Relay 会定期从 Sentry 上游获取项目配置。此设置控制 Relay 获取该配置的频率。您可以减小此值以使配置传播更加频繁。例如,如果您稍后在 Sentry 的项目设置中更改数据清理选项,您的 Relay 实例将更快地意识到这些更改。

  • cache.project_grace_period (in seconds, default: 0)

项目配置过期后仍可使用多长时间。当上游无法访问时,增加此值可能会有所帮助;例如,由于网络问题。

请求路由

SDK 在一组端点上与 Sentry 通信。Relay 提供相同的 API 以成为无缝替代品。这需要一组端点可以访问:

  • /api//envelope/
  • /api//minidump/
  • /api//security/
  • /api//store/
  • /api//unreal/

根据 SDK 或客户端,对这些端点的请求使用压缩内容编码(compressed content-encoding)或分块传输编码(chunked transfer-encoding)执行。根据 Relay 前面的基础设施,请检查以下 HTTP 头设置是否正确:

  • Host: 到此 Relay 的公共主机名
  • X-Forwarded-For: 到客户端 IP 地址
  • X-Sentry-Auth: 客户端提供的值

代理通常为请求设置默认的最大 body 大小。尤其是原生崩溃报告和附件可能会超出这些限制。我们建议将最大客户端 body 大小配置为 100MB。

在内部,Relay 向已配置的上游发出请求以转发数据并检索项目配置。我们 强烈建议 不要限制这些请求。目前,Relay 向以下端点发出请求以进行基本操作:

以上所有端点:

  • /api/0/relays/projectconfigs/
  • /api/0/relays/publickeys/
  • /api/0/relays/register/challenge/
  • /api/0/relays/register/response/
盘点:Log4j 漏洞带来的深远影响

上周,Log4j 漏洞颠覆了互联网,影响是巨大。攻击者也已经开始利用该漏,到目前为止,Uptycs 研究人员已经观察到与 coinminers、DDOS 恶意软件和一些勒索软件变种相关的攻击,这些攻击积极利用了此漏洞。未来几天勒索软件攻击的规模可能会增加。由于...
漏洞服务器安全log4j

Linux 使用rpm方式安装最新mysql(5.7.16)步骤及常见问题解决方法

前几天在阿里云买了个服务器 ,准备自己玩玩,现将最新版mysql(5.7.16)安装步骤,以及遇到问题及解决过程分享如下:第一步:下载rpm包MySQL官网下载:http://dev.mysql.com/downloads/mysql/但如果你的下载网速不好的...
linuxrpmmysql

如何使用Whispers识别静态结构化文本中的硬编码敏感信息

关于WhispersWhispers是一款功能强大的静态代码分析工具,该工具可以帮助广大研究人员解析各种常见的数据格式,并搜索硬编码凭证和危险函数。Whispers支持在命令行终端中运行,或者也可以将其集成到CI/CD管道中。检测功能密码API令牌AWS密钥私...
服务器安全安全工具Whispers静态代码分析

Linux 服务器安全技巧

毋庸置疑,对于系统管理员,提高服务器的安全性是最重要的事情之一。因此,也就有了许多针对这个话题而生的文章、博客和论坛帖子。一台服务器由大量功能各异的部件组成,这一点使得很难根据每个人的需求去提供定制的解决方案。这篇文章尽可能涵盖一些有所裨益的小技巧来帮助管理员...
linux服务器安全