O que é o OSIRIS JSON

OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) define um formato JSON vendor-neutral para descrever recursos de infraestrutura, suas propriedades e seus relacionamentos topológicos em ambientes heterogêneos, com um caminho de extensão para OT quando aplicável.

Como um schema de interchange, o OSIRIS JSON normaliza exports de fontes diversas e permite consumo portátil por ferramentas dedicadas a diagramação, documentação, workflows de inventário/CMDB, evidências de auditoria e integrações, sem exigir que cada consumer implemente e mantenha parsers específicos de vendor.

O OSIRIS JSON define um schema JSON canônico que atua como um middleware neutro entre fontes de dados de infraestrutura e aplicações consumidoras. Em vez de incorporar lógica de parsing específica de vendor em cada ferramenta, o OSIRIS JSON adota uma abordagem de camada de tradução:

PRODUCERS (parsers, translators, discovery agents) traduzem representações de source/vendor para documentos OSIRIS JSON.
CONSUMERS (diagramming tools, CMDBs, IPAMs, DCIMs, documentation pipelines) leem e processam um único schema bem definido.

Isso desacopla as fontes de dados das aplicações consumidoras, reduzindo a complexidade de integração de S×C (S sources × C consumers) para P+C (P producers + C consumers).

Isso desacopla as fontes de dados das aplicações e reduz a complexidade de integração. Em um ambiente com S source systems e C aplicações consumidoras, o esforço de integração muda de mapeamentos diretos S×C para S mapeamentos de producer (source > OSIRIS) mais C mapeamentos de consumer (OSIRIS > application).

O desafio

Dados de infraestrutura são expostos por meio de formatos e modelos específicos de vendor, com semânticas inconsistentes para conceitos equivalentes de identidade, propriedades, relacionamentos e hierarquia. Em ambientes mistos que abrangem hyperscalers, public cloud, sistemas on-prem e infraestrutura OT, o problema se agrava. O resultado são ferramentas fragmentadas e às vezes de alto custo, exports inconsistentes e documentação com topologia fragmentada ou de baixa qualidade que rapidamente fica desatualizada.

crisis_alert

Consequências da fragmentação

crisis_alert

Complexidade de integração

As ferramentas precisam manter adapters, mappings e translators específicos de vendor.
crisis_alert

Alto custo de manutenção

APIs e modelos de dados específicos de vendor evoluem, forçando atualizações contínuas em parsers e integrações e elevando os custos ao longo do tempo.
crisis_alert

Semântica de topologia inconsistente

Os relacionamentos podem ser implícitos, incompletos ou representados de forma diferente entre fontes, tornando a topologia difícil de comparar e reutilizar.
crisis_alert

Drift de documentação

A tradução manual é frágil; a documentação é pobre e os diagramas são, na maior parte do tempo, de baixa qualidade, com ícones incompreensíveis e fluxos caóticos que rapidamente ficam desatualizados.
crisis_alert

Risco de conhecimento tribal

Sem um padrão compartilhado, o contexto crítico frequentemente fica na cabeça das pessoas. Quando elas saem, esse conhecimento vai junto e os sistemas se tornam mais difíceis de entender e operar.
crisis_alert

Risco de lock-in

As organizações podem se tornar dependentes de soluções de normalização fechadas, específicas de vendor ou pagas, que são difíceis de substituir ou talvez não sejam mantidas com uma visão de longo prazo.

verified

Abordagem Open Standard do OSIRIS JSON

verified

Schema neutro de interchange JSON

Um formato vendor-neutral para trocar recursos de infraestrutura e topologia entre sistemas.
verified

Producers traduzem source exports em documentos OSIRIS

Parsers/translators/discovery agents mapeiam representações nativas para o schema OSIRIS.
verified

Consumers implementam um schema para muitas fontes

As ferramentas podem ler um único formato de documento bem definido em diferentes ambientes.
verified

Relacionamentos de topologia explícitos e de primeira classe

