Sidekiq

Sidekiq ist ein einfacher und effizienter Background-Prozessor für Ruby. Es ist auch der Prozessor, den wir zur Verarbeitung von Jobs in AppSignal verwenden. Wenn AppSignal Sidekiq-Metriken erkennt, wird ein Intelligence dashboard erstellt, mit dem Sie zentrale Metriken visuell überwachen können.

Sidekiq-Monitoring für Ruby-on-Rails-Apps

Das AppSignal-Ruby-Gem fügt automatisch einen Listener in den Sidekiq-Server-Middleware-Stack ein, wenn das Modul Sidekiq vorhanden ist und Sie Rails verwenden. Weitere Maßnahmen sind nicht erforderlich. Die Sidekiq-Integration ist mit Active Job kompatibel.

Sidekiq-Monitoring für Ruby-Apps

Das Hinzufügen dieser Konfiguration sollte nur erforderlich sein, wenn Sidekiq AppSignal nicht automatisch über das Framework der App, z. B. Rails, lädt. Fügen Sie diesen Code-Schnipsel mit der richtigen Umgebung und dem richtigen Namen zu Ihrer Sidekiq-Konfiguration hinzu:

require 'appsignal'

Sidekiq.configure_server do |config|
  config.on(:startup) do
    # Start AppSignal
    Appsignal.start
  end

  config.on(:shutdown) do
    # Stop the agent
    Appsignal.stop('Sidekiq shutdown')
  end
end

Performance-Monitoring

Sobald AppSignal beginnt, Sidekiq-Metriken zu melden, erhalten Sie Performance-Einblicke über:

Trace-Timeline
Fehlererfassung
Incident-Gruppierung
Trace-Aufschlüsselung

Trace-Timeline

perform_job.sidekiq-Spans erscheinen in der Trace-Timeline auf der Trace-Seite:

Fehlererfassung

Erfassen Sie Ausnahmen, die beim Ausführen von Sidekiq-Jobs auftreten. Wenn Sidekiq vor oder nach der Verarbeitung eines Jobs auf ein Problem stößt, etwa beim Parsen von JSON aus Redis, wird ein Fehler ausgelöst. Dieser Fehler wird unter der Action SidekiqInternal im Namespace Background gemeldet, da der Job-Kontext beim Auftreten des Fehlers unbekannt ist.

Fehler beim Verwerfen eines Jobs melden

Setzen Sie die Konfigurationsoption sidekiq_report_errors auf discard, um Fehler nur dann zu melden, wenn ein Job verworfen wird. Wenn ein Job verworfen wird, sind alle Job-Wiederholungen aufgebraucht, und der Job wird nicht erneut versucht. Lesen Sie die Sidekiq-Dokumentation, um mehr über die Ausnahmebehandlung von Sidekiq und fehlgeschlagene Job-Wiederholungen zu erfahren.

Wenn Sie Sidekiq mit dem Retry-System von Active Job verwenden, konfigurieren Sie es, Fehler nur beim Verwerfen zu melden, damit Fehler nicht mehrfach gemeldet werden.Nachdem die Active-Job-Wiederholungen aufgebraucht sind, übernimmt das Sidekiq-Retry-System. Deaktivieren Sie das Sidekiq-Retry-System, falls dieses Verhalten unerwünscht ist.

Incident-Gruppierung

Job-Namen werden automatisch basierend auf dem Klassennamen des Sidekiq-Workers erkannt und mit dem Methodennamen perform ergänzt, was zu etwas wie MyWorker#perform führt.

Nach Worker-Klassenname gruppierte Sidekiq-Jobs auf der Performance-Seite

Trace-Aufschlüsselung

Die Trace-Aufschlüsselung auf einer Trace-Seite zeigt, wie sich die Zeit eines Jobs auf Event-Gruppen wie sidekiq und active_record verteilt hat, sodass Sie Performance-Probleme erkennen können, ohne die gesamte Timeline durchzusehen.

Enqueue-Instrumentation

Das Einreihen eines Sidekiq-Jobs zeichnet ein enqueue.sidekiq-event auf, benannt nach dem eingereihten Job. AppSignal zeichnet enqueue-events in der event-timeline der aktiven transaction auf, zum Beispiel wenn Sie einen Job aus einem Web-Request oder aus einem anderen Job heraus einreihen. Sie werden nur aufgezeichnet, wenn eine transaction aktiv ist, sodass das Einreihen eines Jobs außerhalb einer transaction nichts aufzeichnet. Um das Aufzeichnen von enqueue-events für alle background-job-integrations zu stoppen, setzen Sie die Konfigurationsoption enable_job_enqueue_instrumentation auf false. Dies beeinflusst die instrumentation der Jobs selbst nicht.

Intelligence dashboard

