0

さまざまな API に接続する Adpapter クラスのコレクションがあります。以下に、各アダプターのセットアップ方法の簡単で一般的な例を示します。

class AmazonAdapter
    include Sidekiq::Worker
    def perform(id)
        get_results_from_api(id)
    end
end

class WalmartAdapter
    include Sidekiq::Worker
    def perform(id)
        get_results_from_api(id)
    end
end

したがって、通常、 を呼び出すとAmazonAdapter.new(500)、API に接続され、ID として渡された内容に従って結果が返されます。これはすべて Sidekiq コレクション プロセスの一部であり、バックグラウンド ジョブとして実行されるため、何か問題が発生したときに警告するために、必ずしも明白な例外やエラーをスローするとは限りません。

AirBrake の通知システムを使用して、API が正しく接続されていない場合やその他のエラーがスローされた場合に通知を受け取りたいのですが、収集プロセスや sidekiq を停止する必要はありません。エラー処理と通知システムをメインストリーム化することを望んでいました。

私が考えているいくつかの考えは、サブクラスが継承できる ParentClass を作成することです。これは次のようになります。

class Adapter
    include Sidekiq::Worker
    def perform(id)
        begin
            #execute subclass perform method
        rescue Exception => e
            Airbrake.notify(e)
        end
    end
end

しかし、これを行う最善の方法についてはよくわかりません。私は本当にこれについていくつかのアドバイスや助けを使うことができました、ありがとう!

4

2 に答える 2

0

同様の構成を使用して、いくつかの chron ジョブの失敗を警告し、slack チャネルに ping を送信しますが、良い点は継承を必要としないことです! その単純なバージョンは次のようになります。

class AirbrakeNotifier
  def safe_run
    yield
  rescue StandardError => e
    log_error(e)
    raise e
  end

  private

  def log_error(e)
    # do your logging here
  end
end

そして、ワーカーは次のようになります。

class AmazonAdapter
  include Sidekiq::Worker

  def perform(id)
    AirbrakeNotifier.new.safe_run { get_results_from_api(id) }
  end
end

これにより、クラスごと、プロセスごと、または実際に考えられる方法で、さまざまな方法でログを構成する柔軟性が大幅に向上します!

于 2016-09-21T21:06:19.507 に答える