OpenTelemetry Tracing: Monitor CMS Application Using Your Existing Observability Platform

Overview

Info: OpenTelemetry tracing is available in Bloomreach Content version 17.0 and later.

Bloomreach Cloud allows you to export distributed traces from your Bloomreach Content application to your existing observability platform using the OpenTelemetry Protocol (OTLP) standard. This integration provides engineering and SRE teams with detailed visibility into CMS request performance—including slow editorial operations, background jobs, and API calls—within your centralized observability tools.

This documentation covers OpenTelemetry tracing for Bloomreach Content deployed on managed Bloomreach Cloud. For on-premises deployments, refer to the OpenTelemetry Integration guide.

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

When to Use OpenTelemetry Tracing

Enable OpenTelemetry tracing if you:

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

  • Need to diagnose slow editorial operations or production incidents using your existing observability tools, without requesting traces from support.

  • Require a unified view of Bloomreach CMS performance alongside other application components.

How It Works

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

The OpenTelemetry agent sends traces to your configured OTLP endpoint over HTTPS.

In addition to standard Java auto-instrumentation (servlets, JDBC, JAX-RS, HTTP clients), the agent adds CMS-specific context to each trace. For a detailed list of included attributes, see OpenTelemetry Integration documentation.

This integration allows you to connect backend performance data directly to editorial workflows in your observability platform.

Traces are pushed from Bloomreach Cloud to your endpoint. Your observability platform handles 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 (such as Dynatrace, Grafana Cloud, Honeycomb, New Relic, Splunk).

Log streaming is a separate feature. If you already have OpenTelemetry log streaming configured, the same credentials apply to traces unless your observability platform uses a different endpoint for traces.

Requirements

To enable OpenTelemetry tracing, you need:

  • A stack running on Bloomreach Cloud (PaaS).

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

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

  • A technical contact (such as an SRE or observability owner) to validate trace ingestion.

  • Mission Control access to update the system property app configuration for your environments.

Enabling OpenTelemetry Tracing

1. Request Enablement

OpenTelemetry tracing is disabled by default and must be enabled per stack. Activation requires a support ticket. Bloomreach will enable the stack-level capability and configure the outbound pipeline. You then opt in per environment using Mission Control.

  1. Open a support ticket with Bloomreach.

  2. Provide the following information:

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

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

    • A technical contact for observability on your team

Bloomreach Support will confirm eligibility and coordinate activation.

2. Provide Your OTLP Endpoint and Credentials

Your observability owner must supply the connection details required by the OpenTelemetry Collector:

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

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

Submit these details through your support ticket.

If you already have log streaming configured and use a single base endpoint, the same credentials apply to traces. If your observability platform uses separate endpoints for traces and logs, provide the trace-specific URL and headers in addition to your existing log credentials.

3. Bloomreach Cloud Configuration

After verifying your endpoint and credentials, 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 complete and you can proceed with environment-level opt-in.

4. Opt In Per Environment via Mission Control

After stack-level configuration is complete, enable tracing for each environment as follows:

  1. Create a new property file (for example, otel-traces.properties) with the following content:

    brc.otel.traces.enabled=true

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

  3. Redeploy the environment.

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

5. Verify Traces in Your Observability Platform

After enabling tracing:

  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 (for example, brxm-<stack>).

  3. Perform a CMS action (such as opening a document or saving a draft) and confirm:

    • New trace entries appear.

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

    • Timestamps and durations are accurate.

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

Log-Trace Correlation

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

Bloomreach-provided log4j2 templates include the trace context pattern starting with Bloomreach Content 17.1. If you use an older or custom log4j2.xml, add the fields manually. For example:

<PatternLayout pattern="%d{dd.MM.yyyy HH:mm:ss} [%t] %-5p%notEmpty{ [trace_id=%X{trace_id} span_id=%X{span_id}]} [%C.%M():%L] %m%n"/>

With this configuration, log entries and trace spans for the same CMS request share the same trace_id, allowing you to navigate between logs and traces.

Trace Attributes

Each trace span includes standard OpenTelemetry resource attributes (such as service name and host) and CMS-specific attributes (such as the authenticated user and editorial action). For a complete list of attribute names, see OpenTelemetry Integration documentation.

Operational Responsibilities

Bloomreach Cloud:

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

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

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

Customer:

  • Operates and maintains the observability platform (such as Dynatrace, Grafana Cloud, Honeycomb).

  • Provides and manages the OTLP endpoint and credentials.

  • Opts in and out per environment via Mission Control (brc.otel.traces.enabled=true), including triggering redeployments as needed.

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

Share Feedback
Page: /deploy/bloomreach-cloud/monitor/opentelemetry-tracing-monitor-cms-application-via-your-existing-observability-platform
Section: Deploy
Category *
OpenTelemetry Tracing | Bloomreach Content Documentation