Domů / Docs

Dokumentace

Jak DiffMon funguje v oblasti monitoringu, alertů, bezpečnosti a API integrace.

Incident inbox a message log

Jak se incidenty vytvářejí, jak je triážovat a kde auditovat každý pokus o doručení.

Incident inbox a message log

DiffMon odděluje triáž změn od diagnostiky doručování:

  • Incidents (/app/incidents) odpovídá na otázku: Co právě teď vyžaduje pozornost?
  • Message log (/app/message-log) odpovídá na otázku: Co bylo odesláno a uspělo to?

Toto rozdělení drží hlučné transportní detaily mimo vaši triážní frontu.

Jak se incidenty vytvářejí

Incident vznikne ve chvíli, kdy běh monitoru vytvoří diff changed a neexistuje žádný odpovídající otevřený nebo acknowledged incident pro stejný monitor + fingerprint.

Na vysoké úrovni:

  1. Worker vytvoří diff pro každý běh snapshotu.
  2. Pokud je diff changed, worker ho připojí k incidentu.
  3. Pokud neexistuje odpovídající unresolved incident, otevře se nový incident.
  4. Pokud odpovídající incident existuje, aktualizuje se lastActivityAt a lastDiffId.

Poznámky:

  • Diffy baseline_reset incident negenerují.
  • Historie diffů zůstává immutable, i když se incidenty seskupují.

Statusy incidentů a chování operátora

open

  • Význam: aktivní změna vyžaduje pozornost.
  • Doporučená akce: projděte poslední diff a delivery trail.

acknowledged

  • Význam: někdo incident viděl, ale není uzavřený.
  • Doporučená akce: použijte, když je ownership jasný, ale remediation ještě probíhá.

resolved

  • Význam: incident je z pohledu triáže uzavřený.
  • Doporučená akce: použijte poté, co rozhodnete, že změna je přijatá nebo opravená.

Pokud se stejný vzor změny po vyřešení objeví znovu, může se otevřít nový incident.

Policy Rules mohou pro odpovídající změny potlačit doručování notifikací, ale incidenty i diff evidence zůstávají zachované. Chování routingu a suppression viz Policy Rules.

Kde najít detaily

Stránka Incidents (/app/incidents)

Tuto stránku použijte pro triáž a ownership:

  • kontext monitoru (název + URL)
  • čas otevření, poslední aktivita, stáří
  • reference na první a poslední diff
  • rollup notifikací (sent/failed/destination count)
  • akce: Acknowledge, Resolve

Stránka Message log (/app/message-log)

Tuto stránku použijte pro diagnostiku transportu a audit:

  • destination + použitá šablona
  • delivery status a pokusy
  • latence / HTTP status
  • korelace přes diffId / incidentId / requestId
  • poslední response snippet nebo sanitizovaná chyba

Doporučený workflow

  1. Začněte v Incidents.
  2. Otevřete řádek incidentu a zkontrolujte scope, stáří a poslední aktivitu.
  3. Pokud potřebujete ověřit doručení, přejděte do Message log filtrovaného podle incidentId.
  4. Vraťte se k incidentu a zvolte Acknowledge nebo Resolve.

Filtry, na kterých záleží nejvíc

Incidents

  • status (výchozí unresolved)
  • monitor
  • přímé incidentId

Message log

  • time range
  • status
  • destination type
  • monitor
  • incidentId
  • requestId

Tyto filtry stačí k rychlé odpovědi na otázky "co se změnilo?", "kdo byl upozorněn?" a "proč doručení selhalo?".