OpenTelemetry Tracing: Monitor CMS Application Via Your Existing Observability Platform

Overview

Bloomreach Cloud customers can export distributed traces from their Bloomreach Experience Manager  application directly to their existing observability platform using the OpenTelemetry (OTLP) standard. This gives your engineering and SRE teams a detailed view of CMS request performance — including slow editorial operations, background jobs, and API calls — alongside the rest of your infrastructure in a single location.

This page describes the OpenTelemetry tracing for brXM hosted on the managed Bloomreach Cloud. If you run brXM outside Bloomreach Cloud, use the separate on-prem OpenTelemetry Integration guide.

OpenTelemetry tracing is an opt-in feature configured per Bloomreach Cloud stack and delivered as a managed platform service.

When to Use OpenTelemetry Tracing

Enable OpenTelemetry tracing if you:

• Already operate a centralized observability platform such as Dynatrace, Grafana Cloud, Honeycomb, New Relic, Splunk, or any other OTLP-compatible backend.

• Want to diagnose slow editorial operations or production incidents using the tools your team already uses, without needing to open a support ticket to get a trace.

• Want a unified view of Bloomreach CMS alongside the rest of your application stack.

How It Works

Bloomreach Cloud injects an OpenTelemetry Java auto-instrumentation agent into your CMS pod at startup. The agent automatically generates trace spans for CMS requests — no code changes or recompilation of your project are required.

Bloomreach Cloud OpenTelemetry forwards them to your configured OTLP endpoint over HTTPS.

In addition to standard Java auto-instrumentation (servlets, JDBC calls, JAX-RS endpoints, HTTP clients), the agent enriches each trace with CMS-specific context — see What Traces Include in the OpenTelemetry Integration documentation for the full breakdown.

This makes it possible to connect backend performance data directly to specific editorial workflows in your observability platform.

This is a push integration. Bloomreach Cloud forwards traces to your endpoint; your observability platform manages ingestion, storage, and visualization.

Supported Use Cases and Scope

Current support includes:

• Distributed traces from the CMS application on supported Bloomreach Cloud stacks.

• Delivery to any OTLP-compatible observability backend (for example, Dynatrace, Grafana Cloud, Honeycomb, New Relic, Splunk).

Log streaming is a separate feature. If you already have OpenTelemetry log streaming configured, the same credential setup covers traces with no changes required — unless your observability vendor uses a separate endpoint for traces.

Requirements

To use OpenTelemetry tracing, you need:

• A stack running in Bloomreach Cloud (PaaS).

• An OTLP ingest endpoint in your observability platform for traces (for example, a Dynatrace OTLP trace ingest URL or a Grafana Cloud Tempo endpoint).

• An access token or API key, and any required HTTP headers with permissions to ingest traces.

• A technical contact on your side (SRE or observability owner) to validate trace ingestion.

• Mission Control access to update the systemproperty app config for your environments.

Enabling OpenTelemetry Tracing

1. Request Enablement

OpenTelemetry tracing is enabled per stack and is not turned on by default. Enablement requires a support ticket — Bloomreach activates the stack-level capability and configures the outbound pipeline, after which you opt in per environment from Mission Control.

1. Open a ticket with Bloomreach Support.

2. Include:

   • Your stack name (for example, my-stack).

   • Your target observability platform (for example, Dynatrace, Grafana Cloud, Honeycomb).

   • A technical contact for observability on your side.

Support will confirm eligibility and coordinate activation.

2. Provide Your OTLP Endpoint and Credentials

Your observability owner needs to provide the connection details required by the OpenTelemetry Collector:

• OTLP endpoint URL for trace ingestion (for example, https://traces.example.com/otlp).

• Authentication — access token or API key with trace-ingest permissions, and any required HTTP headers (for example, Authorization, tenant IDs, or region headers).

Provide these values to Bloomreach via your support ticket.

If you already have log streaming configured: The same credential secret covers traces automatically when you use a single base endpoint. If your observability platform uses a separate endpoint for traces and logs, provide the traces-specific URL and headers alongside the existing log credentials.

3. Bloomreach Cloud Configuration

Once your endpoint and credentials are confirmed, Bloomreach will:

1. Store your OTLP credentials in the Bloomreach Cloud secrets store for your stack.

2. Configure the OpenTelemetry Collector to export traces to your endpoint.

3. Notify you when the stack-level configuration is ready and you can proceed with the per-environment opt-in.

4. Opt In Per Environment via Mission Control

Once Bloomreach has confirmed the stack-level configuration is ready, opt in each environment you want to enable:

1. Create a new property file (for example, otel-traces.properties) containing: brc.otel.traces.enabled=true

2. In Mission Control, attach this property file for the environment alongside your existing property files.

3. Redeploy the environment.

Note: To disable tracing for an environment later, remove this property and redeploy.

5. Verify Traces in Your Observability Platform

Once tracing is enabled:

1. Open your observability platform and navigate to the traces or distributed tracing section.

2. Filter by your service name. By default this is your environment hostname (brxm-<stack>). 

3. Trigger a simple CMS action (for example, opening a document or saving a draft) and confirm that:

   • New trace entries appear.

   • Spans include CMS-specific attributes such as the user and editorial action.

   • Timestamps and durations look correct.

Work with your observability team to create dashboards and alerts for slow requests, error rates, or specific editorial workflows.

Log-Trace Correlation

When tracing is active, the OpenTelemetry agent automatically injects trace_id and span_id into the Java logging MDC. If you also have log streaming enabled, you can correlate log entries with traces in your observability platform by surfacing these fields in your log output.

Bloomreach-provided log4j2 templates include the trace context pattern from brXM 17.1 onwards. If your project uses an older or custom log4j2.xml, add the fields manually, for example:

<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5p %t trace_id=%X{trace_id} span_id=%X{span_id} %m%n"/>

Once in place, log entries and trace spans for the same CMS request share the same trace_id, making it possible to jump from a log line to the corresponding trace and back.

Trace Attributes

Each trace span carries standard OpenTelemetry resource attributes (service name, host) plus a set of CMS-specific attributes — for example, the authenticated user and editorial action that triggered the request. See What Traces Include in the OpenTelemetry Integration documentation for the full, current list of attribute names.

Operational Responsibilities

Bloomreach Cloud

• Manages the OpenTelemetry Collector and the outbound trace pipeline for your stack.

• Injects and maintains the Java OTel agent in CMS pods.

• Ensures traces are exported to your configured endpoint in OTLP format.

You (Customer)

• Own and operate the observability platform (for example, Dynatrace, Grafana Cloud, Honeycomb).

• Provide and maintain the OTLP endpoint and credentials.

• Opt in and opt out per environment via Mission Control (brc.otel.traces.enabled=true), including triggering the required redeploy.

• Manage dashboards, alert rules, retention, and access control for trace data in your observability platform.