Skip to content

Rumable browser RUM

Rumable provides zero-code browser real user monitoring (RUM) in Beacon. It injects the bundled Web SDK into HTML responses through Nginx or IIS without changing application source code. Browsers send data directly to the RUM receiver; the CLI exits after deployment.

Rumable uses its own rumable command and TOML configuration. Download installation packages from Rumable Releases.

Requirements

  • Linux / Nginx: Bash, curl, sudo, and Nginx with http_sub_module enabled.
  • Windows / IIS: administrator access, a supported PowerShell environment, URL Rewrite, Static Content, and a started, dedicated application pool. One-command setup requires a 64-bit OS.
  • Create a Web application in Guance, obtain its applicationId, and choose a receiver as described in Web application access. Public OpenWay uses site and a browser clientToken; direct DataKit reporting uses datakitOrigin with the RUM input enabled. Choose one reporting method.

The endpoint must be reachable from visitors' browsers. Enter only the scheme, host, and optional port, without an API path. HTTPS websites should use HTTPS reporting endpoints. Go and Node.js are not required on the target server. See the compatibility guide for supported systems.

Set up a website

  1. Open the Rumable configuration page, which is in English.
  2. Enter the application ID, reporting method, endpoint, and browser Client Token if required. Choose Linux / Nginx or Windows / IIS and review sampling and privacy settings. By default, bundled SDK assets are served from your website's origin; Session Replay is optional.
  3. Confirm that the matching release manifest has loaded, save the TOML configuration, and copy the generated installation command. Base64 is encoding, not encryption; use a browser Client Token rather than a management API key.
  4. Run the command on the target Web server with the required administrator privileges. The installer downloads a fixed-version GitHub Release package, verifies its SHA256, and discovers the target website. A unique site is selected automatically; multiple candidates require an interactive terminal.

Setup changes server configuration and preserves recovery records. Nginx configuration may be reloaded. IIS operations recycle the dedicated pool and can lose in-memory sessions; shared pools are refused. Confirm the selected website and record the printed site ID, executable path, state directory, and backup location. Keep state outside the website root.

Verify the installation

Replace REPLACE_SITE_ID with the printed site ID and use the actual executable path and state directory:

read -r -p 'Full path to the installed rumable: ' rumable
sudo "$rumable" status --state-dir /var/lib/rumable --site REPLACE_SITE_ID
sudo "$rumable" probe --state-dir /var/lib/rumable --site REPLACE_SITE_ID

$rumable = Read-Host 'Full path to the installed rumable.exe'
$state = Join-Path $env:ProgramData 'Rumable'
$siteId = 'REPLACE_SITE_ID'
& $rumable status --state-dir $state --site $siteId
& $rumable probe --state-dir $state --site $siteId

Check for rumEnabled=true, empty drift, pendingTransaction=false, and a successful probe. Then:

  1. Open the website in a browser and generate page views, clicks, and API requests.
  2. Check the browser Console for SDK initialization errors and Network for successful /v1/write/rum requests.
  3. In Guance, open the Web application under RUM > Application List and confirm View, Resource, or Action records in the explorer.

A passing HTTP probe verifies injection and script availability. Browser execution and backend ingestion require separate verification.

Updates and recovery

Preserve the original site ID, target configuration, state directory, and old assets when updating. Replacing the CLI alone does not upgrade a deployed site's SDK; use the newer CLI to run setup or enable for the same site. Retest with a new browser session. See the user guide for manual targeting, disabling, rollback, and uninstalling.

Server-side telemetry

Rumable browser reporting uses the TOML RUM configuration. The OTEL_EXPORTER_OTLP_* variables in Common configuration configure server-side language agents, not the browser receiver. Browser RUM is not reported through the DataKit OpenTelemetry input.

Optional server-side OpenTelemetry integration needs separate setup; see the Rumable OTel guide. To correlate browser and server traces, see Connect APM and RUM.

Feedback

Is this page helpful?