Geltungsbereich
Splunk Enterprise
Beschreibung
Ein Benutzer wollte das Berichtsergebnis in ein Dashboard hochladen und wollte die LoadJob-Funktion mit einem bereits konfigurierten geplanten Bericht für diesen verwenden.
Untersuchung
Der Befehl
loadjob kann aus verschiedenen Gründen fehlschlagen. Hier einige Vorschläge:
1. Versuchen Sie, den Besitzer des geplanten Jobs zu niemandem zu ändern (anstelle von admin, und ändern Sie dann den Befehl loadjob entsprechend) (Bearbeiten Sie
local.meta im App-Kontext Ihrer gespeicherten Suche, um dies zu tun)
2. Die zeitgesteuerte Suche kann übersprungen werden (überprüfen Sie dies, indem Sie zu Einstellungen -> Systemaktivität -> Zeitplanberichte wechseln)
3. Das Dispatch-Verzeichnis kann für den Admin-Benutzer voll sein. Überprüfen Sie die Größe und die Beschränkungen des Dispatch-Verzeichnisses
4. Der Name der geplanten Suche kann im Befehl loadjob falsch geschrieben sein.
5. Der App-Kontext, in dem sich die gespeicherte Suche befindet, kann im Befehl loadjob falsch sein.
Auflösung
Es stellte sich heraus, dass der Bericht niemandem gehörte. Das bedeutet, dass der Benutzer, der das Objekt erstellt hat, kein Benutzer im Authentifizierungssystem mehr ist. Wenn Sie einen lokalen Benutzer erstellen, sich dann als dieser Benutzer anmelden, dann ein beliebiges Wissensobjekt erstellen, dann diesen Benutzer löschen, dann werden alle seine Wissensobjekte in den Besitz von niemandem wechseln.
Punktantworten Warum erhalte ich den Fehler "Artefakte für savedsearch_ident können nicht gefunden werden..." beim Versuch, die neuesten gespeicherten Suchergebnisse in Splunk 6.3 abzurufen? https://answers.splunk.com/answers/318096/why-am-i-getting-loadjob-error-cannot-find-artifac.html
Was bedeutet "none" (unter der Besitzerspalte) bei der Suche nach und Berichterstellung im Splunk?
https://answers.splunk.com/answers/425941/what-does-nobody-under-owner-column-signify-in-spl.html
Revisionsverlauf
| Überarbeitung |
Veröffentlichungsdatum |
Kommentare |
1.0 |
28-Sep-2026
|
Erstveröffentlichung |