Start / Docs

Dokumentation

Wie DiffMon bei Monitoring, Alerts, Sicherheit und API-Integration funktioniert.

Policy Rules

Verwenden Sie Post-Diff-Regeln, um Rauschen zu unterdrücken, wichtige Änderungen zu routen und Notification-Severity zu eskalieren.

Policy Rules

Policy Rules sind deterministische Post-Diff-Regeln, die erst laufen, nachdem DiffMon einen Diff berechnet hat.

Planverfügbarkeit: Pro und höher.

Was Policy Rules tun können

  • Notifications für passende Low-Value-Änderungen unterdrücken.
  • zusätzliche Destination Routes für passende High-Impact-Änderungen hinzufügen.
  • Severity Labels von Notifications eskalieren.
  • Labels für Downstream-Routing und Triage ergänzen.

Was Policy Rules nicht ändern

  • Diff-Berechnung.
  • Incident-Grouping.
  • Baseline-Logik.
  • Persistenz von Snapshots und Diffs.

Suppression stoppt nur die Erstellung von Notification Events und Deliveries. Evidence und Incidents bleiben erhalten.

Matching-Inputs

Regeln können auf Folgendes matchen:

  • classification_in: schema_change | value_change | mixed | content_change
  • min_severity: critical | high | medium | info
  • path_prefix_any: ein oder mehrere JSON-Path-Präfixe

path_prefix_any wird in eine kanonische Slash-Prefix-Form normalisiert und dedupliziert.

Rule Schema (v1)

JSON
{
  "schemaVersion": "v1",
  "rules": [
    {
      "id": "breaking-payments",
      "enabled": true,
      "when": {
        "classification_in": ["schema_change", "mixed"],
        "min_severity": "high",
        "path_prefix_any": ["/v1/payments"]
      },
      "then": {
        "suppress_notifications": false,
        "route_destination_ids_add": ["dest_pagerduty"],
        "escalate_to": "critical",
        "labels_add": ["payments", "breaking"]
      }
    }
  ]
}

Evaluierungsverhalten

  • Regeln werden in der gespeicherten Listenreihenfolge ausgewertet.
  • Disabled-Regeln werden übersprungen.
  • Eine Regel matcht nur, wenn alle angegebenen Prädikate zutreffen.
  • suppress_notifications akkumuliert per logischem OR.
  • Routes und Labels werden vereinigt, dedupliziert und sortiert.
  • Eskalation verwendet die höchste gematchte Severity und ist gegenüber der ursprünglichen Severity monoton.

Konfiguration per API (v1)

Policy Rules werden in den Monitor-Einstellungen gespeichert.

  • GET /api/monitors/:id/settings gibt policyRulesJson zurück, wenn eine Berechtigung besteht.
  • PATCH /api/monitors/:id/settings akzeptiert policyRules mit strikter Schema-Validierung.
  • Es gilt Replace-all-Semantik:
    • senden Sie rules: [], um alles zu leeren
    • lassen Sie policyRules weg, wenn nichts geändert werden soll

Beispiel-Update:

JSON
{
  "policyRules": {
    "schemaVersion": "v1",
    "rules": [
      {
        "id": "ignore-timestamps",
        "enabled": true,
        "when": {
          "classification_in": ["value_change"],
          "path_prefix_any": ["/timestamp", "/generated_at"]
        },
        "then": {
          "suppress_notifications": true
        }
      }
    ]
  }
}

Validierungs- und Entitlement-Verhalten

  • Unbekannte Keys werden mit 400 VALIDATION abgelehnt.
  • Ungültige Enums oder Bereiche werden mit 400 VALIDATION abgelehnt.
  • Zu viele Regeln werden mit 400 VALIDATION abgelehnt.
  • Ohne Entitlement werden Updates mit 403 FORBIDDEN abgelehnt.

Best Practices

  1. Starten Sie mit einer Suppression-Regel für bekannte noisy Paths.
  2. Ergänzen Sie eine Eskalationsregel für breaking Schema Paths.
  3. Halten Sie Rule IDs stabil und beschreibend.
  4. Bevorzugen Sie enge path_prefix_any-Scopes statt breiter globaler Suppression.

Zugehörige Dokumentation