Architecture
Rumi Management has two architectural flows — one for command, control, and scripting, and one for telemetry. This page covers both in summary; the Deployment Lifecycle, Deployment Model, Command and Control, Scripting, and Telemetry Model pages cover each in depth.
Command, Control, and Scripting
Ad-hoc command-and-control (start, stop, thread dump, trace level changes, app-specific commands, …) and scripted deployments follow the same path:
Rumi Admin → Rumi Agent (REST) → Embedded Controller → Target Container
Inside each container, incoming commands are dispatched to:
Application logic — app-specific commands (e.g., order cancel, cache refresh).
Rumi Engine — engine commands (e.g., change trace level, stop).
JVM — JVM commands (e.g., thread dump, kill).
Host — host commands (e.g., clear memory cache).
Because both flows terminate at the Agent's REST API, any REST client — the Admin UI, a CI/CD pipeline, or a custom script — can issue commands or run deployment scripts.
Telemetry
Rumi Management observes running containers through three kinds of signals:
Telemetry — aggregated metrics from the container (JVM, host, engine, and application-specific counters, gauges, series, and records), carried in periodic heartbeats. Telemetry is forwarded through the Agent to a time-series database for dashboarding and alerting.
Lifecycle events — as-they-occur notifications of container, service, and bus-connection state changes. Lifecycle events are consumed by the Controller to build and maintain the deployment model; they are not re-emitted as a separate event stream.
Alerts — as-they-occur notifications of noteworthy conditions. Planned as an additional signal; not yet supported.
Each Rumi container runs a telemetry collector that aggregates:
Application-specific metrics — counters, gauges, series, and records from application logic.
Engine metrics — queue depths, latencies, and internal statistics from the Rumi Engine.
JVM metrics — heap, JIT, and runtime metrics.
Host metrics — disk and CPU metrics.
The aggregated telemetry is emitted from the container in each heartbeat. Heartbeats travel to the Rumi Agent over a direct TCP session or a pub-sub bus, depending on the Agent's telemetry mode. The Agent writes the telemetry to a time-series database (InfluxDB), and Rumi Monitor visualizes the stored data through dashboards.
Last updated