> For the complete documentation index, see [llms.txt](https://docs.rumi.systems/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rumi.systems/rumi-management/concepts/architecture.md).

# 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](/rumi-management/concepts/deployment-lifecycle.md), [Deployment Model](/rumi-management/concepts/deployment-model.md), [Command and Control](/rumi-management/concepts/command-and-control.md), [Scripting](/rumi-management/concepts/scripting.md), and [Telemetry Model](/rumi-management/concepts/telemetry-model.md) pages cover each in depth.

## Command, Control, and Scripting

<figure><img src="/files/gwOPuYD4ZWC4K3fSB1ND" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/5JpZERgUdJ9S8omMkuUx" alt=""><figcaption><p>Telemetry flow from container to dashboards.</p></figcaption></figure>

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rumi.systems/rumi-management/concepts/architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.