Routinen und Frequenzen

Auch wenn viel des Monitorings automatisiert ist und von externen Services stark erleichtert wird, kann es dennoch nicht schaden, gewisse Themen manuell zu überprüfen.
Diese händischen Checks (Routinen) sollten in bestimmten Abständen (Frequenzen) überprüft werden. Dabei sind diese Checks von der Priorität eher niedrig und nach Gefühl durchgeführt werden (z.B. wenn es eine (größere) Veränderung bei einer API-Integration gab, sollte man das Log rund um den dem api channel öfters prüfen).
Dabei sollten dedizierte table-Metrics auf dem Main-Dashboard in Nova (opens new window) helfen um einen schnellen Überblick zu bekommen.
Wichtige ERRORs werden/sollten sowieso durch Flare auffallen.

Logs zum checken

1. Place-Log (channel place)
   • nur bei Bedarf (wenn es viele Fehler mit dem Betreff No Place was found with this Postalcode [inputPostalCode, countryCode, geoResponseObject] gab)
2. API-Log (channel api)
   • immer mal wieder checken, gerade wenn neue Integrationen an den Start gehen oder größere Änderungen deployed werden
   • hier auch überprüfen ob die verarbeitete Suchenanzahl der Integration stimmt/in die richtige Richtung geht
3. Notification-Log (channel notification)
   • nur die ERRORs hin und wieder überprüfen (onBounce, onPermanentBounce, ...)
4. Google Jobs (Indexing)
   • jede Woche ca. um eine Tendenz zu erkennen (sollte nie auf 0 inserierte Stelen fallen), jedoch arbeitet Google hier nach seinem eigenen Willen und Auf- bzw. Abstiege sind oft nicht nachvollziehbar. Die Spanne von inserierten Stellen ist ca. 50-300 (wobei 300 schon ein top Wert ist)
5. Flare (Error Tracking)
   • (neue) Bugs, die auch über Slack rein kommen haben Prio da diese auf eine Fehlfunktion der Seite/des Codes und der Funktionalität haben könnten.
     • nach erster Sichtung kann dann entschieden werden ob das Problem wirklich Prio hat oder auch eine spätere Lösung reicht
     • via. Flare kann auch die URL (sofern vorhanden) & der Nutzer (sofern vorhanden) ausgelesen werden und mit diesen Infos (+ Impersonate -Funktion) der Fehler reproduziert werden (bzw. dies zu versuchen)
6. OhDear (Monitoring)
   • Broken Links, Lighthouse Score & Mixed Content können immer mal wieder gecheckt werden (monatlich?)
   • wenn es neue broken Links gibt, kommen diese eigentlich auch in den #health-channel via Slack (bzw. wöchtentlich via Mail?)
   • außer dem Wiki (und die gefilterten Links beim Bog (upload Problem)) sollte es eigentlich keine broken Links geben
7. Dusk-Tests (CI)
   • Die Dusk-Tests in der CI sind wackelig (es failed immer mal wieder 0-4 Tests und es sind meist die gleichen bei bestimmten Bedingungen (Displaygrößen, Datenkonsistenz, ...).
   • Die Fehler konnten lokal nicht eindeutig reproduziert werden und somit auch nicht die Ursache gefunden werden.
   • Der Dusk-CI Job ist auch mit allow_failure: true (und php artisan dusk --order-by=random --colors || true) konfiguriert, sodass dieser in GitLab immer als grün (passing) angezeigt wird
   • es sollte aber immer mal wieder (und gerade vor einem Release/Deploy) überprüft werde ob nicht mehr/neue Tests in Dusk failen (welche dann auch lokal reproduziert und gefixt werden sollten)
   • über die Screenshots von den fehlgeschlagenen DuskTests kann man sich einen ersten Überblick verschaffen
   • falls nötig (Reproduktion des Problem mit der verwendeten Datenbasis) kann die verwendete DB als .sql über die Artefacts in GitLab geladen (und dann lokal eingespielt) werden
   • ⚠️ => es ist die Datenbasis nachdem die Tests gelaufen sind (welche Daten auch verändern) und somit ggf. nicht die selbe Datenbasis wie die, welche bestand als das Problem aufgetreten ist!

übergeordnetes Thema

6. Errortracking und Debugging