2.4 KiB
Architekturentscheidungen
1. MariaDB ist kein Event Store mehr
PostgreSQL ist ausschließlich Control Plane. ClickHouse ist ausschließlich Event-/Analytics-Plane. Dadurch konkurrieren Agent-Updates, Incident-Status und Benutzeraktionen nicht mit Milliarden append-only Events.
2. Queue vor Datenbank
Der Ingress quittiert erst, nachdem Redpanda den Batch bestätigt hat. ClickHouse-Ausfälle führen damit nicht zu HTTP-Timeout-Kaskaden bei den Collectoren. Der Processor kann nachholen, solange die Queue-Retention nicht überschritten wird.
3. Ein kanonisches Event
Es gibt keine parallelen event_logs, event_occurrences, event_count_buckets, raw_event- und Rule-Helper-Kopien mehr. Die einzige langfristige Eventtabelle ist siem.events. Das Dashboard-Rollup ist eine explizite, kleine Materialized View.
4. Raw getrennt von Analytics
Raw-Payloads sind für Parserfehler und Forensik wertvoll, aber ungeeignet als primäre Analytics-Zeile. Sie werden gzip-komprimiert in S3-kompatiblen Object Storage verschoben. ClickHouse speichert nur den Object-Key und den Index im Batch.
5. Kein Graph als Primärspeicher
Graph-Sichten können später aus ClickHouse abgeleitet werden, z. B. (User)-[:LOGGED_ON_TO]->(Host) mit first_seen, last_seen, count. Jedes einzelne Event als Graph-Knoten würde die gleiche Explosion nur in einer anderen Engine wiederholen.
6. Keine TSDB für Security-Events
Prometheus überwacht die Pipeline, speichert aber keine Benutzer-/Host-/IP-Eventdimensionen. Hochkardinale Security-Attribute gehören nach ClickHouse.
7. Idempotenz
Redpanda/Kafka-Consumer liefern at-least-once und auch ein Collector kann nach einem HTTP-Timeout denselben Batch erneut senden. Deshalb berechnet der Ingress batch_uid = SHA-256(agent_id + Batch-Inhalt) und der Processor verwendet event_uid = batch_uid:index. ReplacingMergeTree und uniqExact-States verhindern damit Zählfehler bei Queue- und identischen HTTP-Retries.
8. UI ist kein Compute-Job
Die Startseite liest events_5m und PostgreSQL-Findings. Sie startet keine Detection-Regeln. Die Event-Timeline hat immer ein begrenztes Zeitfenster und Limit.
9. Retention nach Datenklasse
- normalisierte Events: 90 Tage
- Raw: 30 Tage
- Rollups: 730 Tage
- Queue: 24 Stunden
Diese Werte sind Defaults, keine Compliance-Aussage. Rechtliche und organisatorische Anforderungen haben Vorrang.