Wenn AppSignal Sidekiq-Metriken empfängt, wird ein Sidekiq Intelligence dashboard erstellt, das im Dashboard-Bereich der AppSignal-App verfügbar ist. Das Sidekiq Intelligence dashboard enthält die folgenden Graphen:

Graph	Metriken	Tags
Connection Count	`sidekiq_connection_count`	`hostname`
Dauer pro Worker	`trace_duration`	`action` `namespace`
Job-Status pro Queue	`sidekiq_queue_job_count`	`status` `queue`
Gesamter Job-Status	`sidekiq_job_count`	`status` `hostname`
Queue-Latenz	`sidekiq_queue_latency`	`hostname` `queue`
Queue-Länge	`sidekiq_queue_length`	`hostname` `queue`
Redis-Speichernutzung	`sidekiq_memory_usage` `sidekiq_memory_usage_rss`	`hostname`
Throughput pro Worker	`trace_duration`	`action` `namespace`
Worker-/Prozessanzahl	`sidekiq_worker_count` `sidekiq_process_count`	`hostname`

Die Graphen Dauer pro Worker und Throughput pro Worker verwenden trace_duration bei Accounts, die auf Trace-Metriken umgestellt wurden. Bei Accounts, die noch nicht umgestellt sind, basieren diese Graphen stattdessen auf transaction_duration.

Tags geben Ihnen eine kontextbezogene Aufschlüsselung der Sidekiq-Performance-Informationen. AppSignal meldet die folgenden Tags für Sidekiq-Jobs:

Name	Beschreibung
`action`	Der Name der Action, von der die Metrik gemeldet wurde (z. B. `YourWorker#perform`).
`hostname`	Der Hostname des Redis-Servers, den Sidekiq verwendet, oder der in der Probe-Konfiguration festgelegte Wert von `hostname`.
`namespace`	Der Name des Namespaces, von dem die Metrik gemeldet wurde.
`queue`	Benannte Queue, in der Jobs verarbeitet werden, z. B. `default` oder `mailer`.
`status`	Status jedes Jobs. Für Job-Status pro Queue: `processed` oder `failed`. Für Gesamter Job-Status: `processed`, `failed`, `retry_queue`, `died`, `scheduled` oder `enqueued`. Jobs mit dem Status `failed` werden auch als `processed` gezählt.

Jedes Tag wird durch eine farbige Linie im Graphen dargestellt:

Connection-Count-Graph

Der Connection-Count-Graph zeigt die Anzahl der Clients, die mit dem von Sidekiq verwendeten Redis-Server verbunden sind, pro Redis-Host. Sie können den Connection-Count-Graphen verwenden, um Verbindungstrends und Engpässe zu erkennen und Ressourcen zu optimieren.

Dauer-pro-Worker-Graph

Der Dauer-pro-Worker-Graph zeigt die Zeit, die zum Ausführen von Jobs benötigt wurde, gruppiert nach Namespace und Action. Sie können den Dauer-pro-Worker-Graphen verwenden, um die Performance der Worker pro Action und Namespace zu überwachen. So erhalten Sie einen Überblick über die Sidekiq-Performance und können Spitzen in der Dauer schnell identifizieren und untersuchen.

Job-Status-pro-Queue-Graph

Der Job-Status-pro-Queue-mit-Priorität-Graph zeigt die Anzahl der ausgeführten Jobs, gruppiert nach ihrem resultierenden Status und nach der Queue, in der sie eingereiht wurden. Sie können den Job-Status-pro-Queue-Graphen verwenden, um Fehlerzählungen und die Performance pro Queue zu überwachen, Engpässe zu identifizieren und Ihre Background-Jobs für die Skalierbarkeit zu optimieren.

Gesamter-Job-Status-Graph

Der Gesamter-Job-Status-Graph zeigt die Anzahl der Sidekiq-Jobs pro Status und Redis-Host. Sie können den Gesamter-Job-Status-Graphen verwenden, um fehlgeschlagene, tote, wiederholte, geplante und eingereihte Jobs zu überwachen.

Queue-Latenz-Graph

Der Queue-Latenz-Graph zeigt die Latenz, die die Queue zum Zeitpunkt der Messung erfahren hat. Sidekiq berechnet dies als die Zeit seit der Einreihung des ältesten Jobs in der Queue. Dieser Wert wird in Millisekunden gemeldet. Sie können den Queue-Latenz-Graphen verwenden, um Verzögerungen bei der Verarbeitung von Jobs zu erkennen, Queue-Engpässe zu identifizieren und zu verstehen, wie schnell Background-Jobs starten.

Queue-Länge-Graph

Der Queue-Länge-Graph zeigt die Länge der Sidekiq-Queues pro Queue und Redis-Host. Sie können den Queue-Länge-Graphen verwenden, um die Queue-Performance zu überwachen sowie Sidekiq-Engpässe zu erkennen und zu beheben.

