Scans

Das Scannen wird vollständig auf der Seite Scan-Konfiguration eingerichtet: Scope, Inhaltsauswahl, Engine-Tuning und Zeitplan liegen auf einem Bildschirm, sodass jede gespeicherte Konfiguration in sich vollständig ist.

Diese Seite ist die Referenz Option für Option. Zum Arbeiten mit dem Bildschirm siehe Scan-Konfiguration im Benutzerhandbuch.

Scope

Option	Hinweise
Name	Der Name der Konfiguration.
Projekte	Alle zugänglichen Projekte oder eine kommagetrennte Liste von Projektschlüsseln.

Inhalt

Option	Hinweise
Eingeschlossene Felder	Zu scannende Felder, z. B. summary, description.
Ausgeschlossene Felder	Zu überspringende Felder, z. B. environment, labels.
Kommentare einschliessen	Ob Issue-Kommentare gescannt werden.
Anhangsinhalte scannen	Standardmässig aus. Liest den Text in Anhängen mit denselben Regeln. Erfordert das Lizenzmerkmal SCAN_ATTACHMENTS, siehe Lizenz; Formate und Grenzwerte unter Anhänge scannen.
Textmodus	RENDERED, RAW oder beides (Standard). Beides ist es wert: gerenderter Text ist, was Menschen lesen, Rohwerte finden Secrets, die im Markup versteckt sind. Beide Varianten kommen im selben Jira-Aufruf, beides kostet also keinen zusätzlichen Request - ein Treffer in beiden Varianten wird aber als zwei Funde erfasst, einer pro Variante, weil die Textvariante Teil des Quell-Locators eines Funds ist.

Scan-Engine

Wie stark diese Konfiguration Jira belastet. Diese Einstellungen werden mit der Konfiguration gespeichert, sodass jeder Lauf exakt festhält, womit er lief.

Option	Standard	Hinweise
Worker-Anzahl	2	Parallele Scan-Worker.
Max. Issues pro Minute	1000	Durchsatzobergrenze, der wichtigste Hebel für die Jira-Last.
Batch-Grösse	100	Issues pro API-Aufruf.
Wiederholversuche	3	Wiederholungen bei transienten Jira- und API-Fehlern.
Backoff-Sekunden	30	Wartezeit zwischen Wiederholungen.
Erlaubte Scan-Fenster	keine	Optionale wöchentliche Tages-/Zeitfenster, in denen Scans starten dürfen.

Wählen Sie zunächst konservative Engine-Werte. Der Scanner ist so ausgelegt, dass die Scan-Dauer zweitrangig ist gegenüber einer sicheren Last auf Ihrer Jira-Instanz - und das Limit der Scan-Geschwindigkeit ist normalerweise Jira, nicht der Scanner.

Erlaubte Scan-Fenster

Fenster sind die Leitplanke, die Scans zur falschen Zeit von Ihrer Jira-Instanz fernhält. Bleibt die Liste leer - der Standard -, darf ein Scan starten, wann immer er gestartet wird. Mit einem oder mehreren Fenstern darf ein Scan nur noch innerhalb eines davon starten.

• Beide Startwege sind an die Fenster gebunden, der Knopf Scan starten ebenso wie der Zeitplan. Ein Fenster, das nur den Zeitplan zurückhielte, wäre kein Schutz, denn mit dem Knopf liesse es sich einfach umgehen.
• Nur der Start ist reglementiert. Ein Scan, der innerhalb eines Fensters begonnen hat, darf zu Ende laufen, auch über das Fensterende hinaus. Nichts wird mitten im Lauf angehalten; begrenzen Sie über die Durchsatzobergrenze oben, wie stark ein langer Lauf drückt.
• Ein Fenster, dessen Ende vor seinem Start liegt, läuft über Mitternacht in den Folgetag. Freitag 22:00-02:00 deckt Freitagabend bis Samstagmorgen ab - nächtliche Wartungsfenster werden als ein Fenster geschrieben, nicht um Mitternacht geteilt.
• Der Bereich ist halboffen: Ein Scan darf exakt zur Startzeit starten, zur Endzeit aber nicht mehr. Zeiten werden in der Zeitzone des Servers ausgewertet, genau wie Cron-Ausdrücke.

