Overview

Alokai Cloud integrates with OpenTelemetry (OTel) — the industry-standard observability framework — to give you deep visibility into what your storefront is actually doing at runtime.

What it gives you

When customers browse your store, hundreds of things happen behind the scenes: pages are rendered, APIs are called, databases are queried, caches are checked. Any one of those steps can be slow, fail silently, or behave differently than expected — and without instrumentation, you have no way to know which one is responsible.

OpenTelemetry solves this by letting your application report its own activity as it happens. Once instrumented, you gain:

End-to-end request visibility. For any request — a product page load, a cart update, a checkout — you can see exactly what happened: which functions ran, in what order, how long each one took, and whether any failed. This is invaluable when you need to find why checkout is slow for users in a specific region, or why a particular product page occasionally returns an error.

Service-level metrics. Throughput, error rate, and latency percentiles for every route and service — continuously updated, ready to use for dashboards and alerts. These metrics tell you when something is degrading before customers start complaining.

Cross-service tracing. If your storefront calls a middleware service, which in turn calls a third-party commerce API, OTel follows the request through all of them. You see the full picture, not just fragments.

Confidence during deployments. By comparing trace and metric data before and after a release, you can verify that a new version is performing as expected — or catch a regression early.

All of this data is forwarded to your observability backend (Datadog, New Relic, or Dynatrace), where you can explore it using the tools and dashboards you already have.

How it works

OpenTelemetry (OTel) is a vendor-neutral observability framework that standardises how applications produce and export telemetry data. Alokai Cloud has a built-in OTel Collector running inside your instance that receives application traces and metrics from your storefront and middleware, and forwards them to your observability backend.

Your application
      │
      │  OTLP  (gRPC :4317  or  HTTP :4318)
      ▼
Alokai OTel Collector  ──►  Datadog / New Relic / Dynatrace

Your application sends telemetry to the local collector via the standard OTLP protocol. The collector is responsible for batching, retry logic, and forwarding to your configured backend. This means:

• Your application code is decoupled from any specific vendor.
• Switching backends requires only a Console change — no code changes, no redeployment.
• The collector handles back-pressure; a slow or temporarily unavailable backend does not affect your application.

The backend and its credentials are configured from the Console. The only thing your application needs to know is the collector address: otel-collector (available as a DNS name within your instance).

Signals

Alokai Cloud supports two OTel signal types:

Traces — A trace follows a single request end-to-end across services. It is composed of spans, where each span represents one unit of work: an HTTP handler, a database query, an external API call. Traces are the primary tool for diagnosing latency and errors in distributed systems.

Metrics — Aggregated numeric measurements over time: request rate, error rate, latency percentiles, cache hit ratio. Metrics are cheap to store and ideal for dashboards, alerting, and capacity planning.

Supported backends

Datadog APM

When Datadog is configured, traces appear in APM → Services and Distributed Tracing. Datadog also derives APM metrics (request throughput, error rate, latency percentiles) directly from your trace data, so you get service-level dashboards and alerting without separately emitting those metrics.

For full Unified Service Tagging — which correlates APM traces with infrastructure metrics and dashboards — your application must emit three resource attributes:

These are set via OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables on your application.

Sampling

High-traffic storefronts generate a large volume of traces. Sampling reduces the volume forwarded to your backend while preserving statistical accuracy and ensuring errors and slow requests are always captured.

The recommended strategy is head-based ratio sampling, configured via environment variables on your application:

OTEL_TRACES_SAMPLER=parentbased_traceidratio
OTEL_TRACES_SAMPLER_ARG=0.1   # sample 10% of traces

parentbased_traceidratio respects the sampling decision made by an upstream caller — if a trace is marked as sampled upstream, all downstream spans for that trace are also sampled, keeping traces complete and avoiding orphaned spans.

Start at 10–20% for production and tune based on ingestion cost and coverage needs. parentbased_always_on is appropriate for low-traffic environments or during initial setup.

Protocol

The collector accepts OTLP on two transports:

HTTP/protobuf is recommended. Setting OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318 is sufficient — the SDK appends the correct path per signal automatically (/v1/traces, /v1/metrics).

Next steps

• Instrumenting your application — SDK setup, auto-instrumentation, custom spans and metrics