时间戳

首页 > 解决方案 > 我如何告诉 Sentry 不要提醒某些异常？

ruby-on-rails - 我如何告诉 Sentry 不要提醒某些异常？

问题描述

我有一个 Rails 5 应用程序使用raven-ruby向 Sentry 发送异常，然后 Sentry 向我们的 Slack 发送警报。

Raven.configure do |config|
  config.dsn = ENV['SENTRY_DSN']
  config.environments = %w[ production development ]
  config.excluded_exceptions += []
  config.async = lambda { |event|
    SentryWorker.perform_async(event.to_hash)
  }
end

class SentryWorker < ApplicationWorker
  sidekiq_options queue: :default

  def perform(event)
    Raven.send_event(event)
  end
end

我们的 Sidekiq 作业抛出异常并被重试是正常的。这些大多是间歇性的 API 错误和超时，它们会在几分钟内自行清除。Sentry 正在尽职尽责地向我们的 Slack 发送这些错误警报。

我已经将其添加retry_count到了 jobs中。如何防止 Sentry 向 Slack 发送 retry_count < N 的异常，同时仍提醒其他异常？不应警告的示例将具有如下额外上下文：

sidekiq: {
  context: Job raised exception,
  job: {
    args: [{...}],
    class: SomeWorker,
    created_at: 1540590745.3296254,
    enqueued_at: 1540607026.4979043,
    error_class: HTTP::TimeoutError,
    error_message: Timed out after using the allocated 13 seconds,
    failed_at: 1540590758.4266324,
    jid: b4c7a68c45b7aebcf7c2f577,
    queue: default,
    retried_at: 1540600397.5804272,
    retry: True,
    retry_count: 2
  },
}

根本不将它们发送到 Sentry 与将它们发送到 Sentry 但未收到警报的利弊是什么？

标签： ruby-on-railsruby-on-rails-5sentry

解决方案

概括

对我来说效果很好的一个选项是通过在异常上配置Sentryshould_capture和 Sidekiq 的sidekiq_retries_exhausted自定义属性。

细节

1a。添加自定义属性

您可以将自定义属性添加到异常。您可以在任何错误类上定义它attr_accessor：

class SomeError
  attr_accessor :ignore

  alias ignore? ignore
end

1b。抢救错误，设置自定义属性，并重新引发

def perform
  # do something
rescue SomeError => e
  e.ignore = true
  raise e
end
  1. 配置should_capture

should_capture允许您在满足定义的条件时捕获异常。异常被传递给它，您可以在其上访问自定义属性。

config.should_capture { |e| !e.ignore? }

  1. 重试次数用尽时翻转自定义属性

根据所使用的 Sidekiq 版本，有两种方法可以定义您希望在作业终止时发生的行为。如果您想在全球范围内申请并拥有 sidekiq v5.1+，您可以使用死亡处理程序。如果您想申请特定的工人或低于 v5.1，您可以使用sidekiq_retries_exhausted.

sidekiq_retries_exhausted { |_job, ex| ex.ignore = false }

推荐阅读