Wenn Sie sidekiq einführen, das Jobs asynchron verarbeitet, können Sie Einstellungen anpassen, die in solchen Fällen nützlich sind, wenn Sie sie für Ihre eigene Anwendung anpassen und dabei die Vorteile nutzen möchten Es ist zusammengefasst.
sidekiq ist eine Bibliothek, die die asynchrone Verarbeitung ermöglicht. Wenn Sie mehrere Jobs gleichzeitig ausführen, können Sie die Verarbeitungspriorität angeben, indem Sie den Warteschlangennamen jedes Jobs trennen. Ich denke, es gibt ähnliche Bibliotheken wie resque und delay_job. Es ist einfach zu installieren, aber es gibt auch problematische Punkte, z. B. das 25-malige oder 26-malige Wiederholen der gestolperten Warteschlange und das Nicht-Anzeigen des Protokolls der Warteschlange, die als TOT ausgeführt wurde. Es gibt. In diesem Artikel werde ich darüber sprechen, wie Sie die Obergrenze auf DEAD setzen können, ohne es erneut zu versuchen, wenn eine Ausnahme ausgelöst wird. Anschließend wird der Inhalt der Warteschlange festgelegt und eine Fehlermeldung auf "Slack" gesetzt.
Ruby 2.6.6 Rails 6.0.2 redis ist für sidekiq erforderlich.
# On OSX
brew update
brew install redis
brew services start redis
Sie können dies im Dashboard überprüfen, indem Sie Sidekiq-Fehler zum Edelstein hinzufügen, und Sie können sogar alle fehlgeschlagenen Warteschlangen wiederholen.
gem 'sidekiq-failures'
Sie können auch die Details des Fehlers in der Liste der Fehler überprüfen.
Es scheint, dass es viele andere Juwelen gibt, wie das Wissen und Analysieren der geworfenen Warteschlange, also werde ich sie als Referenz veröffentlichen.
Ich denke, dass Sidekiq eine Spezifikation hatte, die die Warteschlange beendet, nachdem sie standardmäßig etwa 25 oder 6 Mal wiederholt wurde. Für diejenigen, die viele Jobs gleichzeitig bearbeiten möchten, muss ich nicht so viel wiederholen, also habe ich es mehrmals versucht und mir gesagt, ob es fehlgeschlagen ist. Beschreiben Sie in der Datei.
app/jobs/your_job.rb
class YourJob < ActiveJob::Base
...
queue_as :default
sidekiq_options retry: 5
...
end
Damit wird die Warteschlange, die fünfmal fehlgeschlagen ist, zur TOTEN Warteschlange.
Slack-Incoming-Webhooks ist ein Juwel, das Slack-Benachrichtigungen in Rails-Apps sehr einfach macht.
gem 'slack-incoming-webhooks'
Rufen Sie die URL des zu benachrichtigenden Kanals ab [diese Seite](https://slack.com/intl/ja-jp/help/articles/115005265063-Slack-%E3%81%A7%E3%81%AE-Incoming-Webhook -Überprüfen Sie% E3% 81% AE% E5% 88% A9% E7% 94% A8).
Legen Sie fest, was zu tun ist, wenn die Warteschlange im Initialisierer stirbt (Kanal-URL in .env speichern).
app/config/initializers/sidekiq.rb
Sidekiq.configure_server do |config|
config.death_handlers << ->(job, ex) do
slack = Slack::Incoming::Webhooks.new(ENV['SLACK_WEBHOOK_URL'])
attachments = [{
title: "Sidekiq failure",
text: "ONE DEAD JOB IS FOUND:\n (#{job['args']}) \n msg(#{job['error_message']})",
color: "#fb2489"
}]
slack.post "", attachments: attachments
end
end
Warteschlangen, die natürlich TOT geworden sind, werden jetzt durch Slack benachrichtigt.
--Rescure_from Exception wird nicht wiederholt, wenn die Benachrichtigung festgelegt ist Da es sich um eine Ausnahmeverarbeitung handelt, wird der Job nach seiner Verarbeitung und dem Auftreten eines Fehlers als tot betrachtet und Sie werden über einen Durchhang informiert, aber nicht erneut versucht. Wenn es aus irgendeinem Grund nicht verarbeitet wird und Sie dennoch möchten, dass es erneut versucht wird, empfehlen wir, in config.death_handlers wie oben beschrieben Slack-Benachrichtigungen festzulegen.
Recommended Posts