Was dieses Tutorial abdeckt
- Die Engine einbinden und einschränken, wer darauf zugreifen kann.
- Queues, Worker und Job-Argumente lesen.
- Einen fehlgeschlagenen Job anhand seines erfassten Fehlers und Backtrace diagnostizieren.
Voraussetzungen
Engine installieren und einbinden
config/routes.rb ein:
Route einschränken
Die Jobs-Oberfläche zeigt Job-Argumente an. Diese enthalten routinemäßig Datensatz-IDs, E-Mail-Adressen und alles andere, was Sie einem Job übergeben haben. Binden Sie sie nicht ohne Authentifizierung ein. Umschließen Sie die Einbindung mit Devise mit einer Constraint auf Routenebene:404 statt einer Anmeldeaufforderung. Die Route verrät ihre Existenz nicht. Falls Ihre Authentifizierungsbibliothek keinen solchen Routing-Helfer bietet, akzeptiert Mission Control auch eine Konfiguration auf Controller-Ebene.
Job lesen
Die Queue-Liste zeigt jede Queue und die darin enthaltenen Jobs. Die Worker-Liste zeigt die verbundenen Dispatcher und Worker mit ihrem letzten Heartbeat. Öffnen Sie einen Job, sehen Sie seine Klasse, Queue, Argumente sowie die Zeitpunkte, zu denen er eingereiht und abgeschlossen wurde. Es lohnt sich, die Argumente zu verstehen, denn sie werden als JSON gespeichert, nicht als Ruby-Objekte. Eine an einen Job übergebene Active-Record-Instanz erscheint als Global-ID-Referenz. Ein Hash mit Symbol-Schlüsseln trägt einen Marker. Der Marker hält fest, dass seine Schlüssel beim Deserialisieren des Jobs wieder zu Symbolen werden sollen. Was Sie sehen, ist die serialisierte Form, nicht die Objekte, die Ihr Job tatsächlich erhält.Fehlgeschlagenen Job diagnostizieren
Ein fehlgeschlagener Job behält seine Fehlerklasse, Meldung und sein Backtrace. Das reicht normalerweise aus, um die Zeile zu identifizieren, die den Fehler ausgelöst hat, sie zu beheben und den Job direkt von derselben Ansicht aus erneut zu versuchen.Wo AppSignal ansetzt
Mission Control beantwortet die Frage „Was befindet sich gerade in meinen Queues?”. Es ist eine Live-Ansicht des eigenen Speichers des Backends und standardmäßig auf eine Anwendung beschränkt. AppSignal beantwortet die Fragen, die Verlauf und Aggregation über Deploys hinweg erfordern:- Ist dieser Fehlschlag neu, und wie oft tritt er auf? Die Fehlerverfolgung gruppiert Job-Fehlschläge zu Issues, nicht zu einer Liste einzelner fehlgeschlagener Zeilen. Jedes Issue hat eine Anzahl und einen Zeitpunkt des ersten Auftretens.
- Welche Jobs sind langsamer geworden, und wann? Jobs werden im
background-Namespace mit eigenen Performance-Traces gemeldet. Kombinieren Sie das mit Deploy-Markern, um eine Regression mit dem Deploy abzugleichen, der sie verursacht hat. - Ist der Job überhaupt gelaufen? Ein Job, der nie eingereiht wird, hinterlässt in keinem der beiden Tools eine Spur. Check-ins berichten über die Einhaltung von Zeitplänen und informieren Sie über den Lauf, der nicht stattgefunden hat.
Transkript
Aus dem Video transkribiert und leicht bearbeitet. Die automatischen Untertitel haben mehrere Produkt- und API-Namen falsch verstanden, diese wurden korrigiert.Transkript lesen
Transkript lesen
0:02 Hallo zusammen, ich freue mich riesig auf diese Folge. Mission Control ist endlich öffentlich verfügbar. Es hat noch ein paar Bugs, aber die werden sicher sehr schnell behoben. Mission Control Jobs ist die erste Version von Mission Control, die DHH auf der Rails World 2023 angekündigt hat. Interessant ist, dass es Mission Control Bindestrich Jobs heißt, was bedeutet, dass wir in Zukunft wahrscheinlich weitere Mission-Control-Funktionen sehen werden. Zum Einrichten fügen Sie Mission Control Jobs zu Ihrer Gemfile hinzu und dann diese Zeile zu Ihrer Routes-Datei, um loszulegen.0:41 Das machen wir jetzt, wir sagen bundle add, Mission Unterstrich control Bindestrich jobs, und Sie führen das aus. Dann starte ich den Rails-Server. Ich habe hier eine Rails-Anwendung, die wir in der Solid-Queue-Folge erstellt haben und auf der Solid Queue installiert ist, eingerichtet als Puma-Plugin, das es automatisch ausführt. Wenn wir Puma.rb öffnen, sehen wir hier das Solid-Queue-Plugin: Es startet Solid Queue, wann immer Puma hoch- und heruntergefahren wird, und fährt Solid Queue dabei automatisch mit herunter. Das ist alles, was Sie tun müssen, um Mission Control Jobs einzurichten. Wenn wir jetzt unsere Rails-Anwendung ausführen, gehen wir zu unserer Routes-Datei und fügen die Zeile hinzu, um die Mission-Control-Engine einzubinden. Falls Sie Devise verwenden, können Sie das auch mit authenticated user do umschließen, um zu prüfen, ob der Nutzer angemeldet ist, und den Zugriff auf diese Route dann zuzulassen.1:45 Andernfalls, wenn ein Nutzer nicht angemeldet ist, gibt es einfach einen 404. Das ist also eine praktische Möglichkeit, der Mission-Control-Route eine Authentifizierung hinzuzufügen. Sie können die Authentifizierung aber auch mit etwas Konfiguration zum Controller hinzufügen, falls Sie etwas anderes verwenden, das diese Routing-Helfer nicht hat. Ich finde das aber wirklich praktisch, weil ich dafür keine zusätzliche Konfiguration vornehmen muss, sondern es einfach hier in meiner Routes-Datei erledigt wird. Nachdem das hinzugefügt ist – wir haben hier kein Devise, also lassen wir das auskommentiert – können wir jetzt auf die Jobs-Route zugreifen.2:22 Sie sehen, dass ich hier schon ein bisschen herumprobiert habe. Wir haben die Default-Queue, die natürlich standardmäßig erstellt wird, wenn Sie keine bestimmten Queues angegeben haben. Wir haben ein paar Jobs – ich habe vor einem Monat mit Solid Queue herumgespielt –, aber wir haben auch die Jobs, mit denen ich vor Kurzem experimentiert habe. Hier sehen wir die verbundenen Worker. Ich habe meinen einen Worker, der von Puma eingerichtet wird und hier läuft, er ist verbunden.2:52 Der letzte Heartbeat war vor einer Minute. Wir können neu laden und schauen, ob sich das aktualisiert. Das also ist Mission Control Jobs. Wenn wir jetzt einen Job in unserer Rails-Konsole ausführen würden, öffnen wir die Rails-Konsole – ich habe hier ein paar Beispiele –, und wenn wir zum Beispiel einen Mailer mit einem Post darin versenden wollen, können wir das tun.3:21 Das reiht den Job ein, den Mail-Delivery-Job. Wir bekommen dort all diese Informationen, und dann können wir unsere Oberfläche aktualisieren. Wir haben einen laufenden Job, diesen Action-Mailer-Mail-Delivery-Job. Läuft seit weniger als 20 Sekunden auf Worker 26. Wenn wir das aktualisieren, sollte er fertig sein, und er war erfolgreich – wir finden ihn hier unter den abgeschlossenen Jobs, was großartig ist.3:43 Wir können auf die Jobs klicken und die Argumente sehen, die Job-ID, in welcher Queue er war, wann er eingereiht und wann er abgeschlossen wurde, und wir sehen alle Rohdaten dazu. Das ist praktisch, um die Argumente zu sehen, damit wir erkennen können, welche Job-Klasse es war, wie die ID lautete und welche Argumente wir hatten. Wir haben hier den User-Mailer, die receipt-Methode, deliver_now und die Parameter. Die Post-Instanz wurde dabei in eine Global ID umgewandelt. Es weiß außerdem, dass wir für unsere Hash-Schlüssel Symbole wollen, und weil wir das in JSON umwandeln müssen, um es in der Datenbank zu speichern, gibt es dafür eine spezielle Darstellung: Sie besagt, dass es innerhalb von params einen post-Schlüssel gibt, den wir aber wieder in ein Symbol umwandeln wollen, sobald wir es zurück in einen Ruby-Hash verwandeln.4:34 Das sind also alles sehr nützliche Informationen, und ich wollte darauf hinweisen: Wenn wir einen Fehler in unserem User-Mailer machen würden, etwa eine Variable referenzieren, die nicht existiert, und dann in unser Terminal zurückgehen und es erneut versuchen, müssen wir eventuell neu laden. Der Job wird dann wahrscheinlich mit der fehlerhaften Logik eingereiht. Und da haben wir es, ein neuer fehlgeschlagener Job. Vor weniger als einer Minute ist dieser Mail-Delivery-Job fehlgeschlagen. Und das Schöne ist, dass die Fehlerinformationen festgehalten werden: der Typ, die Meldung und das Backtrace.5:14 Wir sehen hier: user_mailer, Zeile 11, in der receipt-Methode wurde eine undefinierte lokale Variable oder Methode ASDF aufgerufen, was stimmt, und wir können das dann beheben und den Job erneut versuchen. Leider hat die aktuelle Version von Mission Control hier einen Bug, sodass Retry momentan nicht funktioniert. Das wird aber sehr bald behoben. Ich habe das schon gemeldet, und wir werden dafür wahrscheinlich auch einen Pull Request erstellen, aber das wird sehr bald behoben sein. Es gibt hier nicht mehr allzu viel zu sehen, aber wenn Sie in Ihrer Rails-Konsole jobs help eingeben, sehen Sie diese Ausgabe, die besagt, dass Sie sich mit connect to, App-ID und Server-ID, mit einem Job-Server verbinden können.6:00 Und weiter unten werden Beispiele ausgegeben. Was fehlt – dafür habe ich schon einen Pull Request erstellt – sind die doppelten Anführungszeichen darum. Das hat mich etwas verwirrt. Und die App-ID und der Doppelpunkt davor oder die Server-ID müssen wohl nicht sein. Das hier ist wahrscheinlich die App-ID, aber Sie können connect to mit doppelten Anführungszeichen und einem String schreiben und einen der verfügbaren Job-Server verwenden, die hier aufgelistet werden – das listet, soweit ich sehen kann, alle Job-Server auf, die mit Ihrer Datenbank verbunden sind.6:32 Danach sind Sie damit verbunden, und Sie können ActiveJob.jobs aufrufen und die aus der Datenbank geladenen Jobs sehen. Wir haben gerade keine laufenden Jobs oder Ähnliches, also liefert das im Grunde nichts, aber Sie können darauf zugreifen, und es gibt eine ganze Menge, was Sie aufrufen können, um diese Jobs zu betrachten. Das ist quasi die Schnittstelle, über die die Oberfläche das abruft, denn das unterstützt tatsächlich Resque, das Dinge in Redis speichert, während Solid Queue sie in Ihrer Datenbank speichert. Es hat also ein flexibles Backend, um mit diesen unterschiedlichen Diensten zu sprechen. Man kann sich also vorstellen, dass wir irgendwann wahrscheinlich auch eine Integration für Sidekiq, GoodJob, Que und all die anderen bekommen.7:23 Die müssen sich einfach nur mit dieser Schnittstelle verbinden, und das war es dann im Wesentlichen. Das ist schon cool: Sie können auf die fehlgeschlagenen Jobs zugreifen, das hier eingeben und sie sich ansehen, und dann im Grunde die ausstehenden Jobs für eine bestimmte Queue abfragen und so weiter. Das ist ziemlich großartig. Es gibt viele Dinge, die Sie damit machen könnten, aber im Allgemeinen werden Sie sich damit wahrscheinlich nicht groß befassen. Die Oberfläche ist hier wirklich das Herzstück von Mission Control Jobs.7:57 Ja, mich würde interessieren, was passiert, wenn wir die Rails-Konsole öffnen und einfach ActiveJob.jobs aufrufen. Ich vermute, diese Methode wird definiert, sobald man sich mit einem der Job-Server verbindet. Das ist wahrscheinlich der Grund, oder wenn wir jobs help eingeben. Ja, also eine definierte Methode, die muss dynamisch definiert werden, wenn wir uns verbinden. Das ist schon ziemlich cool.8:28 Ich weiß nicht, ob es eine disconnect-Methode gibt. Ich würde annehmen, dass es sie gibt, aber vielleicht ist sie einfach nicht dokumentiert oder so, aber das ist trotzdem ziemlich cool. Ein kleiner praktischer Helfer, um auf Ihre Job-Server zuzugreifen und ein bisschen tiefer einzusteigen. Das war also Mission Control Jobs. Ich vermute, das ist ein Hinweis darauf, dass es in Zukunft noch viel mehr coole Dinge für Mission Control geben wird, aber das ist es, was angekündigt wurde, und es funktioniert großartig.8:53 Ich liebe es, mit Solid Queue meine Jobs im Backend zu speichern, aber dank des Puma-Plugins muss ich mich nicht einmal um die Verwaltung eines weiteren Prozesses kümmern. Das wird in Zukunft eine großartige Möglichkeit sein, Jobs in Ihren Anwendungen ohne separaten Dienst auszuführen, da es einfach die Datenbank nutzt, die Sie bereits verwenden. Das war’s für diese Folge. Es steckt wirklich nicht viel mehr dahinter. Das war’s.9:21 Sie haben Zugriff, um mit den ActiveJob-Jobs zu sprechen, wenn Sie möchten, aber das war es im Wesentlichen. Es ist eine großartige kleine Benutzeroberfläche. Sie können sie schon heute zu Ihren Rails-Anwendungen hinzufügen. Das war’s also. Wenn Sie Fragen haben, lassen Sie es uns in den Kommentaren unten wissen, und wir sehen uns in der nächsten Folge.9:37 Bis dann.