Skip to main content
The bronto CLI can trace its own runs with OpenTelemetry. This is off by default, and nothing is sent anywhere unless you configure an exporter with the standard OTEL_* environment variables. The only setting specific to the CLI is BRONTO_TELEMETRY_CAPTURE, which controls how much of the command line is recorded.

​
Turn it on

Point bronto at an OTLP endpoint:
Each run produces:
  • A root span named after the command, such as bronto search or bronto monitors list. It records bronto.command (the same command path), process.executable.name, process.pid and process.exit.code, and on failure error.type, which holds the error code (for example auth_invalid_key). It also records the flags and arguments, sanitized as described in What’s recorded.
  • A client span for each HTTP request to the Bronto API, retries included, as children of the root span. Each is named after the method and the API route, such as GET /monitors/{monitorId}, and records the route as url.template. A path that doesn’t match a known route, such as one passed to bronto api, gets just the method (GET), so IDs never end up in span names.
These names follow the OpenTelemetry HTTP span conventions. The root span departs from the CLI conventions, which name it after the executable alone (bronto). That would give every command the same span name, so trace lists couldn’t tell bronto search from bronto monitors list. The set of commands is fixed, so the names stay low-cardinality. Spans are flushed when the command exits. If the backend can’t be reached, the exit is delayed by at most 3 seconds, and the command’s exit code and output don’t change. To send the CLI’s traces to Bronto itself, use your region’s ingestion endpoint and an ingestion API key. See Send Traces to Bronto:

​
Continue a trace

When TRACEPARENT is set, the root span of bronto becomes a child of that trace. TRACESTATE and BAGGAGE are read too. This is the environment-variable carrier convention that CI integrations and tools like otel-cli use, so a bronto call inside a traced pipeline step shows up inside that step’s trace:
The trace context is passed on even when export is off. With TRACEPARENT set, requests to the Bronto API carry a W3C traceparent header, and exec plugins get TRACEPARENT, TRACESTATE and BAGGAGE in their environment. When bronto is exporting, those values point at its own spans, so a plugin’s spans nest under the bronto command that ran it.

​
Settings

bronto reads these: The OTLP exporters also honor the rest of the standard exporter settings, such as OTEL_EXPORTER_OTLP_HEADERS, OTEL_EXPORTER_OTLP_TIMEOUT, OTEL_EXPORTER_OTLP_COMPRESSION and OTEL_EXPORTER_OTLP_CERTIFICATE, plus their _TRACES_ variants.

​
What’s recorded

Command lines can hold queries, payloads and keys, so the root span records them only in sanitized form. BRONTO_TELEMETRY_CAPTURE picks the level:
  • default: bronto.flags lists the flags that were set, by name. Values go into bronto.flag.<name> and positional arguments into bronto.args as follows:
  • none: only the command path, not even flag names.
  • all: every value as given, plus the whole argument list as process.command_args. Use it to debug in an environment you control: queries, payloads and messages are exported verbatim.
At every level, including all, the value of --api-key is never recorded. An unrecognized value records nothing, like none, and is reported when OTEL_LOG_LEVEL is set. For exec plugins, whose flags bronto doesn’t know, the arguments are recorded only with all. HTTP client spans record the request URL as url.full, with every query-string value replaced by REDACTED, at every level. Only traces are exported. The bronto CLI doesn’t emit OpenTelemetry metrics or logs.