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
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:debug_transaction
debug_transaction
transaction.hash: Transaction hash being debuggednetwork: Stellar network (testnet, mainnet, futurenet)
fetch_transaction
fetch_transaction
transaction.hash: Transaction hashnetwork: Stellar networkenvelope.size_bytes: Size of transaction envelope in bytes
simulate_transaction
simulate_transaction
simulator.binary_path: Path to simulator binaryrequest.size_bytes: Size of simulation request in bytesresponse.stdout_size: Size of simulator response in bytes
Supported platforms
The OTLP HTTP exporter is compatible with:Jaeger
Jaeger
Open-source distributed tracing platform.
Honeycomb
Honeycomb
Observability platform with advanced query capabilities.
Datadog
Datadog
Full-stack monitoring and analytics platform.
New Relic
New Relic
Application performance monitoring and observability.
Any OTLP-compatible platform
Any OTLP-compatible platform
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):TestInit and TestGetTracer
TestInit and TestGetTracer
Confirm Init and tracer work with tracing on/off.
TestInit_UnreachableCollector
TestInit_UnreachableCollector
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):Starting ERST daemon on port 8080 and the process stays up.
Run debug with collector down
Debug should complete even if the OTLP endpoint is unreachable: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:Best practices
Use semantic conventions
Use semantic conventions
Follow OpenTelemetry semantic conventions for consistent attribute naming across services.
Add custom attributes
Add custom attributes
Enrich spans with domain-specific attributes like contract IDs, network types, and error codes.
Set appropriate sampling
Set appropriate sampling
Balance visibility with cost by sampling traces appropriately for your environment.
Monitor collector health
Monitor collector health
Ensure your OTLP collector is healthy and processing traces correctly.
Correlate with metrics
Correlate with metrics
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.