Vorschau · Entwicklungsstand 1.6.1

Logs lesen und auswerten

AusführungsverlaufErfolgreiche und fehlgeschlagene Beispielausführungen mit Ergebnissen und Warnungen im Verlauf.
Erfolgreiche und fehlgeschlagene Beispielausführungen mit Ergebnissen und Warnungen im Verlauf.
  1. 1
    2 Ausführungen mit neuen Problemen

    Hinweis auf noch nicht angesehene Läufe mit Fehlern oder Warnungen.

  2. 2
    Ergebnis

    Zeigt Erfolg, Warnungen oder Fehler des abgeschlossenen Laufs.

  3. 3
    Auslöser

    Zeigt, ob der Lauf manuell oder durch eine Automation gestartet wurde.

  4. 4
    Dauer

    Zeitspanne der Ausführung; sie hilft, langsame oder ungewöhnliche Läufe zu erkennen.

Editor-Ausschnitt mit Markierungen · Lightmode · Beispieldaten · Bild anklicken zum Vergrößern. Die Ansichten erklären die Bedienung; noch nicht gewählte Quellen, Geräte oder Modelle müssen für einen ausführbaren Job ergänzt werden.

Benutzer-Doku

Logs unterscheiden den Start eines Ablaufs, seinen belegten Abschluss, fachliche Ergebnisse und die Vollständigkeit der gespeicherten Daten.

Einen Lauf in der UI untersuchen

Ablauf: Einen Lauf in der UI untersuchen
  1. 1
    Schritt 1→

    Öffne Logs und grenze Quelle, Zeitraum und gegebenenfalls Schweregrad ein. Ein enger Schweregradfilter kann hilfreiche Details verbergen.

  2. 2
    Schritt 2→

    Öffne den betreffenden Lauf. Prüfe Outcome, CompletionReason und ob die Daten vollständig gelesen wurden.

  3. 3
    Schritt 3→

    Vergleiche Step-Übersicht und Einzelereignisse. Wiederholte erfolgreiche oder übersprungene Hauptphasen-Steps können in StepSummaries aggregiert sein; Warnungen und Fehler bleiben einzeln.

  4. 4
    Schritt 4→

    Bei Automationen zuerst Triggerbeobachtung und Startentscheidung lesen, dann den zugehörigen Job-/Makrolauf. Ein abgewiesener Start ist keine ausgeführte Aktion.

  5. 5
    Schritt 5Abschluss

    Exportiere den Bericht, wenn du den Ablauf weiter untersuchen möchtest. Prüfe vor Weitergabe die enthaltenen strukturierten Pfade und Identitäten.

Leserichtung: von oben nach unten. Die Zahlen zeigen die Reihenfolge.

Die vier Log-Ansichten

Die vier Log-Ansichten im Zusammenhang
  1. 1
    ÜbersichtZeigt aktuelle Läufe und neue Probleme. Die Problemzahl umfasst den gewählten Bestand, nicht nur die sichtbaren Vorschauzeilen.
  2. 2
    Job-AusführungenZeigt konkrete Jobläufe mit Status, Dauer und Step-Verlauf. Normales Öffnen zeigt auch erfolgreiche Läufe; die Problemaktion kann gezielt nur neue Probleme filtern.
  3. 3
    AutomationenZeigt Beobachtung und Entscheidung je Trigger-ID sowie zugehörige neue oder bereits laufende Ziele. Ein bloßer Startauftrag ohne belegten Lauf bleibt angefordert beziehungsweise unklar.
  4. 4
    AnwendungsdiagnoseErlaubt Suche nach Quelle, Fachbereich und Schweregrad. Die gezielte Quelle Application schließt Job-/Makro-Ereignisse aus; quellenübergreifende Diagnose berücksichtigt auch Domain-Ereignisse.

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Beim Lesen beziehungsweise Scrollen kann die sichtbare Live-Aktualisierung pausieren; die Erfassung läuft weiter. Neu passende Ereignisse werden gezählt und können anschließend geladen werden. Weitere Seiten behalten ihren Abfrage-Snapshot, damit neue Ankünfte die Liste nicht verschieben.

Run-Export verwendet den aktuellen Filter und Checkpoint für alle passenden Läufe, nicht nur die sichtbare Seite. Bei Ereignisexport gelten entsprechend die Ereignisfilter. Nach einer Definitionänderung bleiben frühere Trigger-, Ziel- und Step-Snapshots erhalten; sie werden nicht aus der aktuellen Definition neu erfunden.

Neu, Gesehen und Erledigt