Conexões, dependências, containment e agrupamento são representados diretamente para que um snapshot possa descrever o que existe e como isso se relaciona em um ponto no tempo.
verified

Compatibilidade futura por meio da ignorância segura de campos desconhecidos

Consumers podem ignorar propriedades e extensões desconhecidas sem quebrar o processamento básico.
verified

Extensions são suportadas nativamente

Um mecanismo definido permite que vendors e usuários enriqueçam documentos sem quebrar a interoperabilidade.

Capacidades principais

schema Design unificado

Construído para ambientes heterogêneos de IT, com um caminho claro de extensão para OT e outros domínios à medida que a adoção cresce.

hub Modelo explícito de relacionamentos

Representação de primeira classe de conexões, dependências, containment e outros relacionamentos de topologia.

account_tree Constructos de agrupamento

Suporte para agrupamento lógico e físico que reflete estruturas organizacionais e arquitetônicas reais sem forçar uma taxonomia única.

dns Atribuição de provider

Os recursos preservam a rastreabilidade até seu source system/provider enquanto usam uma representação padronizada e vendor-neutral.

extension Extensibilidade

Um mecanismo definido para propriedades específicas de vendor e tipos de recurso customizados sem quebrar a compatibilidade.

verified_user Validação em três níveis

Validação estrutural (schema), semântica e de domínio, melhorando consistência e qualidade dos dados quando tooling de validação é aplicada.

Princípios de design

Formato de snapshot estático

OSIRIS JSON é um formato de interchange de snapshot estático. Ele captura o que existe e como isso se relaciona em um ponto no tempo. Não foi projetado como um sistema de monitoramento em tempo real, uma ferramenta de deployment ou um motor de Infrastructure-as-Code.

O que o OSIRIS JSON NÃO é

close Não é telemetria e monitoramento em tempo real

O OSIRIS JSON descreve topologia e estado de inventário, não métricas de séries temporais, logs ou dados de observabilidade. Projetos como Prometheus, Grafana, Zabbix e OpenTelemetry tratam das necessidades de telemetria.

close Não é deployment e orquestração de infraestrutura

O OSIRIS JSON não é uma linguagem de infrastructure-as-code nem uma especificação de deployment. Projetos como Terraform, CloudFormation ou TOSCA Oasis tratam de workflows de deployment.

close Não é gerenciamento de configuração

O OSIRIS JSON não define nem impõe configuração de estado desejado para recursos. Sistemas de gerenciamento de configuração como Ansible, Puppet, Chef e Salt atendem a esse propósito.

close Não é rastreamento de mudanças e histórico

O OSIRIS JSON representa um snapshot pontual no tempo. Rastrear mudanças ao longo do tempo é responsabilidade dos sistemas produtores e consumidores.

close Não é autenticação, autorização e políticas de acesso

O OSIRIS JSON pode carregar metadata que descreve fronteiras ou ownership, mas não define mecanismos ou políticas de controle de acesso.

close Informações de custo e billing

Billing detalhado e modelagem financeira estão fora do escopo do schema central, embora metadata relacionada a custo possa ser incluída por extensão.

Estrutura do documento

Documentos OSIRIS são objetos JSON. Na Specification v1.0.0, o objeto de nível superior é definido em torno de três campos: version, metadata e topology. Um campo opcional $schema pode ser incluído para referenciar a URI do schema.

[!NOTE] Este é um outline do schema OSIRIS JSON de nível superior. Os $defs foram omitidos aqui para melhorar a legibilidade no nível superior; consulte a URI canônica para ver o schema completo.

O schema central do OSIRIS JSON define:

{
  "$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

Entidades de infraestrutura unicamente identificáveis com propriedades e atribuição de provider.

topology.connections

Relacionamentos explícitos e direção entre recursos (network, dependência, containment, fluxo de dados etc.).

topology.groups

Coleções lógicas ou físicas que organizam recursos (por exemplo, VPC, subnet, rack, data center).

Validação e interoperabilidade