Zum Hauptinhalt springen
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 Magic 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:

Event-Timeline

perform_job.sidekiq-Events werden in der Event-Timeline auf der Detailseite eines Performance-Incidents angezeigt: Example event timeline

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. Example sidekiq error

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. Example performance incident grouping

Sample-Performance

Sample-Breakdowns ermöglichen es Ihnen, die Performance von Sidekiq schnell zu überprüfen und Performance-Probleme zu erkennen, ohne tief in die Details eintauchen zu müssen. Example Sidekiq performance sample

Magic Dashboard

Wenn AppSignal Sidekiq-Metriken empfängt, wird ein Sidekiq Magic Dashboard erstellt, das im Dashboard-Bereich der AppSignal-App verfügbar ist. Das Sidekiq Magic Dashboard enthält die folgenden Graphen:
GraphMetrikenTags
Connection Countsidekiq_connection_counthostname
Dauer pro Workertransaction_duration
  • action
  • namespace
  • Job-Status pro Queuesidekiq_queue_job_count
  • status
  • queue
  • Gesamter Job-Statussidekiq_job_count
  • status
  • hostname
  • Queue-Latenzsidekiq_queue_latency
  • hostname
  • queue
  • Queue-Längesidekiq_queue_length
  • hostname
  • queue
  • Redis-Speichernutzung
  • sidekiq_memory_usage
  • sidekiq_memory_usage_rss
  • hostname
    Throughput pro Workertransaction_duration
  • action
  • namespace
  • Worker-/Prozessanzahl
  • sidekiq_worker_count
  • sidekiq_process_count
  • hostname
    Tags geben Ihnen eine kontextbezogene Aufschlüsselung der Sidekiq-Performance-Informationen. AppSignal meldet die folgenden Tags für Sidekiq-Jobs:
    NameBeschreibung
    actionDer Name der Action, von der die Metrik gemeldet wurde (z. B. YourWorker#perform).
    hostnameDer Name des Hosts, von dem die Metrik gemeldet wurde.
    namespaceDer Name des Namespaces, von dem die Metrik gemeldet wurde.
    queueBenannte Queue, in der Jobs verarbeitet werden, z. B. default oder mailer.
    statusStatus jedes Jobs, entweder processed oder failed.
    Jobs mit dem Status failed werden auch als processed gezählt.
    Jedes Tag wird durch eine farbige Linie im Graphen dargestellt: Example Sidekiq dashboard

    Connection-Count-Graph

    Der Connection-Count-Graph zeigt die Anzahl der Sidekiq-Verbindungen pro Host. Sie können den Connection-Count-Graphen verwenden, um Sidekiq-Verbindungen pro Host zu überwachen, 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 gesamte Job-Status-Graph zeigt die Anzahl der erwarteten Sidekiq-Jobs pro Status und Namespace. Sie können den Gesamter-Job-Status-Graphen verwenden, um fehlgeschlagene Jobs zu überwachen und die Verteilung der Jobs über Namespaces hinweg zu verfolgen.

    Queue-Latenz-Graph

    Der Queue-Latenz-Graph zeigt die Latenz, die die Queue zum Zeitpunkt der Messung erfahren hat. Sidekiq berechnet dies, indem die Zeit, zu der der letzte Job eingereiht wurde, von der Messzeit subtrahiert wird. 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 Namespace. 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:
    • Die Virtual-Memory-Size-Speichernutzung von Redis (sidekiq_memory_usage_rss)
    • Die Resident-Set-Size-Speichernutzung von Redis (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 Hostname. Sie können diesen Graphen verwenden, um die Worker-Performance, gruppiert nach der Klasse, die den Job definiert, zu überwachen.

    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.