Betrieb

CEP ist einer der pd cep Dienste — API, Konsole und Engine befinden sich im selben Prozess.

Punkt	Wert
Port	7400 (HTTP) · 7401 (TLS)
`pd` Dienst	`cep` — nur MASTER
Konfiguration	`plantpulse-cep.properties` (gerendert)
Regeln · Event-Typen	PostgreSQL `datalake` DB
Eingang · Ausgang	Valkey

docker exec plantpulse-datalake pd status cep
docker exec plantpulse-datalake pd restart cep
docker exec plantpulse-datalake pd logs --lines 200 cep

Welches Backend ist gestartet — Eine Logzeile gibt die Antwort

CEP input path: aster.

ingest.rate_1m ist kein Beweis

Unabhängig davon, welche Engine gestartet wurde, steigt das Aufkommen. „Es läuft“ und „Was läuft“ sind unterschiedliche Fragen.

Die Methode zur Auswahl des Backends und die Reihenfolge des Wechsels finden Sie unter Backend.

Registrierungsergebnisse lesen

Sätze werden registriert, und jede Registrierung hat ein Ergebnis.

curl -fsS -H "X-API-Key: ${PP_CEP_API_KEY}" http://127.0.0.1:7400/api/v1/eql/registration

Ergebnis	Bedeutung
ACTIVE	Wurde vom gestarteten Backend empfangen und läuft
REJECTED	Wurde gespeichert, läuft aber nicht. Ein Token gibt an, aufgrund welcher Konfiguration dies geschah

REJECTED ist eine Liste, kein «Defekt»

Es ist nicht normal, dass die Anzahl 0 sein muss. Eine abgelehnte Anweisung ist der Input für den nächsten Schritt — die Konfiguration entfernen und erneut schreiben, das Backend wechseln oder die Funktion anfordern.

Wichtig ist, dass es nicht still bleibt. Ablehnungen werden gespeichert, haben einen Namen und können abgefragt werden.

Die Portabilität wird separat abgefragt.

curl -fsS -H "X-API-Key: ${PP_CEP_API_KEY}" http://127.0.0.1:7400/api/v1/eql/portability

Haupt-APIs

Pfad	Funktion
`POST /api/v1/eql/deploy`	Registrierung von Sätzen
`POST /api/v1/eql/validate`	Nur Entscheidung
`DELETE /api/v1/eql/undeploy/{id}`	Deregistrierung
`GET /api/v1/eql/registration`	Tabelle der Registrierungsergebnisse (ACTIVE / REJECTED)
`GET /api/v1/eql/portability`	Portabilität
`GET /api/v1/eql/metrics/snapshot` · `/metrics/engine`	Match-Rate · Output-Rate pro Satz, Engine-Metriken
`GET`·`POST`·`PUT`·`DELETE /api/v1/event-types`	Event-Typ Registrierung
`GET`·`POST`·`DELETE /api/v1/keys`	API-Schlüssel
`GET /api/health`	Anonyme Readiness — Engine · Cache · Schema

Satzmetriken sind Match-Rate und Output-Rate

Der Server zählt Matches und Outputs für jeden Satz; die beiden Endpunkte liefern diese Werte. Dies ist unabhängig vom gestarteten Backend.

CPU-Zeit · Wall-Clock-Time pro Satz werden nicht ausgegeben — ein Wert von 0 für nicht messbare Größen würde fälschlicherweise als «schnell» interpretiert.

Originalfassung der Regeln — Absicht in der DB, Realität in der Engine

Frage	Originalfassung
«Welche Regel sollte existieren»	`cep_statement` (datalake DB)
«Welche Regel läuft gerade»	Die gestartete Engine selbst

CREATE TABLE IF NOT EXISTS cep_statement (
    statement_name  VARCHAR(200)  NOT NULL,
    eql             TEXT          NOT NULL,
    updated_at_ms   BIGINT        NOT NULL DEFAULT 0,
    updated_by      VARCHAR(64)   NOT NULL DEFAULT '',
    CONSTRAINT cep_statement_pkey PRIMARY KEY (statement_name)
);

Ein Satz entspricht einer Zeile; Registrierung schreibt, Deregistrierung löscht.

Technische Komponenten lesen keine Geschäftstabellen

CEP ist eine Regel-Engine, kein Asset-Management. Daher schreibt es, «was laufen soll», in seine eigene Tabelle.

Das Fehlen der Spalte enabled ist beabsichtigt

Das einzige Signal zum Stoppen ist das Fehlen einer Zeile, ein Zustand, der durch die Deregistrierung erzeugt wird. Eine Spalte, die immer wahr sein muss, würde wie ein nicht existierender Schalter wirken.