Ein Scan, der von Hand ausserhalb aller Fenster gestartet wird, wird abgelehnt; die Meldung nennt den nächsten Zeitpunkt, zu dem ein Fenster öffnet. Wird ein geplanter Lauf ausserhalb aller Fenster fällig, wird der Takt übersprungen statt verschoben - er reiht sich nicht ein und läuft nicht verspätet. Der übersprungene Takt wird als SCAN_SCHEDULE_SKIPPED im Audit-Log festgehalten, und das Panel meldet den letzten Lauf als übersprungen.

Ein Zeitplan, der ausserhalb seiner eigenen Fenster feuert, läuft demnach nie. Meldet eine Konfiguration wiederholt übersprungene Läufe, prüfen Sie den Cron-Ausdruck gegen die Fenster - beide werden unabhängig gesetzt, und sie laufen leicht auseinander.

Zeitplan

Hinterlegen Sie einen Cron-Ausdruck, damit die Konfiguration selbstständig Scans startet, statt darauf zu warten, dass jemand an den Knopf denkt.

• Ein Dropdown bietet Vorlagen - Every night at 03:00, Every weekday at 06:30, Every Sunday at 02:00, First of the month at 04:00, Every 6 hours und Every hour - und schreibt den passenden Ausdruck; eine eigene Änderung im Feld schaltet auf Custom.
• Ausdrücke haben sechs Felder: Sekunde Minute Stunde Tag-des-Monats Monat Wochentag, ausgewertet in der Zeitzone des Servers. Die Seite zeigt eine Vorschau der nächsten Auslösezeitpunkte.
• Eine Warnung erscheint, wenn der Ausdruck mehr als einmal täglich feuert.
• Ein Ausdruck, der gültig ist, aber nie feuern kann (zum Beispiel der 30. Februar), wird beim Speichern abgelehnt, statt still nie zu laufen.
• Die Planung ist nur aktiv, solange der Zeitplan eingeschaltet ist.

Geplante Läufe überlappen sich nie. Läuft beim Auslösen noch ein Scan derselben Konfiguration, wird der Takt übersprungen und als SCAN_SCHEDULE_SKIPPED im Audit-Log festgehalten - er reiht sich nicht hinter dem laufenden Scan ein. Das Panel zeigt den letzten und den nächsten geplanten Lauf und warnt, wenn der jüngste Versuch übersprungen wurde oder fehlschlug.

Zeitpläne hängen an der Konfiguration, nicht an einer ihrer Versionen: Das Speichern einer neuen Version übernimmt den Zeitplan. Mehrere Scanner-Instanzen an derselben Datenbank lösen einen Zeitplan nicht doppelt aus.

Scope-Vorschau

Vor dem Speichern schätzt die Vorschau die Anzahl der Projekte, Beispiel-Projektschlüssel, die Anzahl der Issues und die erwartete Laufzeit, indem sie Jira fragt, wie viele Issues der Scope tatsächlich umfasst. Prüfen Sie sie - ein Scope über "alle zugänglichen Projekte" ist meist grösser als gedacht.

Unveränderlichkeit

Scan-Konfigurationen sind unveränderliche Snapshots: Jeder Scan-Lauf referenziert die exakte Konfigurationsversion, mit der er lief, inklusive der damals gültigen Engine-Einstellungen - so bleiben Ergebnisse auch Monate später erklärbar. Um Scope oder Tuning zu ändern, speichern Sie eine neue Version. Alle Versionen derselben Konfiguration teilen sich eine Konfigurationsgruppe, an der Zeitplan und Scan-Historie hängen.

Scan-Verhalten

• Scans sind immer vollständige Scans (kein inkrementelles Scannen) und strikt lesend.
• Rohfeldwerte werden nur im Arbeitsspeicher verarbeitet und nie gespeichert.
• Laufende Scans können pausiert, fortgesetzt und abgebrochen werden; fehlgeschlagene Scans setzen am letzten Checkpoint auf, ohne Funde zu duplizieren.