Was ist OSIRIS JSON

OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) definiert ein vendor-neutral JSON-Format zur Beschreibung von Infrastrukturressourcen, ihren Eigenschaften und ihren topologischen Beziehungen in heterogenen Umgebungen mit einem Erweiterungspfad für OT, wo dies anwendbar ist.

Als Interchange-Schema normalisiert OSIRIS JSON Exporte aus unterschiedlichen Quellen und ermöglicht die portable Nutzung durch Tools für Diagrammerstellung, Dokumentation, Inventar-/CMDB-Workflows, Audit-Nachweise und Integrationen, ohne dass jeder consumer vendor-spezifische Parser implementieren und pflegen muss.

OSIRIS JSON definiert ein kanonisches JSON-Schema, das als neutrales Middleware-Layer zwischen Infrastruktur-Datenquellen und konsumierenden Anwendungen fungiert. Anstatt vendor-spezifische Parsing-Logik in jedes Tool einzubetten, verfolgt OSIRIS JSON einen Übersetzungs-Layer-Ansatz:

PRODUCERS (parsers, translators, discovery agents) übersetzen Source-/Vendor-Darstellungen in OSIRIS-JSON-Dokumente.
CONSUMERS (Diagramm-Tools, CMDBs, IPAMs, DCIMs, Dokumentations-Pipelines) lesen und verarbeiten ein einzelnes, klar definiertes Schema.

Dadurch werden Datenquellen von konsumierenden Anwendungen entkoppelt und die Integrationskomplexität von S×C (S Quellen × C consumers) auf P+C (P producers + C consumers) reduziert.

Dadurch werden Datenquellen von Anwendungen entkoppelt und die Integrationskomplexität reduziert. In einer Umgebung mit S Quellsystemen und C konsumierenden Anwendungen verlagert sich der Integrationsaufwand von S×C direkten Mappings auf S producer-Mappings (source > OSIRIS) plus C consumer-Mappings (OSIRIS > application).

Die Herausforderung

Infrastrukturdaten werden über vendor-spezifische Formate und Modelle bereitgestellt, mit inkonsistenter Semantik für gleichwertige Konzepte wie Identität, Eigenschaften, Beziehungen und Hierarchie. In gemischten Umgebungen, die hyperscaler, public cloud, on-prem-Systeme und OT-Infrastruktur umfassen, verstärkt sich dieses Problem. Das Ergebnis sind fragmentiertes und teilweise teures Tooling, inkonsistente Exporte und Dokumentation mit fragmentierter oder qualitativ schlechter Topologie, die schnell veraltet.

crisis_alert

Folgen der Fragmentierung

crisis_alert

Integrationskomplexität

Tools müssen vendor-spezifische adapters, mappings und translators pflegen.
crisis_alert

Hohe Wartungskosten

Vendor-spezifische APIs und Datenmodelle entwickeln sich weiter und erzwingen kontinuierliche Updates an Parsern und Integrationen, wodurch die Kosten im Laufe der Zeit explodieren.
crisis_alert

Inkonsistente Topologie-Semantik

Beziehungen können implizit, unvollständig oder je nach Quelle unterschiedlich dargestellt sein, was Topologie schwer vergleichbar und wiederverwendbar macht.
crisis_alert

Dokumentationsdrift

Manuelle Übersetzung ist fragil; Dokumentation ist oft schwach und Diagramme sind meist von geringer Qualität, mit unverständlichen Icons und chaotischen Flows, die schnell veralten.
crisis_alert

Risiko von Tribal Knowledge

Ohne einen gemeinsamen Standard steckt kritischer Kontext oft in den Köpfen von Personen. Wenn diese gehen, geht dieses Wissen mit ihnen, und Systeme werden schwerer zu verstehen und zu betreiben.
crisis_alert

Lock-in-Risiko

Organisationen können von geschlossenen, vendor-spezifischen oder kostenpflichtigen Normalisierungslösungen abhängig werden, die schwer zu ersetzen sind oder möglicherweise nicht mit einer langfristigen Perspektive gepflegt werden.

verified

Open-Standard-Ansatz von OSIRIS JSON

verified

Neutrales JSON-Interchange-Schema

Ein vendor-neutral Format zum Austausch von Infrastrukturressourcen und Topologie zwischen Systemen.
verified

Producers übersetzen Source-Exporte in OSIRIS-Dokumente

Parsers/translators/discovery agents mappen native Darstellungen auf das OSIRIS-Schema.
verified

Consumers implementieren ein Schema für viele Quellen

Tools können ein einzelnes, klar definiertes Dokumentformat über verschiedene Umgebungen hinweg lesen.
verified

Explizite, erstklassige Topologie-Beziehungen

Connections, Abhängigkeiten, Containment und Gruppierung werden direkt dargestellt, sodass ein Snapshot beschreiben kann, was existiert und wie es zu einem bestimmten Zeitpunkt zusammenhängt.
verified

Vorwärtskompatibilität durch sicheres Ignorieren unbekannter Felder

Consumers können unbekannte Eigenschaften und Erweiterungen ignorieren, ohne die Grundverarbeitung zu beeinträchtigen.
verified

Erweiterungen werden nativ unterstützt

Ein definierter Mechanismus erlaubt es vendors und Benutzern, Dokumente anzureichern, ohne die Interoperabilität zu brechen.

Kernfähigkeiten

schema Einheitliches Design

Entwickelt für heterogene IT-Umgebungen, mit einem klaren Erweiterungspfad für OT und andere Domänen, wenn die Akzeptanz wächst.

