Unified Observability Architecture: Profiling, Logging, and Telemetry
Status: Architecture Extension
Date: 2025-10-31
Author: FEAGI Architecture Team
Executive Summary
This document extends the feagi-observability crate proposal to include profiling and telemetry alongside logging, creating a unified observability infrastructure. Profiling, logging, and telemetry share common context, correlation IDs, and initialization patterns, making them natural partners in a single crate.
Why Unified Infrastructure?
1. Shared Context and Correlation
Problem: Logs, traces, metrics, and profiles are often disconnected, making it hard to correlate.
Solution: Unified correlation IDs propagate across all observability systems:
// Same correlation ID used for:
// - Logs: "request_id=abc123"
// - Traces: Span with trace_id="abc123"
// - Metrics: Label request_id="abc123"
// - Profiles: Profile metadata includes request_id="abc123"
Benefit: Can trace a request from log → trace → metric → profile seamlessly.
2. Unified Initialization
Problem: Multiple initialization calls scattered across codebase.
Solution: Single initialization function:
use feagi_observability::init_observability;
init_observability(&ObservabilityConfig {
logging: LoggingConfig { level: "info", format: LogFormat::Json },
telemetry: TelemetryConfig {
metrics_enabled: true,
tracing_enabled: true,
tracing_endpoint: Some("http://jaeger:4317".to_string()),
},
profiling: ProfilingConfig {
cpu_profiling: true,
memory_profiling: false,
output_dir: "./profiles".into(),
},
})?;
Benefit: One place to configure all observability, ensures consistency.
3. Shared Data Collection
Problem: Each system (logging, metrics, tracing) collects similar data separately.
Solution: Unified collection layer:
// Single instrumentation point collects:
// - Logs (structured)
// - Metrics (counters/histograms)
// - Traces (spans)
// - Profiling samples (if enabled)
#[instrument]
pub async fn execute_burst() {
// Automatically creates:
// - Log entry
// - Trace span
// - Metrics counter
// - Profiling sample (if enabled)
}
Benefit: Less overhead, consistent data collection.
4. Consistent Patterns
Problem: Different APIs for logging vs metrics vs tracing.
Solution: Unified macros:
// Same pattern for all observability
feagi_observability::burst_info!(
burst_id = 42,
neurons_fired = 1000,
// Automatically creates:
// - Log entry
// - Metric update
// - Trace span
// - Profiling sample (if enabled)
);
Benefit: Developers learn one API, not three.
Architecture: Unified Observability
┌─────────────────────────────────────────────────────────────┐
│ feagi-observability │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Context Layer (Correlation IDs, Request Context) │ │
│ │ - Trace ID propagation │ │
│ │ - Span context │ │
│ │ - Request correlation │ │
│ └──────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Instrumentation Layer (Unified Collection) │ │