Skip to main content

System monitoring

The System monitoring feature in RemotiveStudio embeds system monitoring dashboards for all entities in your brokers, mocks, behavioral models—letting you inspect throughput, health, and other key metrics without leaving Studio.

Prerequisites​

System monitoring is only available when the running topology was generated with metrics enabled. See RemotiveTopology → System monitoring for how to enable it.

If the topology is running but was generated without metrics, Studio shows a "System monitoring is not enabled" guidance page with the command needed to regenerate the topology with metrics.

Open a dashboard​

Open the Topology section in the left sidebar and expand the System monitoring entry. Studio lists the dashboards it discovered on the running topology—click any of them to open it as a tab in the main view. Multiple dashboards can be open at the same time as separate tabs.

[Image] System monitoring sidebar and an embedded dashboard in Studio

Tabs are persisted across reloads, and the tab title reflects the dashboard's current name.

Viewing a dashboard​

Dashboards are embedded directly in Studio and follow the light/dark theme. You can interact with them just like a regular monitoring dashboard—change the data source and time range, filter by container, expand panels, and drill into individual metrics.

note

Dashboards are served by the monitoring services running inside your topology stack. If you stop the topology, the System monitoring tab fails to load until the topology is restarted.

Available dashboards​

The generated topology ships with the following dashboards:

  • Containers—Per-container CPU, memory, network, and disk usage for every service in the topology. Useful for spotting which container is consuming the most resources.
  • gRPC Performance—Request rates, error ratios, and latency percentiles for the gRPC API exposed by each RemotiveBroker. Useful for diagnosing slow or failing client calls.
  • Namespace Internals—Per-namespace message queue depths inside the RemotiveBroker. Useful for detecting backpressure or stalled signal processing on a specific namespace.
  • Python Models & Mocks—Behavioral-model metrics: input-handler latency percentiles and frames-received rates. Useful for tracking the health of Python ECU simulations and mocks.
  • VM Health—Internal health of the broker runtime: memory breakdown, process and port counts, and scheduler run queues. Useful for diagnosing memory or scheduling problems in the broker itself.