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.
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- undpolycrate-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¶
Nur für Superuser
DataSources verwalten systemweite Feeds und können Pflichtinformationen wie Provider-Störungen importieren. Das Anlegen und Bearbeiten ist auf Superuser beschränkt. Normale Benutzer sehen die erzeugten Notes, aber nicht die Quelle.
Schritte in der UI:
- Admin → DataSources → Neu öffnen.
- Kind wählen (
rss,api,polycrate-hub,otc-status,webhook). - URL bzw. Webhook-Config eintragen.
- Optional: Provider verknüpfen → Notes als Provider-Status.
- Optional: Credential (für
api/polycrate-hub). - Bei Pull-Kinds Interval festlegen; bei
webhookIngest-URL + optionale Tokens notieren. - 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=CRITICALgesetzt und ein Downtime-Eintrag angelegt — genauso wie für jedes andere ManagedObject.