hub Explizites Beziehungsmodell

Erstklassige Darstellung von connections, Abhängigkeiten, Containment und anderen Topologie-Beziehungen.

account_tree Gruppierungskonstrukte

Unterstützung für logische und physische Gruppierung, die reale organisatorische und architektonische Strukturen widerspiegelt, ohne eine einzelne Taxonomie zu erzwingen.

dns Provider-Zuordnung

Ressourcen bewahren die Nachvollziehbarkeit zu ihrem Quellsystem/provider, während sie eine standardisierte, vendor-neutral Darstellung verwenden.

extension Erweiterbarkeit

Ein definierter Mechanismus für vendor-spezifische Eigenschaften und custom resource types, ohne die Kompatibilität zu brechen.

verified_user Dreistufige Validierung

Strukturelle (schema), semantische und domänenspezifische Validierung verbessert Konsistenz und Datenqualität, wenn Validierungs-Tooling angewendet wird.

Designprinzipien

Statisches Snapshot-Format

OSIRIS JSON ist ein statisches Snapshot-Interchange-Format. Es erfasst, was existiert und wie es zu einem Zeitpunkt zusammenhängt. Es wurde nicht als Echtzeit-Monitoring-System, Deployment-Tool oder Infrastructure-as-Code-Engine entworfen.

Was OSIRIS JSON NICHT ist

close Keine Echtzeit-Telemetrie und kein Monitoring

OSIRIS JSON beschreibt den Zustand von Topologie und Inventar, nicht Zeitreihenmetriken, Logs oder Observability-Daten. Projekte wie Prometheus, Grafana, Zabbix, OpenTelemetry decken Telemetrie-Anforderungen ab.

close Kein Infrastruktur-Deployment und keine Orchestrierung

OSIRIS JSON ist keine infrastructure-as-code-Sprache und keine Deployment-Spezifikation. Projekte wie Terraform, CloudFormation oder TOSCA Oasis decken Deployment-Workflows ab.

close Kein Konfigurationsmanagement

OSIRIS JSON definiert oder erzwingt keine desired state-Konfiguration für Ressourcen. Konfigurationsmanagement-Systeme wie Ansible, Puppet, Chef, Salt erfüllen diesen Zweck.

close Kein Change-Tracking und keine Historie

OSIRIS JSON stellt einen Snapshot zu einem bestimmten Zeitpunkt dar. Das Nachverfolgen von Änderungen über die Zeit liegt in der Verantwortung produzierender und konsumierender Systeme.

close Keine Authentifizierung, Autorisierung und Zugriffsrichtlinien

OSIRIS JSON kann metadata transportieren, die Grenzen oder ownership beschreiben, definiert jedoch keine Zugriffskontrollmechanismen oder -richtlinien.

close Kosten- und Abrechnungsinformationen

Detaillierte Abrechnung und Finanzmodellierung liegen außerhalb des Geltungsbereichs des core schema, obwohl kostenbezogene metadata per extension einbezogen werden können.

Dokumentstruktur

OSIRIS-Dokumente sind JSON-Objekte. In Specification v1.0.0 ist das Top-Level-Objekt um drei Felder herum definiert: version, metadata und topology. Ein optionales Feld $schema kann aufgenommen werden, um auf die Schema-URI zu verweisen.

[!NOTE] Dies ist ein Top-Level-Überblick über das OSIRIS-JSON-Schema. $defs werden hier aus Gründen der Lesbarkeit auf Top-Level-Ebene ausgelassen; die vollständige Schema-Definition finden Sie unter der kanonischen URI.

Das OSIRIS JSON core schema definiert:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema#",
  "$id": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "title": "Core OSIRIS JSON Schema v1.0",
  "description": "OSIRIS Open Standard for Infrastructure Resource Interchange Schema. This schema encodes baseline interoperability requirements; additional semantic rules (e.g. referential integrity, uniqueness) are validated by tooling.",
  "type": "object",
  "required": [
    "version",
    "metadata",
    "topology"
  ],
  "properties": {
    "$schema": {
      "type": "string",
      "description": "Optional JSON Schema dialect reference for OSIRIS documents.",
      "format": "uri"
    },
    "version": {
      "type": "string",
      "description": "OSIRIS specification version of this document (semver). For the v1.0 schema endpoint, any 1.x.y is allowed.",
      "pattern": "^1\\.[0-9]+\\.[0-9]+$"
    },
    "metadata": {
      "$ref": "#/$defs/metadata"
    },
    "topology": {
      "$ref": "#/$defs/topology"
    }
  },
  "additionalProperties": true,
  "$defs": {
    "osirisType": { },
    "providerName": { },
    "namespaceKey": { },
    "tags": { },
    "freeformObject": { },
    "extensions": { },
    "provider": { },
    "resource": { },
    "connectionDirection": { },
    "connectionType": { },
    "connection": { },
    "group": { },
    "topology": { },
    "metadataGenerator": { },
    "metadataScope": { },
    "metadata": { }
  }
}

topology.resources

Eindeutig identifizierbare Infrastruktur-Entitäten mit Eigenschaften und Provider-Zuordnung.

topology.connections

Explizite Beziehungen und Richtung zwischen Ressourcen (network, dependency, containment, data flow, etc.).

topology.groups

Logische oder physische Sammlungen, die Ressourcen organisieren (z. B. VPC, subnet, rack, data center).

Validierung und Interoperabilität