Skip to content
Obscenter

Docs Automation & analysis

Business logic, request samples and the data store

See the business values your applications handle: OpenTelemetry attributes from spans, sampled request and response bodies, and a searchable data store.

The Business logic group in the Launchpad holds three pages. Together they are about the values your applications work with, rather than the machinery around them: order totals, plan names, cart sizes. The group needs the Business logic capability, which is off by default for members, because it shows request contents from the whole install.

Business logic

This page has two sections:

  • Declared by the applications: the OpenTelemetry attributes with a dotted name, such as checkout.total, that your services put on their own spans.
  • Captured from the traffic: the fields found in sampled request and response bodies.

For each name the page shows its readings. When every value is a number it shows the range and the average. Otherwise it shows the most common values. Each name lists the traces it was measured in. Filter by service. Names nested inside arrays are hidden by default, and a chip says how many.

To declare a value, set it as an attribute on a span your code creates:

import { trace } from '@opentelemetry/api';
const tracer = trace.getTracer('shop');

tracer.startActiveSpan('checkout', (span) => {
  span.setAttribute('checkout.total', order.total);
  // … the work …
  span.end();
});

In a Node.js service the agent picks this up in the process, with no exporter. See Without an exporter.

Browser: request samples

The Browser page controls body sampling and lists what was captured, per service and endpoint. The agent inside an instrumented Node.js service keeps a few request and response bodies per endpoint: two per route, eight per report at most. It keeps JSON documents, form posts and the rows a soft navigation carries. Static assets and prefetches are never sampled. The collector keeps the last 20 samples per endpoint, for two days.

  • Sampling is on for every instrumented service unless you switch it off. A switch per service and a switch per endpoint turn it off where you choose. For example, you can turn off an endpoint that carries card details while the rest of the service stays sampled.
  • body size: 16 KB, 100 KB (the default), 256 KB, 512 KB or 1 MB per body.
  • mask secret-looking fields: off by default. When on, any field whose name contains a word such as pass, secret, token, auth, cookie, session, card, cvv, iban, ssn, otp, api key or credential is stored as [redacted]. Field names are kept.
Request bodies can hold personal data. Before you rely on this page, decide which endpoints should not be sampled at all, and consider switching the masking on.

A service whose agent is too old to sample shows a warning. Sampling starts when it next restarts with the current agent.

Data store

The Data store page lists every captured sample across all services, newest first. Each sample carries its service, method, endpoint, status and trace. Filter by service, method, endpoint, status class (ok, client error, server error), or a word found in the request, the response or the endpoint. The counts per service, method and endpoint follow the filter. Everything here is a sample, kept for two days. It is a way to see what a real request looked like, not a record of all traffic.

Through the API

The same data is readable with an API key: /api/business, /api/samples and /api/store. See The REST API.