Installation & Betrieb

Ein Server im Werk

WERKSPUR läuft als Docker-Compose-Stack auf einem Server in Ihrem Werk hinter Ihrer eigenen Firewall. Die Kernfunktionen benötigen keinen Cloud-Dienst. Nur optionale Integrationen, insbesondere ein externer KI-Anbieter, benötigen die von Ihnen freigegebene Verbindung zum jeweiligen Ziel.

Der Stack besteht aus der Anwendung, PostgreSQL, NATS, MQTT, AMQP, einem Backup-Dienst und Caddy als TLS-Zugang. Über Caddy laufen alle Zugriffe von Stationen und Browsern. Die mitgelieferte Compose-Datei veröffentlicht zusätzlich Broker-Ports für Entwicklung und Tests. Entfernen Sie diese Portfreigaben im Produktivbetrieb oder binden Sie sie an 127.0.0.1, wie es die Kommentare in der Datei vorsehen.

Die Stationen erreichen ausschließlich den TLS-Edge. Innerhalb des Servers verbindet die Anwendung Datenbank und Nachrichtenwege; der Backup-Dienst liest die Datenbank unabhängig von den Benutzerzugriffen.

flowchart TB
    Clients["Browser und Stationen"] --> Edge

    subgraph PlantServer["Server im Werk"]
        Edge["TLS-Edge"] --> App["Anwendung"]
        App --> Database["Datenbank"]
        App --> Bus["Nachrichtenbus"]
        App --> Mqtt["MQTT-Broker"]
        App --> Amqp["AMQP-Broker"]
        Database --> Backup["Backup-Dienst"]
        Backup --> Dumps["Sicherungsdateien"]
    end

    App -.->|"optional"| Integrations["Freigegebene Integrationen"]

Jeder dieser Dienste startet mit der Compose-Option restart: unless-stopped. Nach einem Prozess- oder Serverausfall startet Docker die Container erneut, sobald der Docker-Dienst wieder läuft. Aktivieren Sie dafür Docker beim Systemstart:

sudo systemctl enable docker

Installation

Voraussetzung ist Docker mit dem docker compose-Plugin. Datenbank, Nachrichtenbus, Broker und Edge laufen als Container. Kopieren Sie zuerst die Beispielkonfiguration:

cp deploy/.env.example deploy/.env

Öffnen Sie deploy/.env. Setzen Sie den Bootstrap-Zugang für den ersten Admin und den Master-Schlüssel. Wählen Sie außerdem den TLS-Modus bewusst.

Für ein Produktivsystem benötigen Sie zusätzlich die an diese Installation gebundene Lizenz. Erzeugen und übertragen Sie diese wie unter Lizenzbetrieb beschrieben.

Eine Produktivinstallation verwendet die mitgelieferte Datei deploy/docker-compose.production.yml. Diese Datei enthält keine Build-Einträge; die beiden WERKSPUR-Images stammen als vorgebaute, signaturprüfende Ausgaben aus dem Release-Kanal des Anbieters. Übernehmen Sie die beiden Image-Verweise unverändert aus dem Release-Manifest in deploy/.env:

WERKSPUR_IMAGE=registry.example/werkspur@sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
WERKSPUR_EDGE_IMAGE=registry.example/werkspur-edge@sha256:60303ae22b998861bce3b28f33eec1be758a213c86c93c076dbe9f558c11c752

Beide Werte müssen unveränderliche @sha256-Digest-Verweise sein. Reine Tag-Angaben wie :latest lehnt der Produktionsstart ab. Legen Sie außerdem vor dem ersten Start die Lizenz nach Lizenzbetrieb ab. Dann laden und starten Sie den Stack:

make production-pull
make production-up

Beide Kommandos laufen über deploy/production-compose.sh. Das Skript prüft zuerst die Digest-Verweise und ruft dann docker compose mit der Produktionsdatei auf. Mit make production-config prüfen Sie die Konfiguration, ohne etwas zu starten; make production-down stoppt den Stack und erhält alle Volumes.

Für alle weiteren Beispiele in diesem Kapitel gilt: Auf einem Produktivsystem ersetzen Sie den Aufruf docker compose -f deploy/docker-compose.yml durch ./deploy/production-compose.sh. Unterbefehle und Dienstnamen sind identisch.

