Skip to main content

Overview

Erst supports exporting distributed traces to external observability platforms via OpenTelemetry. This enables deep visibility into transaction debugging workflows, RPC calls, and simulator execution.

Quick start

1

Start Jaeger

Launch a local Jaeger instance using Docker Compose:
2

Enable tracing

Run Erst with tracing enabled:
3

View traces

Open Jaeger UI at http://localhost:16686 to view traces.

Configuration

CLI flags

  • --tracing: Enable OpenTelemetry tracing (default: false)
  • --otlp-url: OTLP exporter endpoint URL (default: http://localhost:4318)

Spans generated

The integration creates the following span hierarchy:

Span attributes

Each span includes relevant attributes for filtering and analysis:
  • transaction.hash: Transaction hash being debugged
  • network: Stellar network (testnet, mainnet, futurenet)
  • transaction.hash: Transaction hash
  • network: Stellar network
  • envelope.size_bytes: Size of transaction envelope in bytes
  • simulator.binary_path: Path to simulator binary
  • request.size_bytes: Size of simulation request in bytes
  • response.stdout_size: Size of simulator response in bytes

Supported platforms

The OTLP HTTP exporter is compatible with:
Open-source distributed tracing platform.
Observability platform with advanced query capabilities.
Full-stack monitoring and analytics platform.
Application performance monitoring and observability.
Any platform supporting the OpenTelemetry Protocol (OTLP) over HTTP.

Performance

When tracing is disabled (default), there is zero performance overhead. When enabled, the overhead is minimal due to:
  • Efficient span batching: Spans are batched before export
  • Asynchronous export: Trace export doesn’t block main execution
  • Minimal attribute collection: Only essential attributes are captured
For production deployments, consider using a sampling strategy to reduce trace volume while maintaining visibility into errors and slow requests.

Example usage

Debug with Jaeger

Debug with Honeycomb

Debug with custom OTLP endpoint

Testing graceful degradation

Telemetry is designed to fail silently: if the metrics collector is down, core SDK paths do not block and no errors are logged.

Unit tests

Run the telemetry tests (no collector required):
Confirm Init and tracer work with tracing on/off.
Confirm that with tracing enabled and an unreachable OTLP URL, Init still succeeds and spans can be created without blocking.

Run daemon with collector down

Build and start the daemon with tracing enabled but an OTLP URL that nothing is listening on. The daemon should start and keep running (no error, no hang):
You should see Starting ERST daemon on port 8080 and the process stays up.
Without graceful degradation, Init would fail and the daemon would exit with an error.

Run debug with collector down

Debug should complete even if the OTLP endpoint is unreachable:
Debug runs as normal; traces are dropped silently when the collector is down.

Advanced configuration

Environment variables

You can also configure OpenTelemetry using standard environment variables:

Custom trace sampling

For high-volume environments, implement custom sampling:

Trace analysis patterns

Identifying slow transactions

Query for traces with high duration:

Finding RPC errors

Filter for failed RPC calls:

Analyzing simulator performance

Group by simulator execution time:

Integration with logs

Combine traces with structured logs for complete observability:
This allows you to correlate log entries with trace spans using trace and span IDs.

Best practices

Follow OpenTelemetry semantic conventions for consistent attribute naming across services.
Enrich spans with domain-specific attributes like contract IDs, network types, and error codes.
Balance visibility with cost by sampling traces appropriately for your environment.
Ensure your OTLP collector is healthy and processing traces correctly.
Use trace IDs to correlate distributed traces with Prometheus metrics for comprehensive observability.
For production deployments, consider using a dedicated OpenTelemetry Collector to handle trace aggregation, filtering, and export to multiple backends.