Neu, Gesehen und Erledigt – Orientierung
  1. 1
    Zusammenhang 1

    Diese Markierungen beschreiben deinen Bearbeitungsstand eines Problems, nicht die Qualität des ausgeführten Jobs. Neu weist auf noch nicht bestätigte Probleme hin; Gesehen hält fest, dass eine konkrete Beobachtung gelesen wurde; Erledigt ist eine ausdrückliche Bearbeitungsmarkierung.

  2. 2
    Zusammenhang 2

    Nach erfolgreichem Laden einer Problembeobachtung wird nur diese Auswahl bestätigt. Andere ungesehene Probleme desselben Steps oder Laufs bleiben neu. Eine erneut beobachtete gleiche Problem-ID bleibt bestätigt; neue Problem-IDs oder eine höhere Schwere können wieder Aufmerksamkeit benötigen.

  3. 3
    Zusammenhang 3

    Die Markierungen werden getrennt von den unveränderten Logs gespeichert und über Neustarts erhalten. Sie ändern weder ursprüngliche Fehler-/Warnungszahlen noch die Aufbewahrung oder den Export der Ausführungsbelege. Du kannst eine Markierung ausdrücklich wieder öffnen.

  4. 4
    Zusammenhang 4

    Bei Speicherfehlern bleibt die Bestätigung als Fehler sichtbar; die UI soll keinen erfolgreich gespeicherten Status vortäuschen. Bei unvollständiger Evidenz wird eine bestätigte Laufzusammenfassung separat behandelt, statt nicht vorhandene Ereignisse zu erfinden.

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Welche Daten aufgezeichnet werden

Welche Daten aufgezeichnet werden – Orientierung
  1. 1
    Zusammenhang 1

    Strukturierte Details folgen einer Allowlist. Bekannte geladene Secrets werden maskiert; rohe Eingabetexte, Skriptargumente und Bilder werden nicht pauschal als Datenabbild gespeichert. Erlaubte Dateipfade und Identitäten können dennoch im Bericht stehen.

  2. 2
    Zusammenhang 2

    Für Agenten: Code, typisierte Statuswerte, Run-/Step-IDs und Vollständigkeit auswerten. Message dient Menschen. Verlorene Ereignisse nicht rekonstruieren und unbekannte Endzeitpunkte nicht ersetzen.

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Entwickler- und Agenten-Doku JSON, Feldnamen, Typen und Verträge

Dieser Bereich erklärt die Bearbeitung von Textdateien und die technischen Verträge. Zur Entwickler-Doku

Identitäten und Status

Identitäten und Status im Zusammenhang
  1. 1
    RunIdIdentität eines konkreten Laufs; nicht mit Job-/Makro-/Automation-ID verwechseln.
  2. 2
    Source / SourceIdArt und Identität der Ursprungsdefinition.
  3. 3
    StepId / StepExecutionIdKonfigurierter Step und konkrete Ausführung; Wiederholungen können neue Ausführungs-IDs besitzen.
  4. 4
    ParentRunId / RelatedInstanceIdsVerbindung zu übergeordneten beziehungsweise zugehörigen Läufen/Instanzen.
  5. 5
    Outcome / CompletionReasonBelegtes Resultat und Abschlussgrund. Start, Dispatch und eine Ausgabe ersetzen keinen terminalen Abschluss.
  6. 6
    IsComplete / LostEntries / Issues / ReadStateQualität der Belege. Bei Lücken keinen Erfolg aus fehlenden Fehlerereignissen ableiten.

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Nach einem Neustart kann ein vorher offener Lauf als interrupted/incomplete erkannt werden. Ein unbekannter Abschlusszeitpunkt wird nicht erfunden. found=false beziehungsweise available=false im Step-Ergebnis bleibt eine fachliche Aussage, die vom technischen Step-Status getrennt zu prüfen ist.

JSONL und Support-Export

JSONL und Support-Export – Orientierung
  1. 1
    Zusammenhang 1

    Schema-Version 2 schreibt strukturierte JSONL-Ereignisse, Laufmetadaten und Speicherzustand unter dem lokalen Logs/v2-Verzeichnis. Eine JSONL-Zeile ist ein JSON-Objekt. Context trägt die Zuordnung; Code ist stabiler als der übersetzte Message-Text.

  2. 2
    Zusammenhang 2

    Der ZIP-Export enthält einen Manifest-/Übersichtsbestand, runs.json, JSONL-Ereignisse und report.txt. Der Store wird davor gespült; ein bestehendes Exportziel wird nicht überschrieben. Lies Laufzusammenfassung und Ereignisse gemeinsam, statt nur nach Fehlertexten zu suchen.

  3. 3
    Zusammenhang 3

    Retention hält Ereignisse standardmäßig ungefähr 30 Tage und bis ungefähr 500 MiB. Aktive geschützte Läufe können Grenzen überschreiten. Das Alter richtet sich nach dem letzten Anhängen eines Segments, nicht jeder einzelnen Zeile; Aufräumen erfolgt beim Start, bei Rotation und stündlich. Das Bestätigen eines Log-Hinweises verlängert die Aufbewahrung nicht.

  4. 4
    Zusammenhang 4

    Unlesbare Dateien und bekannte Verluste ergeben Partial/Unavailable beziehungsweise einen unvollständigen Bestand. Die UI kann lesbare Teile weiterhin zeigen. Ältere Logs werden nicht zu einem künstlich vollständigen v2-Lauf zusammengemischt.

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Ein Ereignis als JSON lesen

