Skip to main content
The Observability module (OtelModule) provides comprehensive monitoring through OpenTelemetry-compliant traces, metrics, and logs. Essential for debugging, performance analysis, and production monitoring.

Configuration

Configure the Observability module in config.yaml:
config.yaml

Configuration Options

Core Settings

boolean
default:"true"
Enable/disable observability module
string
default:"iii"
Service name for telemetry data
string
Service version identifier
string
Service namespace/environment (e.g., production, staging)

Trace Configuration

string
default:"memory"
Trace exporter type:
  • memory: Store in-memory (for development/debugging)
  • otlp: Export to OTLP collector
  • both: Both memory and OTLP
string
OTLP endpoint URL (required when exporter is otlp or both)
number
default:"1.0"
Basic sampling ratio (0.0 to 1.0)

Metrics Configuration

boolean
default:"true"
Enable metrics collection
string
default:"memory"
Metrics exporter: memory, otlp
number
default:"3600"
How long to keep metrics in memory (seconds)

Logs Configuration

boolean
default:"true"
Enable log collection
string
default:"memory"
Logs exporter: memory, otlp, both
number
default:"1.0"
Log sampling ratio (0.0 to 1.0)
boolean
default:"true"
Output logs to console

Logging Functions

Use built-in logging functions for structured logs:

Log Input Format

Traces

All function invocations are automatically traced. Access traces via functions:

List Traces

Get Trace Tree

Clear Traces

Metrics

Access collected metrics:

Built-in Metrics

  • iii.invocations.total - Total function invocations
  • iii.invocations.success - Successful invocations
  • iii.invocations.error - Failed invocations
  • iii.invocations.deferred - Deferred invocations
  • iii.workers.spawns - Worker spawn count
  • iii.workers.deaths - Worker death count
  • iii.workers.active - Active workers

Logs

Query stored logs:

Clear Logs

Log Triggers

React to log events:
index.ts

Advanced Sampling

Configure rule-based sampling:
config.yaml

Alerts

Configure metric-based alerts:
config.yaml
Query alert states:

Health Check

Check observability system health:

Distributed Tracing

Traces automatically propagate across:
  • HTTP calls
  • Queue messages
  • Stream events
  • State changes

Baggage

Propagate custom context across traces:

Exporting to OTLP Collector

Export to Jaeger, Zipkin, or other OTLP collectors:
config.yaml
Docker Compose example:
docker-compose.yml

Best Practices

  1. Production: Use exporter: otlp with sampling
  2. Development: Use exporter: memory for debugging
  3. Sampling: Adjust based on traffic (0.1 = 10% for high traffic)
  4. Alerts: Configure for critical metrics
  5. Log Triggers: Use for error notification
  6. Retention: Balance storage vs. retention needs

Performance Impact

  • Memory exporter: Low overhead, limited by max_spans
  • OTLP exporter: Network overhead, offloads storage
  • Sampling: Reduces overhead proportionally
  • Logs: Consider sampling for high-volume applications

Source Code Reference

  • Module: src/modules/observability/mod.rs:278
  • Logging functions: src/modules/observability/mod.rs:329
  • Traces API: src/modules/observability/mod.rs:591
  • Metrics API: src/modules/observability/mod.rs:769
  • Logs API: src/modules/observability/mod.rs:947