RUM Architecture

Kloudfuse RUM instruments the browser (or a native/hybrid client) directly, rather than relying on the systems that produce metrics, logs, and traces. This page explains how an event gets from a user’s browser into the RUM store, what registering an application does, and how the four RUM screens — Applications, Explorer, Custom Facets, and Performance — fit together.

How an event reaches the RUM store

The Kloudfuse RUM SDK (Web, Flutter, or React Native — see RUM Setup) runs inside the instrumented application and observes page navigations, user interactions, network calls, errors, and long tasks without any code changes beyond initialization. Each observation becomes a RUM event — a View, Action, Resource, Error, Long Task, or Vitals sample — stamped with the applicationId and clientToken from the registered application, plus session, device, browser, and geo context.

The SDK batches events and posts them over HTTPS to the cluster’s public RUM ingest endpoint (https://<kfuse-hostname>/ddrumproxy). The Kloudfuse ingester accepts the batch, routes each event type to its own Kafka topic (kf_rum_views_topic, kf_rum_actions_topic, kf_rum_resources_topic, kf_rum_longtasks_topic, kf_rum_errors_topic), and writes it to the RUM store, where the events for one Session are correlated by session ID. See RUM Instructions for the cluster-side configuration this requires — RUM is disabled by default because, unlike agent-collected telemetry, it needs a public ingress endpoint.

If log collection is enabled in the SDK, the browser also emits frontend log lines; the ingester applies RUM-specific parsing rules that tag them with the same application_id, session_id, and view.id facets as the RUM events, so a frontend log line and the view it occurred on can be cross-filtered in Logs.

Session replay is a separate, optional storage path

When session recording is enabled in the SDK, the browser additionally records a compressed stream of DOM mutations for the session and posts it to the kf_rum_session_replay_topic. Unlike the other event types, replay data is written to an object store (S3, Azure Blob, or GCS) rather than the RUM store, because recordings are large relative to a typical event. This is why session replay storage is configured separately, in RUM Session Replay Storage: AWS S3, RUM Session Replay Storage: Azure Blob, or RUM Session Replay Storage: Google GCS — RUM works without it, but the Replay tab has nothing to play back until a storage backend is configured.

Four screens over one data set

Applications

Register the frontend applications RUM tracks, and retrieve each one’s applicationId, clientToken, and generated SDK integration code. Every other screen scopes to one or more applications registered here.

Explorer

Search, filter, and visualize raw RUM events across all seven event types, in eight visualization forms, with drill-down into individual event detail and session replay.

Custom Facets

Index an application-specific usr. or context. attribute — set via the SDK’s custom attribute APIs — so the Explorer’s facet sidebar and query builder can filter and group by it.

Performance

Pre-aggregated Web Vitals and error summaries per application, so common performance questions don’t require building an Explorer query from scratch.

Because all four screens read the same underlying events, a custom facet created for an application immediately becomes filterable in both the Explorer and Performance screens for that application.

Correlation with APM and Logs

A RUM Resource event corresponds to one outbound HTTP request from the browser. If the backend that served that request is APM-instrumented and configured to read the same trace-propagation headers the RUM SDK injects, the resource and the backend trace share a trace_id and Kloudfuse links them — see Connect RUM and Traces. Combined with the frontend-log tagging described above, a single user session can be traced end-to-end: the page view, the action that triggered a request, the resource event for that request, the backend trace it produced, and any frontend log lines emitted along the way.

Next steps