Issues

Ein Issue ist der einzelne Datensatz eines Problems: etwas, das die eigenen Checks von Polylane gefunden haben, oder ein Alert, den ein verbundenes Tool geschickt hat. Der Datensatz führt Buch (Fingerprint, Vorkommen, Urteil, Schweregrad); der Fix-Run-Thread, der ihn bearbeitet, ist der Ort, an dem du liest, was passiert ist.

Was es leistet

Jede Erkennung durchläuft einen einzigen Lebenszyklus, egal aus welcher Quelle: Sie wird aufgezeichnet, ein Fix-Run kommt zu einem Urteil, ein bestätigter Incident wird bis zu einem Fix bearbeitet, und das Issue wird gelöst, wenn das Problem vorbei ist. Es gibt keine rohe Alert-Warteschlange, die von Hand triagiert werden muss. Duplikate werden in das bereits bestehende Issue zusammengeführt, sodass ein Problem ein Datensatz und ein Thread ist.

Woher Issues kommen

So funktioniert es

1. Ein Befund wird mit einem Fingerprint aufgezeichnet, der aus seiner Quelle gebildet wird: Ressource und Check bei Polylane-Erkennungen, Integration und Alert-ID bei Anbieter-Alerts. Ein Auslösen, das zu einem offenen Issue passt, erhöht dessen Vorkommenszähler, statt ein Duplikat anzulegen.
2. Ein Fix-Run liest die rohe Payload, die Abfrage hinter dem Alert, jüngste Metriken und deinen Code und hält dann eines von zwei Urteilen fest: confirmed (ein echtes Problem) oder dismissed (Rauschen oder erwartetes Verhalten). Ein Befund, der zu einem bereits offenen oder kürzlich gelösten Issue gehört, schließt sich diesem Issue an.
3. Ein bestätigtes Issue wird im selben Thread bis zu einem Fix bearbeitet, sofern nicht der Mindest-Schweregrad des Workspace oder ein Planlimit es zurückhält, bis eine Person es startet. Der Schweregrad ist einer von critical, high, medium, low oder info, und der Run kann ihn neu einstufen, sobald er die Belege gelesen hat.
4. Das Issue wird gelöst, wenn das Problem vorbei ist: eine Erholung vom Anbieter, ein späterer Check, der sauber zurückkommt, oder ein Alert, der still bleibt. Du kannst eines auch selbst als Resolved markieren. Kehrt dasselbe Problem innerhalb von 24 Stunden zurück (länger bei Issues, die einen Code-Defekt benennen), wird das bestehende Issue wieder geöffnet, und sein Fix-Run sieht sich die Sache neu an.

Status

Ein Issue trägt außerdem resolvedAt, sobald das Problem vorbei ist, unabhängig von seinem Status.

Wo du es findest

Öffne Issues in der Konsole, um Erkennungen zu durchsuchen, nach Schweregrad oder Status zu filtern und aktive oder zurückgehaltene Issues zu finden. Jedes Issue hat eine Seite mit Belegen, Untersuchung, Zeitachse und Eigenschaften. Investigate startet einen Run; Open thread setzt das Gespräch fort. Das API-Feld _html_url verlinkt direkt auf diese Seite, auch bei Issues ohne Run.

Unter Threads listet die Voreinstellung Fix runs die Gespräche mit dem Agenten. Die letzte Nachricht eines Runs enthält sein Ergebnis: einen Pull Request, keinen nötigen Fix oder eine Bitte um deine Unterstützung. Die Seitenleiste öffnet die Belege und jede Eskalation; Open full page öffnet den vollständigen Datensatz.

Jedes Cloud-Konto, jede Integration und jede Topologie-Ressource hat einen Tab Problems, der die Fix-Runs in diesem Bereich auflistet. Ein Issue, das nie einen Run bekommen hat, erscheint als Karte im Feed; klapp es auf und nutze Investigate, um einen zu starten. Aus Skripten ist das Issue ein vollwertiges Objekt in der API-Referenz, gelesen mit dem Scope issues:read und bearbeitet mit issues:write.

Verwandt

• Fix-Runs dafür, wie ein Run zu seinem Urteil kommt und ein bestätigtes Issue bearbeitet.
• Threads zum Lesen eines Transkripts und seiner Belege.
• Escalations dafür, was passiert, wenn der Agent dich braucht.
• Clouds für die Konten und Ressourcen, auf die Issues bezogen sind.