DataSources

DataSources

DataSources sind externe Feeds, die Inhalte in die Polycrate API ziehen. Sie verbinden externe Systeme (RSS-Feeds, REST-APIs, Polycrate Hub) mit der Plattform und erzeugen daraus Objekte im System — typischerweise Notes oder Block-Templates.

Jeder Eintrag wird periodisch von einem Celery-Task ausgewertet und erzeugt beim ersten Auftreten neue Objekte. Bereits importierte Items werden idempotent erkannt und nicht erneut angelegt.

Wofür DataSources

Anwendungsfall DataSource-Kind Erzeugt
Status-Feeds von Cloud-Providern (z. B. Hetzner Status) rss Notes kind=provider-status
Open Telekom Cloud Status-API otc-status Notes + strukturierte Maintenances
Zammad-/Webhook-Statusmails (Push) webhook Notes kind=provider-status
Sicherheits- oder Produkt-News rss Notes kind=news
Externe REST-APIs periodisch abfragen api Notes (generisch)
Block-Templates aus Polycrate Hub polycrate-hub Template-Blöcke

Kinds im Überblick

rss — RSS-/Atom-Feeds

Polycrate ruft den Feed in einem konfigurierbaren Intervall ab und legt pro neuem Item eine Note an. Die Note verlinkt auf das Originalitem (source_url) und speichert Titel, Zusammenfassung und Zeitstempel.

Typisch verlinkt auf einen Provider: wenn der Feed z. B. die Statusseite eines Infrastruktur-Providers ist, wird datasource.provider gesetzt und die erzeugten Notes erhalten automatisch kind=provider-status plus Verknüpfung zu diesem Provider. So landen Provider-Störungen direkt im Timeline-/Dashboard-Kontext.

api — REST-APIs

Wie rss, aber für beliebige REST-Endpunkte mit JSON-Response. Eine Credential kann hinterlegt werden (API-Token, Basic Auth), damit geschützte Endpunkte abgefragt werden. Das Ergebnis wird in Notes übersetzt.

polycrate-hub — Block-Templates aus Poly Hub

Zieht Block-Definitionen aus dem zentralen Polycrate Hub und legt sie als installierbare Template-Blöcke an (template=true). Ersetzt die frühere Artifact-Discovery (siehe Artefakte).

otc-status — Open Telekom Cloud

Spezialisierter Pull gegen die OTC-Status-API (feste Schema-Pfade). Events werden als Notes und bei Maintenances direkt als Wartungen synchronisiert (inkl. PoP-Matching über Komponenten-Regionen). Content-Hashes erlauben Updates bei Statusänderungen.

webhook — Push-Ingest (z. B. Zammad)

Push-only: kein periodischer Sync.

POST /api/v1/datasources/{uuid}/ingest/

Optional HMAC (X-Hub-Signature) oder Bearer-Token. Typischer Flow: Zammad-Ticketmail → Note kind=provider-status → KI-Analyse → Maintenance und/oder Incident inkl. Affected Hosts/Volumes/PoPs.

Manueller Re-Scan: Note-Action rescan_provider_status bzw. DataSource rescan_notes.

Sync-Fenster

RSS- und API-Sync betrachten Items der letzten 30 Tage (älter werden ignoriert). otc-status nutzt ein konfigurierbares gleitendes Fenster (Default 45 Tage).

Beziehungen

Provider ─────────────┐
                      │ optional FK
                      ▼
┌──────────────┐   ┌──────────────┐   erzeugt     ┌─────────┐
│ Credential   │──▶│  DataSource  │──────────────▶│  Notes  │
│ (für api)    │   │  kind=rss    │               └─────────┘
└──────────────┘   │  kind=api    │
                   │  kind=…-hub  │   erzeugt     ┌───────────────┐
                   └──────────────┘──────────────▶│ Block-Template│
                                                  └───────────────┘
  • Provider ist ein globaler Katalog-Eintrag (Hersteller/Anbieter). Eine DataSource kann auf einen Provider zeigen, muss aber nicht — dann werden aus einem RSS-Feed z. B. "News" statt "Provider-Status" erzeugt.
  • Credential liefert die Authentifizierung für api- und polycrate-hub-Kinds.
  • Notes sind das primäre Output-Objekt. Jede durch eine DataSource erzeugte Note bekommt eine Rückreferenz auf die DataSource und kann im Notes-Tab aller betroffenen Objekte angezeigt werden.

DataSource einrichten

Schritte in der UI:

  1. Admin → DataSources → Neu öffnen.
  2. Kind wählen (rss, api, polycrate-hub, otc-status, webhook).
  3. URL bzw. Webhook-Config eintragen.
  4. Optional: Provider verknüpfen → Notes als Provider-Status.
  5. Optional: Credential (für api / polycrate-hub).
  6. Bei Pull-Kinds Interval festlegen; bei webhook Ingest-URL + optionale Tokens notieren.
  7. Speichern → erster Sync (Pull) bzw. Warten auf Push.

Manueller Sync über die "Reconcile"-Action; Re-Scan für Provider-Status-Notes separat.

Kontrolle & Observability

  • Last run / last success: Jede DataSource zeigt, wann zuletzt gesynct wurde und ob dabei Fehler auftraten.
  • Aktivitäten: Jeder Sync erzeugt einen Activity-Eintrag (Kind datasource_sync) mit Zähler "neu erzeugte Notes/Blocks". Die Aktivitäten sind über das Metriken-Dashboard und im Detail-View der DataSource sichtbar.
  • Fehler-Notifications: Schlägt ein Sync wiederholt fehl, wird die DataSource auf state=CRITICAL gesetzt und ein Downtime-Eintrag angelegt — genauso wie für jedes andere ManagedObject.

Verwandte Themen