Zum Hauptinhalt springen

Separate Komponenten

Separate Komponenten werden für maßgeschneiderte Deployments genutzt: Backend auf einem Host, Connector auf einem anderen, externes Elastic oder unternehmensweite Supervisoren.

Übliche Komponenten​

  • spot-server: UI/API und operative Konfiguration.
  • spot-agent-sap: SAP-Extractor.
  • spot-license-blackbox: lokaler Validator, der vor Backend und Connector benötigt wird.
  • spotctl: Administrations- und Diagnosewerkzeug.
  • RFC SDK: SAP-Bibliotheken, die der Connector benötigt.
  • Externes oder separat verwaltetes eingebettetes Elastic.

Wann diese Variante passt​

  • Unternehmensrichtlinien schreiben eigene Verzeichnisse vor.
  • Basis-, Linux- und Observability-Teams sind getrennt.
  • Elastic ist bereits standardisiert.
  • Der Start wird in einen bestehenden Supervisor integriert.

Schreiben und Lesen trennen​

Jeder spot-agent-sap-Prozess konfiguriert genau einen Elasticsearch+Namespace-Writer und kann N SAP-Systeme extrahieren. Jeder Eintrag benötigt eine explizite ID; derselbe Wert wird als source_id geschrieben und in UI/API als targetId verwendet. Alle SAP-Systeme dieses Prozesses teilen die zwei Data Streams des Namespace, bleiben aber durch source_id isoliert.

Das Backend konfiguriert einen oder mehrere unabhängige Read Scopes mit je eigener URL, Namespace und Lese-Credentials. Standalone-Connectoren können über getrennte Prozesse mehrere Scopes versorgen. Der Katalog entdeckt jedes SAP, bindet es genau an einen Scope und wechselt nie ersatzweise zu einem anderen Elasticsearch.

Checklist​

  1. Konfigurations-, Daten- und Logpfade definieren.
  2. Ausführungsbenutzer für jeden Prozess definieren.
  3. Benötigte RFC-SDK-Variablen exportieren.
  4. Validator installieren und die Lizenz aktivieren oder installieren.
  5. Read Scopes des Backends konfigurieren und testen.
  6. Den Writer jedes Connectors mit demselben Namespace wie sein Scope konfigurieren.
  7. N SAP-Verbindungen mit expliziten, eindeutigen IDs konfigurieren.
  8. Backend und Connectoren starten.
  9. Health, Logs, Ingestion und die Zuordnung jedes source_id zum richtigen Scope unter /api/targets prüfen.

Häufige Risiken​

  • RFC-SDK-Variablen fehlen im Service.
  • Logverzeichnisse sind nicht beschreibbar.
  • Externes Elastic ist vom Backend erreichbar, aber nicht vom Connector.
  • Schreib- und Lese-Namespaces unterscheiden sich.
  • Dieselbe source_id wird in zwei Scopes geschrieben; der Target wird dann mit target_binding_conflict blockiert.