OpenDIMA — Discover · Ingest · Monitor · Automate

Subtitle: Infrastructure visibility, incident context, and automation.

Problem

Monitoring, logging, inventory, topology, and automation often live in separate tools. During incidents teams jump between screens and manually rebuild context.

A pod being slow might not be a “Kubernetes problem” at all—it can be CPU ready, datastore latency, storage queues, or the network path. Rebuilding that chain still depends heavily on team experience.

Goal

OpenDIMA aims to unify different infrastructure layers through service maps, metric/log correlation, incident timelines, and automation flows in one context.

Highlights

• Discovery
• Inventory
• Service map
• Metric/log correlation
• Incident timeline
• Alertmanager-style alert flows
• Automation / remediation

Architecture approach

OpenDIMA has four layers (DIMA):

1. Discover — Inventory and topology from gIMI and other collectors.
2. Ingest — Metrics, logs, traces, and events in an OpenTelemetry-friendly way.
3. Monitor — Rule engine and incident timeline (Alertmanager-style).
4. Automate — Policy-driven remediation and runbook automation.

OpenDIMA targets a shared incident context using topology from gIMI, storage state from SLTV, host metrics from dc(e)OS, and workload telemetry from Kubernetes.

Roadmap

OpenDIMA matures in later phases (5+). Priority is stabilizing gIMI’s telemetry backbone.

Repository

github.com/opensddc/opendima