Der Quellstand in diesem Repository baut mit make stack-up dagegen ausdrücklich die Entwicklungs-Ausgabe ohne Lizenzprüfung. Das ist für Entwicklung und lokale Prüfung gedacht, nicht für eine Produktivinstallation:

make stack-up

Das Entwicklungskommando verwendet docker compose up --build --detach --wait. Dienste mit einem Healthcheck müssen den Zustand healthy erreichen. Dienste ohne Healthcheck, derzeit backup und caddy, müssen laufen; --wait prüft ihre Funktion nicht weiter. Der Healthcheck des werkspur-Containers verwendet /readyz.

Readiness prüfen

Prüfen Sie nach dem Start zusätzlich die Readiness über den Edge. Im Modus FOUNDRY_EDGE_TLS=none verwenden Sie HTTP und den über FOUNDRY_EDGE_PORT veröffentlichten Port, standardmäßig 8080:

curl -fsS http://localhost:8080/readyz \
  | grep -Eq '"status"[[:space:]]*:[[:space:]]*"ok"'

Für FOUNDRY_EDGE_TLS=internal oder custom verwenden Sie HTTPS, den exakten Wert aus FOUNDRY_EDGE_DOMAIN und den über FOUNDRY_EDGE_TLS_PORT veröffentlichten Port. Ersetzen Sie im folgenden Beispiel die Domain durch Ihren konfigurierten Wert und den Port bei Bedarf durch Ihre Zuordnung. Der Name muss vom Prüfgerät zum WERKSPUR-Server auflösbar sein:

WERKSPUR_EDGE_DOMAIN='werkspur-host.internal.invalid'
WERKSPUR_EDGE_TLS_PORT='8443'
curl -fsS --cacert ./caddy-root.crt \
  "https://${WERKSPUR_EDGE_DOMAIN}:${WERKSPUR_EDGE_TLS_PORT}/readyz" \
  | grep -Eq '"status"[[:space:]]*:[[:space:]]*"ok"'

--cacert ./caddy-root.crt ist für internal geeignet, nachdem Sie das Caddy-Root-Zertifikat wie im TLS-Abschnitt exportiert haben. Bei custom verwenden Sie stattdessen das freigegebene CA-Bündel Ihrer PKI. Ist die ausstellende Zertifizierungsstelle bereits im Vertrauensspeicher des Betriebssystems hinterlegt, lassen Sie --cacert weg. Verwenden Sie nicht -k oder --insecure, weil damit weder die Zertifikatskette noch der konfigurierte Hostname geprüft würde.

Die Befehle folgen keiner Weiterleitung. Die Pipeline ist nur erfolgreich, wenn die Antwort von /readyz den Status ok enthält; eine HTTP-Weiterleitung erfüllt diese Prüfung nicht. Bei Port 443 dürfen Sie die Portangabe in der HTTPS-URL weglassen.

Öffnen Sie anschließend im Browser dieselbe mode-gerechte Basisadresse: bei none über http:// und FOUNDRY_EDGE_PORT, bei internal oder custom über https://, FOUNDRY_EDGE_DOMAIN und FOUNDRY_EDGE_TLS_PORT. Auch der Browser muss der ausstellenden CA vertrauen. Damit prüfen Sie die Auslieferung der Oberfläche durch Caddy. Melden Sie sich danach mit dem Bootstrap-Zugang an.

Drei Anwendungsvariablen haben im Compose-Stack keinen Standardwert: FOUNDRY_BOOTSTRAP_ADMIN_BADGE, FOUNDRY_BOOTSTRAP_ADMIN_PIN und FOUNDRY_SECRET_KEY. Fehlt eine davon, bricht bereits die Compose-Interpolation ab. Für die WERKSPUR-Anmeldung gibt es daher keine mitgelieferten Standard-Anmeldedaten. Die lokalen Datenbank- und Broker-Standardwerte sind davon getrennt. Ändern Sie diese für jede gemeinsam genutzte Bereitstellung und schließen Sie die veröffentlichten Broker-Ports.

TLS