Redis-Speichernutzungs-Graph

Der Redis-Speichernutzungs-Graph zeigt:

Den gesamten von Redis reservierten Speicher (sidekiq_memory_usage)
Die Resident Set Size, den physischen Speicher, den Redis aus Sicht des Betriebssystems belegt (sidekiq_memory_usage_rss)

Sie können den Redis-Speichernutzungs-Graphen verwenden, um die Speichernutzung von Sidekiq zu überwachen, das Ressourcenmanagement zu verbessern und speicherintensive Jobs zu optimieren.

Throughput-pro-Worker-Graph

Der Throughput-pro-Worker-Graph zeigt die Anzahl der ausgeführten Jobs, gruppiert nach Namespace und Action. Sie können diesen Graphen verwenden, um zu sehen, wie viele Jobs jede Worker-Klasse verarbeitet, und um Worker zu erkennen, deren Volumen sich unerwartet ändert.

Worker-/Prozessanzahl-Graph

Der Worker-/Prozessanzahl-Graph zeigt die Anzahl der Sidekiq-Worker und der ausgeführten Prozesse. Sie können den Worker-/Prozessanzahl-Graphen verwenden, um die Workload-Verteilung zu verwalten, die Ressourcenzuweisung zu optimieren und Performance-Probleme zu identifizieren.

Hostname-Konfiguration

AppSignal versucht, den Hostnamen der Redis-Instanz zu erkennen, die Ihre Sidekiq-Instanz zum Speichern ihrer Queues verwendet. Wenn die Erkennung nicht genau ist, können Sie die Hostname-Konfiguration anpassen, indem Sie die Standard-Sidekiq-Probe überschreiben. Zuerst müssen Sie die Standard-Sidekiq-Probe überschreiben, indem Sie eine neue Probe mit demselben Namen (:sidekiq) registrieren. Diese Probe benötigt einen Konfigurations-Hash, einschließlich des Schlüssels :hostname mit dem neuen Hostname-Wert. Durch Angabe der Konfigurationsoption :hostname in der Sidekiq-Minutely-Probe werden die Metriken mit dem angegebenen Hostname-Wert getaggt. Der Wert der Konfigurationsoption :hostname wird nicht verwendet, um eine Redis- oder Sidekiq-Verbindung herzustellen. Zum Beispiel:

# config/initializers/appsignal.rb or a file that's loaded on boot

# Ruby gem 2.11.0 and newer
Appsignal::Minutely.probes.register(
  :sidekiq, # Use the same key as the default Sidekiq probe to override it
  Appsignal::Probes::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

# Ruby gem 2.10.x and older
Appsignal::Minutely.probes.register(
  :sidekiq, # Use the same key as the default Sidekiq probe to override it
  Appsignal::Hooks::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

In Version 2.11.0 des Ruby-Gems wurde die Konstante SidekiqProbe in ein eigenes Modul verschoben. Beim Aufruf der Konstante wird eine Warnung ausgegeben und protokolliert. Aktualisieren Sie auf den neuen Konstantennamen Appsignal::Probes::SidekiqProbe, um die Warnung zu entfernen.

Span-Attribute

Nur im Collector-Modus: Dies gilt, wenn AppSignal für Ruby im Collector-Modus läuft. Andernfalls hat es keine Auswirkung.

Der Enqueue- und der eigene Span des Jobs tragen jeweils:

messaging.system — die Queueing-Bibliothek.
messaging.destination.name — die Queue, in die der Job eingereiht wurde.
messaging.operation.type — ob der Span das Enqueue oder die Ausführung des Jobs ist.

Ein Span für einen Job, der einen Fehler ausgelöst hat, trägt außerdem error.type, die Klasse des Fehlers.

Verteiltes Tracing

Nur im Collector-Modus: Dies gilt, wenn AppSignal für Ruby im Collector-Modus läuft. Andernfalls hat es keine Auswirkung.

Ein Job läuft im selben Trace wie der Code, der ihn eingereiht hat. Er erscheint unter der Anfrage oder dem Job, der ihn geplant hat, sodass Sie einen langsamen Job bis zu seiner Ursache zurückverfolgen können. Der Trace wird direkt auf dem Job mitgeführt, zusammen mit seinen übrigen Daten. Lesen Sie mehr über Verteiltes Tracing.

Siehe auch

Sidekiq-Batches: Jobs parallel ausführen und dann handeln: Teilt eine Arbeitseinheit in viele Jobs auf und führt einen Callback aus, sobald jeder Job erfolgreich war. Erklärt, warum der Callback eine eigene Klasse benötigt und wie sich ein Batch an den nächsten anschließen lässt.

SDKs & Telemetrie

Sprach-SDKs

Telemetrie-Tools

Sidekiq-Monitoring für Ruby-on-Rails-Apps

Sidekiq-Monitoring für Ruby-Apps