JSON-Aufbau: Ein Ereignis als JSON lesen
  1. 1
    SchemaVersion2
  2. 2
    Id22222222-2222-4222-8222-222222222222
  3. 3
    Sequence2
  4. 4
    Timestamp2030-01-01T08:00:01+00:00
  5. 5
    SourceJob
  6. 6
    SourceId11111111-1111-4111-8111-111111111111
  7. 7
    SourceNameWerteverbindung: 250 ms warten
  8. 8
    AreaExecution
  9. 9
    LevelInformation
  10. 10
    Codestep.completed
  11. 11
    MessageBeispiel: Warte-Step beendet.
  12. 12
    DetailsNicht angegeben
  13. 13
    Context{"RunId": "33333333-3333-4333-8333-333333333333", "InstanceId": null, "TriggerId": null, "AutomationId": null, "StepId": "warten", "StepExecutionId": "44444444-4444-4444-8444-444444444444", "ParentRunId": null}
  14. 14
    ProblemIdNicht angegeben
  15. 15
    DiagnosticCodeNicht angegeben
  16. 16
    PhaseMain
  17. 17
    Iteration1
  18. 18
    DurationMs250
  19. 19
    Parameters{}
  20. 20
    BranchDecisionNicht angegeben
  21. 21
    TriggerNicht angegeben
  22. 22
    Paths[]
  23. 23
    FlowEffectNicht angegeben
  24. 24
    CategoryExecution
  25. 25
    RelatedInstanceIds[]

Schematische Übersicht: Beschriftungen und Werte aus der Referenz, keine nachgezeichnete Bedienoberfläche.

Dieses synthetische Ereignis wurde mit den echten Log-Serializeroptionen erzeugt. In einer JSONL-Datei steht das Objekt auf einer einzelnen Zeile. PascalCase-Feldnamen wie SchemaVersion, Code und Context sowie Enum-Namen wie Job und Information bleiben erhalten.

Context.RunId verbindet das Ereignis mit dem Lauf, StepId mit der Konfiguration und StepExecutionId mit dieser konkreten Ausführung. step.completed und DurationMs=250 belegen diesen Step-Abschluss; der Abschluss des ganzen Jobs benötigt weiterhin den zugehörigen Laufstatus beziehungsweise run.completed.

Für Abfragen verwenden LogQuery und LogPage die dokumentierten Filter, Snapshot-/Sequenzgrenzen und den Lesezustand. LogStepExecution verbindet Ereignisse, Status, Ursache und gegebenenfalls eine aggregierte Summary.

JSON-Strukturbeispiel – bei Ausschnitten fehlt die vollständige Dateihülle.

{
  "SchemaVersion": 2,
  "Id": "22222222-2222-4222-8222-222222222222",
  "Sequence": 2,
  "Timestamp": "2030-01-01T08:00:01+00:00",
  "Source": "Job",
  "SourceId": "11111111-1111-4111-8111-111111111111",
  "SourceName": "Werteverbindung: 250 ms warten",
  "Area": "Execution",
  "Level": "Information",
  "Code": "step.completed",
  "Message": "Beispiel: Warte-Step beendet.",
  "Details": null,
  "Context": {
    "RunId": "33333333-3333-4333-8333-333333333333",
    "InstanceId": null,
    "TriggerId": null,
    "AutomationId": null,
    "StepId": "warten",
    "StepExecutionId": "44444444-4444-4444-8444-444444444444",
    "ParentRunId": null
  },
  "ProblemId": null,
  "DiagnosticCode": null,
  "Phase": "Main",
  "Iteration": 1,
  "DurationMs": 250,
  "Parameters": {},
  "BranchDecision": null,
  "Trigger": null,
  "Paths": [],
  "FlowEffect": null,
  "Category": "Execution",
  "RelatedInstanceIds": []
}