Überprüfung und typische Probleme - Drupal
Das Testereignis
Klicke im Formular /admin/config/development/dock-ray auf Testereignis senden. Ergebnis und Zeitstempel bleiben im Statusbereich, und das Ereignis selbst sollte im Panel unter Fehler des Projekts erscheinen, auf das der Token zeigt.
Prüfung über das Log
Da das Modul als Logger-Kanal arbeitet, ist der eigentliche Test ein gewöhnlicher Log-Eintrag mindestens der eingestellten Schwere:
drush php:eval "\Drupal::logger('dock_ray_test')->error('DockRay-Kontrolleintrag');"Der Eintrag sollte als Meldung bei DockRay ankommen. Kommt er nicht an, während das Testereignis aus dem Formular funktioniert, liegt es an der Log-Stufe, nicht an der Verbindung.
Typische Probleme
Das Testereignis funktioniert, echte Fehler kommen aber nicht an
Prüfe minimum_level. Bei 3 (Error) werden Warnungen und Notices absichtlich übersprungen. Prüfe außerdem, ob der Fehler überhaupt im Drupal-Log landet - das Modul meldet, was der Logger sieht, nicht was daneben passiert.
Ich habe einen Token im Formular eingetragen, das Modul nutzt einen anderen
In der settings.php steht $settings['dock_ray'], während die Konfigurationsquelle auf Auto steht - dann gewinnt der Schlüssel aus der Datei für sein Feld. Der Statusbereich zeigt den tatsächlich wirksamen Wert und nennt seine Herkunft.
Die Felder für Token und Schlüssel sind gesperrt
Das heißt, der Wert kommt aus der settings.php. Das Speichern des Formulars in diesem Zustand löscht nichts - die Form API übermittelt den Standardwert eines gesperrten Feldes mit. Um sie in der Oberfläche einzutragen, stelle die Quelle auf Nur dieses Formular.
Transaktionen fehlen
Transaktionen entstehen nur bei einer traces_sample_rate über null und schließen auf kernel.terminate. Eine Anfrage, die vorher endet - durch exit abgebrochen oder vom Page-Cache beantwortet - hinterlässt keine Transaktion.
JavaScript-Fehler kommen nicht an
Der Kollektor ist standardmäßig aus und bleibt bewusst von Admin-Seiten fern. Kommt nach dem Aktivieren trotzdem nichts, prüfe, ob /dock-ray/collector.js die Datei tatsächlich ausliefert - bei aggressivem Caching oder einem unüblichen Docroot ist das meist die erste Ursache. Denke auch an das Limit von 20 Meldungen pro IP-Adresse und Stunde und daran, dass der Empfänger auch bei Ablehnung 202 antwortet.
Konfigurations-Cache nach Änderung der settings.php
Leere nach dem Bearbeiten der settings.php den Cache (drush cr). Das Formular liest die Overrides beim Aufbau, bis zum Neubau des Containers kann der Statusbereich also den vorherigen Zustand zeigen.
Das Panel antwortet 200, aber es gibt kein Ereignis
Eine Antwort 200 {"success": false} bedeutet, dass das Konto sein monatliches Fehlerkontingent aufgebraucht hat. Die Integration behandelt das nicht als Störung - zu Recht. Das Kontingent siehst du im Konto-Dashboard; bis zum Monatsende wird es aus der erfassten Nutzung berechnet, Fehler zu löschen setzt es also nicht zurück.
Es funktioniert weiterhin nicht
Arbeite die Checkliste zur Fehlerbehebung durch, und wenn das nicht hilft, schreib uns. Nenne den Projektnamen, die Version der Integration und ungefähr die Uhrzeit des Tests: das verkürzt den Weg zur Antwort.