Caddy übernimmt TLS und reicht /api/*, /healthz und /readyz an die Anwendung weiter; alles andere liefert es als Oberfläche aus. Die Variable FOUNDRY_EDGE_TLS wählt einen von drei Modi.

Im Modus none läuft alles über reines HTTP. Das reicht für Testbetrieb im vertrauten Netz, nicht für Stationen, die aus einem öffentlichen oder gemischten Netz zugreifen.

Im Modus internal stellt Caddy ein lokales Zertifikat aus. Setzen Sie dafür FOUNDRY_EDGE_DOMAIN auf den Namen oder die IP, unter der die Stationen den Server erreichen. Ohne diese Angabe bleibt Caddy bei einem reinen HTTP-Eintrag, und HTTPS kommt nicht zustande. Das Root-Zertifikat liegt danach im caddy-data-Volume; Sie exportieren es einmal aus dem laufenden Container:

docker compose -f deploy/docker-compose.yml cp \
  caddy:/data/caddy/pki/authorities/local/root.crt ./caddy-root.crt

Importieren Sie diese Datei einmal pro Gerät in den Zertifikatsspeicher des Browsers. Ohne diesen Import zeigt der Browser eine Vertrauenswarnung, obwohl die Verbindung verschlüsselt ist. Im Modus custom legen Sie ein eigenes cert.pem und key.pem unter deploy/certs/ ab. Caddy bindet beide Dateien schreibgeschützt ein und verwendet sie unverändert. Setzen Sie FOUNDRY_EDGE_DOMAIN auf den Hostnamen des Zertifikats. Ohne Domain bleibt der Edge beim reinen HTTP-Eintrag. Bei einer Zertifikatskette zu einer bereits vertrauenswürdigen öffentlichen oder internen Zertifizierungsstelle ist kein zusätzlicher Import erforderlich.

Zwei Ports steuern den Zugriff: FOUNDRY_EDGE_PORT (Standard 8080) für HTTP und FOUNDRY_EDGE_TLS_PORT (Standard 8443) für HTTPS. Für einen echten Produktivbetrieb setzen Sie beide auf die üblichen Web-Ports:

FOUNDRY_EDGE_PORT=80
FOUNDRY_EDGE_TLS_PORT=443

Sobald FOUNDRY_EDGE_DOMAIN gesetzt ist, leitet Caddy HTTP-Aufrufe auf Port 443 der Domain um, nicht auf FOUNDRY_EDGE_TLS_PORT. Mit den Standardports 8080 und 8443 erreicht diese Weiterleitung keinen Listener auf Port 443.

Setzen Sie FOUNDRY_EDGE_DOMAIN nicht zusammen mit FOUNDRY_EDGE_TLS=none. Caddy versucht in dieser Kombination eine öffentliche Zertifikatsausstellung über ACME. Ohne öffentliche DNS-Auflösung und erreichbaren Port 80 wird der Edge nicht betriebsbereit. Verwenden Sie für einen internen Namen internal oder custom.

Nach jeder Änderung an FOUNDRY_EDGE_TLS oder FOUNDRY_EDGE_DOMAIN in deploy/.env starten Sie nur den Edge neu, nicht den ganzen Stack:

docker compose -f deploy/docker-compose.yml up -d caddy

Anwendung, Datenbank und Nachrichtenbus laufen währenddessen unverändert weiter.

Konfigurationsebenen

deploy/.env ist eine Eingabe für Docker Compose. Compose übergibt nur die in deploy/docker-compose.yml ausdrücklich zugeordneten Werte an die einzelnen Container. Die Anwendung liest ihre Umgebung einmal beim Start. Einstellungen in der Oberfläche oder HTTP-API ändern diese Startumgebung nicht.

Für einen direkt gestarteten oder selbst paketierten werkspur-Prozess gilt eine andere Grenze: Er liest alle unterstützten FOUNDRY_*-Variablen direkt. Eine unbekannte Variable mit diesem Präfix verhindert den Start. Ein unbekannter Eintrag in deploy/.env, den die mitgelieferte Compose-Datei keinem Container zuordnet, hat dagegen keine Wirkung.

Mitgelieferter Compose-Stack

Variable	Standard und Wirkung im Compose-Stack
`POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB`	Compose konfiguriert PostgreSQL und baut daraus `FOUNDRY_POSTGRES_URL`. Setzen Sie ein eigenes Datenbankpasswort für jede gemeinsam genutzte Umgebung. Ein abweichender `POSTGRES_USER` erfordert Anpassungen am fest eingetragenen PostgreSQL-Healthcheck und an `deploy/scripts/backup-verify.sh`. Ein abweichender `POSTGRES_DB` erfordert nur die Anpassung des Healthchecks; das Verifikationsskript verwendet eine eigene temporäre Datenbank.
`FOUNDRY_BOOTSTRAP_ADMIN_BADGE`, `FOUNDRY_BOOTSTRAP_ADMIN_PIN`	Beide Werte sind Pflicht. Sie legen den ersten Admin nur bei leerer Benutzertabelle an. Danach verwalten Sie Zugänge unter „Benutzer“, siehe Benutzer & Audit.
`FOUNDRY_SECRET_KEY`	Pflichtwert: base64-kodierter 32-Byte-Master-Schlüssel für den Secret-Speicher und den daraus abgeleiteten Audit-HMAC-Schlüssel. Sichern Sie denselben Wert getrennt vom Server. Details finden Sie unter Sicherheit im Betrieb.
`FOUNDRY_SEED_PROFILE`	Wählt beim Start ein mitgeliefertes Seed-Profil; ohne Wert gilt das Standardprofil. Ein nicht unterstützter Bezeichner verhindert den Start. Die Seed-Anwendung legt fehlende Einträge an und überschreibt vorhandene Definitionen grundsätzlich nicht. Wählen Sie das Profil vor der Erstinbetriebnahme; ein späterer Wechsel ist keine Datenmigration.
`FOUNDRY_LOG_LEVEL`	Mindeststufe der strukturierten Anwendungslogs, standardmäßig `info`. Ungültige Werte verhindern den Start.
`FOUNDRY_EDGE_DOMAIN`, `FOUNDRY_EDGE_TLS`, `FOUNDRY_EDGE_PORT`, `FOUNDRY_EDGE_TLS_PORT`	Compose und Caddy verwenden diese Werte für Domain, TLS-Modus und veröffentlichte Ports. Die Anwendung selbst liest sie nicht.
`FOUNDRY_BACKUP_RETENTION_DAYS`	Der Backup-Container löscht Dumps, die älter als diese Anzahl Tage sind. Standard ist `14`. Die Anwendung selbst liest den Wert nicht.
`FOUNDRY_MQTT_URL`	Compose setzt bei fehlendem oder leerem Wert `tcp://mosquitto:1883`. Die MQTT-Bridge ist im mitgelieferten Stack daher standardmäßig aktiv. Eine andere nicht leere URL ersetzt den internen Broker. Zum Deaktivieren müssen Sie die Zuordnung in `deploy/docker-compose.yml` ausdrücklich auf einen leeren Wert ändern. Zuordnungen und Payloads beschreibt MQTT & Telemetrie.
`FOUNDRY_AMQP_URL`	Compose setzt bei fehlendem oder leerem Wert `amqp://rabbitmq:5672/`. Der Wert aktiviert nur die eingehende Bridge; die tatsächliche Verbindung stammt aus dem AMQP-Zielsystem des jeweiligen Listeners. Zum Deaktivieren müssen Sie die Compose-Zuordnung ausdrücklich leeren. Details finden Sie unter AMQP-Listener.
`FOUNDRY_AI_PROVIDER`	`anthropic` ist der Standard für die direkte API; `bedrock` wählt AWS Bedrock. Andere Werte verhindern den Start.
`FOUNDRY_AI_MODEL`	Eine leere Angabe verwendet für die direkte API den eingebauten Modellstandard. Für `bedrock` ist eine nicht leere Bedrock-Modell-ID erforderlich.
`FOUNDRY_ANTHROPIC_API_KEY`	Optionaler Schlüssel für die direkte API. Ist er beim Anbieter `anthropic` leer, bleibt die KI-Funktion deaktiviert; die übrige Anwendung bleibt verfügbar.
`AWS_BEARER_TOKEN_BEDROCK`, `AWS_REGION`	Compose reicht beide Werte für Bedrock weiter. Alternativ kann eine angepasste Bereitstellung die Standard-AWS-Anmeldekette bereitstellen. Anbieter, Modell und Betriebsgrenzen beschreibt Der KI-Assistent.

FOUNDRY_HTTP_ADDR, FOUNDRY_POSTGRES_URL und FOUNDRY_NATS_URL sind in der Compose-Datei fest für das interne Netz gesetzt. Ein gleichnamiger Eintrag nur in deploy/.env überschreibt diese Werte nicht. Ändern Sie dafür die Zuordnung in deploy/docker-compose.yml.

Direktstart und angepasste Bereitstellung

Die folgende Tabelle beschreibt den Konfigurationsloader eines direkt gestarteten oder selbst paketierten werkspur-Prozesses. „Nicht gesetzt“ bedeutet, dass die Variable in der Prozessumgebung fehlt. Ein expliziter Leerwert ist dagegen ein vorhandener Eintrag wie FOUNDRY_LOG_LEVEL=.

Variable	Verhalten außerhalb der unveränderten Compose-Zuordnung
`FOUNDRY_HTTP_ADDR`	Nicht gesetzt: `:8080`. Ein expliziter Leerwert verhindert den Start. Ein nicht leerer Wert legt die Listen-Adresse fest.
`FOUNDRY_POSTGRES_URL`, `FOUNDRY_NATS_URL`	Nicht gesetzt oder leer: Die jeweilige Abhängigkeit und die davon abhängigen Module bleiben deaktiviert; `/readyz` überspringt die zugehörige Prüfung. Ein nicht leerer Wert aktiviert Verbindung und Readiness-Check.
`FOUNDRY_BOOTSTRAP_ADMIN_BADGE`, `FOUNDRY_BOOTSTRAP_ADMIN_PIN`	Außerhalb des Compose-Stacks sind beide optional, müssen aber gemeinsam gesetzt oder gemeinsam leer sein. Ohne beide Werte entsteht kein Bootstrap-Admin. Mit beiden Werten wird er nur bei leerer Benutzertabelle angelegt. Genau ein nicht leerer Wert verhindert den Start.
`FOUNDRY_LOG_LEVEL`	Nicht gesetzt: `info`. Ein expliziter Leerwert oder eine unbekannte Stufe verhindert den Start. Die unveränderte Compose-Zuordnung ersetzt einen fehlenden oder leeren Wert dagegen durch `info`.
`FOUNDRY_SEED_PROFILE`	Nicht gesetzt: das Standardprofil. Ein expliziter Leerwert oder nicht unterstützter Bezeichner verhindert den Start. Die unveränderte Compose-Zuordnung ersetzt einen fehlenden oder leeren Wert durch den Standard.
`FOUNDRY_LABEL_PRINTER_ADDR`	Nicht gesetzt oder leer: Etiketten-Consumer deaktiviert. Eine nicht leere Adresse `host:port` aktiviert ZPL über TCP. Die unveränderte Compose-Datei reicht diese Variable nicht weiter; ergänzen Sie dort bei Bedarf `werkspur.environment`. Siehe Etiketten & Drucker.
`FOUNDRY_MQTT_URL`, `FOUNDRY_AMQP_URL`	Nicht gesetzt oder leer: jeweilige Bridge deaktiviert. Eine nicht leere MQTT-URL wird direkt verwendet. Eine nicht leere AMQP-URL muss mit `amqp://` oder `amqps://` beginnen und aktiviert nur die eingehende Bridge. Im unveränderten Compose-Stack ersetzen die internen Standards auch Leerwerte.
`FOUNDRY_SECRET_KEY`, `FOUNDRY_SECRET_KEY_FILE`	Ist `FOUNDRY_SECRET_KEY` nicht gesetzt oder explizit leer, versucht die Anwendung die in `FOUNDRY_SECRET_KEY_FILE` angegebene Datei. Ein nicht leerer `FOUNDRY_SECRET_KEY` hat immer Vorrang und muss gültiges Base64 sein, das genau 32 Byte dekodiert; ungültiges Base64 oder eine andere Länge verhindert den Start, auch wenn zugleich eine gültige Datei angegeben ist. Die Datei darf den Schlüssel base64-kodiert oder als genau 32 Rohbytes enthalten; ein Lese- oder Formatfehler verhindert ebenfalls den Start. Der mitgelieferte Compose-Stack übergibt die Dateivariable nicht und verlangt einen nicht leeren `FOUNDRY_SECRET_KEY`.
`FOUNDRY_AI_PROVIDER`	Nicht gesetzt: `anthropic`. Ein expliziter Leerwert oder ein anderer Wert als `anthropic` oder `bedrock` verhindert den Start. Die unveränderte Compose-Zuordnung ersetzt einen fehlenden oder leeren Wert durch `anthropic`.
`FOUNDRY_AI_MODEL`, `FOUNDRY_ANTHROPIC_API_KEY`	Ein fehlendes oder leeres Modell verwendet bei `anthropic` den eingebauten Standard; `bedrock` verlangt ein nicht leeres Modell. Ein fehlender oder leerer direkter API-Schlüssel lässt den Anthropic-Client deaktiviert.
`FOUNDRY_AI_KILL_SWITCH`	Nicht gesetzt: `false`. Ein expliziter Leerwert oder nicht parsebarer Boolean-Wert verhindert den Start. Der Wert initialisiert nur eine noch nicht vorhandene KI-Einstellungszeile. Die unveränderte Compose-Datei reicht ihn nicht weiter.
`FOUNDRY_AI_MONTHLY_CAP_USD`	Nicht gesetzt: `0`, also kein Limit. Ein expliziter Leerwert, ein nicht numerischer oder ein negativer Wert verhindert den Start. Der Wert initialisiert nur eine noch nicht vorhandene KI-Einstellungszeile. Die unveränderte Compose-Datei reicht ihn nicht weiter.

Wenn FOUNDRY_SECRET_KEY leer oder nicht gesetzt ist und auch FOUNDRY_SECRET_KEY_FILE leer oder nicht gesetzt ist, bleiben Secrets deaktiviert und die Audit-Kette verwendet den schlüssellosen SHA-256-Modus. Existieren bereits gespeicherte Secrets, verhindert der fehlende Schlüssel den Start. Den laufenden KI-Not-Aus-Schalter und das Monatslimit lesen und ändern Admins ausschließlich über GET und PUT /api/ai/settings; ein Editor in der Oberfläche existiert derzeit nicht.

Updates

Für ein Produktiv-Update übernehmen Sie die neuen WERKSPUR_IMAGE- und WERKSPUR_EDGE_IMAGE-Digests aus dem Release-Manifest in deploy/.env und starten den Stack mit unveränderten Mounts neu:

make production-pull
make production-up

Alle benannten Volumes bleiben dabei erhalten, auch die Installationsidentität der Lizenz. Das lokale Entwicklungskommando make stack-up baut dagegen Images aus dem Quellstand neu. Bei beiden Wegen gelten dieselben running- und healthy-Kriterien wie bei der Installation. Beim Start legt die Seed-Anwendung grundsätzlich nur fehlende Einträge an. Vorhandene Ansichten, Abfragen und Aktionen bleiben unverändert, auch wenn die Version ein geändertes Seed-Artefakt mitliefert.

Ein eigenes Downgrade-Werkzeug gibt es nicht. Wenn Sie auf einen früheren Datenstand zurückkehren müssen, verwenden Sie eine geprüfte Sicherung nach Backup & Wiederherstellung.

Laufender Betrieb

Zwei Endpunkte geben Auskunft über den Zustand des Systems. /healthz bestätigt nur, dass der Prozess antwortet; Abhängigkeiten prüft der Endpunkt nicht. /readyz prüft PostgreSQL und NATS, wenn diese konfiguriert sind, und antwortet bei einem fehlgeschlagenen Check mit 503. Der Docker-Healthcheck und make stack-up verwenden diesen Endpunkt. Externe Integrationen, MQTT, AMQP, Drucker und KI gehören nicht zu diesen Checks.

Logs sehen Sie mit:

docker compose -f deploy/docker-compose.yml logs -f werkspur

Die Anwendung schreibt strukturierte JSON-Logs auf die Standardausgabe, ein eigenes Logfile gibt es nicht.

Nach einem Vorfall prüfen Sie zuerst den Zustand aller Dienste:

docker compose -f deploy/docker-compose.yml ps

Führen Sie anschließend den modusspezifischen Readiness-Check aus. Er verwendet im TLS-Betrieb die HTTPS-URL mit Domain, TLS-Port und Zertifikatsprüfung und verlangt den Antwortstatus ok. Eine HTTP-Weiterleitung kann deshalb nicht als erfolgreicher Readiness-Check gelten.

Einen eigenen Metrik-Endpunkt gibt es in diesem Stack derzeit nicht. Leiten Sie die Standardausgabe bei Bedarf an Ihr Protokoll-Sammelsystem weiter. Protokollspezifische Prüfungen beschreibt Integration: Fehlersuche; Statuscodes, Sitzungen und die Grenzen von /readyz finden Sie unter API & Authentifizierung.