Teilnehmer zusammenbringen
Anwendungen und Dienste beschreiben ihre Ressourcen und Fähigkeiten. Controls führt daraus eine gemeinsame Sicht zusammen. Stuttgartbilder erscheint als eigenständige Anwendung; WordPress ist eine andere Teilnehmerart.
Clever Engines Layer · Bausteine und Möglichkeiten
CEL Controls
Verbindet Teilnehmer, bestätigt Beobachtungen und vermittelt definierte Aktionen.
Aufgabe
Controls hält die Fäden zusammen, ohne die Arbeit der anderen Bausteine zu übernehmen. Es kennt Teilnehmer und ihre Schnittstellen, organisiert Abrufe und macht bestätigte Ergebnisse für Resilient zugänglich.
Möglichkeiten
Beobachtungen bestätigen
Eine WordPress-Site liefert Messwerte und Ereignisse. Controls prüft den Vertrag, überträgt die Beobachtung unverändert an CEL Live und bestätigt sie durch Rücklesen. So haben Plugin und Resilient einen benennbaren gemeinsamen Stand.
Handlungen nachvollziehen
Ein Bedienauftrag hat ein Ziel, einen Zustand und ein Ergebnis. Laufende Vorgänge bleiben von abgeschlossenen Ergebnissen unterscheidbar. Ein erneuter Abruf verändert nicht nebenbei eine Messperiode.
Zusammenspiel
Die Teilnehmerdomäne besteht aus getrennten Modulen für Registrierung, Sitzungsnachweise, Zulassung und das Hybridmodell. Der Poller ergänzt die aktuelle Erreichbarkeit; Rollen und Fähigkeiten beschreiben die Struktur. Eine Beschreibung allein erteilt noch kein Ausführungsrecht.
Stuttgartbilder registriert sich als eigenständige Anwendung. Resistant registriert jede konfigurierte Instanz als eigenen Dienst. Die fachlichen Beziehungen bleiben im Controls-Kontext; Registry und struktureller Mirror kommunizieren ausschließlich im RAM.
CEL Live besitzt die vollständige Beobachtung. Controls hält Abruf- und Vorgangszustände sowie die daraus erzeugten Lesemodelle. CEL Participants spiegelt die strukturelle Registrierung über einen Controls-Neustart hinweg. Die drei Speicheraufgaben sind nicht austauschbar.
Technik
| Lokaler Zugang | 127.0.0.1:19090; Windows-Dienst CELControls |
|---|---|
| Programm | bin/cel_controls_1.3.71.exe |
| Teilnehmervertrag | cel.participant.contract.v1alpha3 |
| Hybridmodell | pkg/participanthybrid; explizite Modell-ID, Rollen, Fähigkeiten, Bindung, Descriptor-Revision und SHA-256-Hash mit kompatiblen Ableitungen für ältere Teilnehmer |
| Anwendungsmodell | cel.application.service; eingebaute, deklarative Controls-Sicht ohne nachgeladenen Teilnehmercode |
| Register | Registrierungen und Sitzungsschlüssel im RAM; Mirror über /control/participant-registry/snapshot |
| Zulassung | config/participant_trust.json ist dauerhafte Sicherheitskonfiguration und bleibt beim Update erhalten. |
| Beobachtung | cel.wp_object_cache.delivery.v2 → CEL Live → bestätigter Read-back |
| Lesemodell | /control/read-model/object-cache; Liste mit summary, Detailroute mit vollständiger Observation |
| Herkunft | observation_id, period_id, live_epoch, live_revision, payload_sha256 und getrennte UTC-Zeitpunkte |
| Polling | Standard: Tick 5 s, 4 Worker. Pro Site höchstens ein laufender Abruf; Jitter und Backoff begrenzen Wiederholungen. |
| Bedienauftrag | Wartet bis zu 5 s auf einen laufenden Site-Abruf; danach eindeutiger Fehler statt paralleler Ausführung. |
| Vorgänge | Bis zu 100 abgeschlossene Vorgänge, davon höchstens 20 erfolgreiche Routineabrufe; offene Vorgänge bleiben bis zum Ergebnis. |
| Resetjournal | data/participants/observation_resets.json; vom flüchtigen Teilnehmerregister getrennt |
| HTTPS | Eine bekannte HTTPS-Adresse wird durch einen Heartbeat für dieselbe Site nicht auf HTTP zurückgesetzt. Redirects werden nicht verfolgt. |
Zustände und Betriebsgrenzen
Verbindung, Cache, Messintegrität und Ereignisse sind getrennte Befunde. Eine gültige Sitzung ersetzt keine frische Beobachtung. Ein alter vollständiger Stand bleibt mit seinem Alter erkennbar; ein fehlgeschlagener Abruf wird nicht als neue Messung ausgegeben.
HTTP-Fehler tragen im Dienstlog Ziel-URL, Host, Status und Redirect-Ziel. site_http_301 beschreibt eine Umleitung; SITE_RECEIPT_INVALID eine nicht lesbare fachliche Antwort. HTTP-Status wird vor der Receipt-Auswertung geprüft.
Bei einem Paketaustausch bleiben die lokalen Bestände getrennt vom Quell- und Programmstand erhalten: config/, context/ (lokale Zuordnungen), participants/ (lokale Beschreibungen), data/ (Resetjournal), logs/.
Werkzeuge
Alle BAT- und PowerShell-Dateien dieses Pakets, einschließlich der internen Aufrufwege. Die Wirkung unterscheidet reine Abfragen, lokale Prüfungen und Eingriffe. Web-Abfragen sind davon getrennt.
Paketwurzel · 8 Werkzeuge
| Name | Zweck | Aufruf, Ausgabe und Wirkung |
|---|---|---|
build_all.batBuild | Prüft den Quellstand und baut die Komponenten des Pakets. | Buildphasen, Zielpfade und Compiler-/Prüfergebnis; bei Fehlern kein erfolgreicher Abschluss. Wirkung: schreibt Buildausgaben |
install_service.batBetrieb | Registriert den Windows-Dienst oder aktualisiert seinen Programmpfad. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand |
run_console.batBetrieb | Startet den Paketprozess im Vordergrund; seine Ausgabe bleibt in der Konsole. | Konsolenausgabe des Werkzeugs; Fehler über Exitcode oder benannte Fehlerzeilen. Wirkung: liestAufrufweg:build_all.bat |
start_service.batBetrieb | Startet den bereits registrierten Windows-Dienst. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand |
status_service.batDiagnose | Liest Windows-Dienststatus und den lokalen Health-Endpunkt. | Status-, Identitäts- oder Messfelder; ein Fehler bzw. Timeout bleibt als solcher sichtbar. Wirkung: liest |
stop_service.batBetrieb | Fordert das Stoppen des Windows-Dienstes an. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand |
test_controls.batPrüfung | Liest nacheinander Health und Systemübersicht von Controls. | Prüf- oder Messwerte und Exitcode. Schreibende Tests gehören an einen eigenen Testbestand. Wirkung: Testlauf |
uninstall_service.batBetrieb | Stoppt den Windows-Dienst und entfernt seine Registrierung. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand |
History
Ein bestätigter Beobachtungsweg
Die Anzeige wurde auf unveränderte Beobachtungen mit eindeutigem Herkunfts- und Revisionsnachweis ausgerichtet. Ereignisse besitzen einen eigenen Strom.
Registrierung mit eigenem Lebenszyklus
Dauerhafte Zulassung und flüchtige Sitzung wurden getrennt. Teilnehmer können sich nach Verlust ihrer Sitzung mit dem erhaltenen Bootstrap-Nachweis erneut anmelden.
Modulare Teilnehmerdomäne
Registrierung und Hybridmodell erhalten eigene Zuständigkeiten; der getrennte RAM-Mirror bewahrt die Struktur bei einem Controls-Neustart.
Verlässliche lokale Abrufe
Unabhängige Runner, kanonische Site-Adressen und nachvollziehbare HTTP-Fehler schließen Lücken zwischen Website-Traffic und lokalem Kontrollkanal.
Echte hybride Teilnehmer
Anwendungen und Resistant-Dienste registrieren nun explizite Modelle, Rollen, Bindungen und erneuerbare Leases. Eine aktive strukturelle Lease genügt für die Zuordnung; ein WordPress-spezifischer Beobachtungsvertrag ist keine Voraussetzung.