Dass statement_name der Primärschlüssel ist, dient demselben Zweck — Situationen, in denen derselbe Name zwei Inhalte hat, werden abgelehnt, statt sie aufzulösen.

updated_at_ms · updated_by werden nicht vom Code gelesen — sie sind für die Person vor psql während einer Störung gedacht.

Die drei Tabellen (cep_statement · cep_event_type · cep_api_key) werden vom CEP beim Start selbst erstellt. Da sie nach dem Prinzip «behalten, falls vorhanden» funktionieren, gelten sie auch für Installationen mit bestehenden Werten.

Eingang — Valkey Stream

Konfiguration	Standardwert
Stream-Präfix	`PP:CEP-IN-STREAM`
Shard-Anzahl	`16` (`cep.stream.shard_count`)
Anzahl der gleichzeitig gelesenen Datensätze	`1000`
TLS	Aus — Werte kommen aus `cache.ssl.enabled`

Dass der Standardwert für tls «Aus» ist, basiert auf Messwerten

In der Valkey-Konfiguration der Platform gibt es keine TLS-Port-Deklaration; es wird im Klartext bedient.

🔴 Wenn dieser Wert falsch ist, schlägt es nicht offensichtlich fehl. Ein Verbindungsversuch per TLS an einen Klartext-Server führt zum Handshake-Timeout, was dann nicht als Konfigurationsfehler, sondern als Netzwerkstörung interpretiert wird.

Fehlgeschlagene oder gestaute Events werden als Dead Letter archiviert — kehren Sie nicht zu einer stillen Entsorgung zurück.

Ausgang — Ein Topic pro Satz

Ergebnisse werden an ein Valkey-Topic gesendet, das pro Satznamen eindeutig ist.

Wenn 0 Subscriber vorhanden sind, wird nur ein Log erstellt. Da das Publishing auch ohne Subscriber erfolgreich ist, ist dies der Ort, an dem Ergebnisse still verschwinden.
Bei einer Neuverteilung ist zuerst der Consumer zu stoppen, bevor die Registry geleert wird. In umgekehrter Reihenfolge sammeln sich bei jeder Neuverteilung Dead Letters.

Zeitzonen

Ebene	Wert	Festgelegt durch
Wire	epoch ms	Keine Zeitzone. Gleicher Wert in jedem `PP_TZ`
Fenstergrenze	Satz > `PP_TZ` > Ablehnung	`WINDOW TUMBLING … AT TIME ZONE`

Die Antwort auf die Registrierung enthält die tatsächlich verwendete Zeitzone und deren Quelle — damit im Nachhinein geklärt werden kann, «welcher Mitternacht» gemeint war.

Ablehnung bei falscher JVM-Zeitzone

Es wird keine Vermutung angestellt. Eine still gewählt gültige Zeitzone würde unterschiedliche Antworten pro Deployment-Host erzeugen.

Konfigurationswerte

Schlüssel	Standardwert	Beschreibung
`cep.backend`	`aster`	Backend — `aster` · `flink`. Ohne Konfiguration startet es als `aster`. Bei anderen Werten (inkl. alter Werte wie `esper` · `siddhi`) stoppt der Startvorgang mit Namensmeldung
`cep.mode`	`native`	Bei `portable` wird auch das Basis-Backend (Aster CEP) abgefragt
`cep.stream.shard_count`	`16`	Input-Shards
`cep.consumer.thread_count`	`16`	Consumer-Threads
`cep.api.max_eql_text_length`	`100000`	Maximale Satzlänge
`cep.storage.ttl_seconds`	`864000` (10 Tage)	Aufbewahrung der Betriebskennzahlen
`cep.api.key`		`X-API-Key` der Management-API
`cep.web.user` · `cep.web.password`		Konsolen-Login — wenn leer, ist nur die Konsole geschlossen

Das Verfahren zum Ändern von Werten finden Sie unter Konfiguration ändern, die Schlüsselrotation unter Passwörter · API-Schlüssel ändern.

Im Container geänderte Konfigurationen gehen beim Neustart verloren

Die Originalfassung ist das vom Deployment gerenderte Template.

Welches Backend ist gestartet — Eine Logzeile gibt die Antwort​

Registrierungsergebnisse lesen​

Haupt-APIs​

Originalfassung der Regeln — Absicht in der DB, Realität in der Engine​

Eingang — Valkey Stream​

Ausgang — Ein Topic pro Satz​

Zeitzonen​

Konfigurationswerte​

Verwandte Dokumente​