The observability system tracks ALL data flowing into and out of the Gemini Live API, including session events, audio/video streams, tool calls, memory searches, transcriptions, and errors with context.
Quick Start
Minimal Configuration
Architecture Overview
System Architecture
The observability system uses a worker-based architecture for optimal performance:
Key Components
ObservabilityManager
Central event tracking and session management
ObservabilityWorker
Background thread for API communication (optional)
AudioAggregator
PCM audio buffering and flushing
TraceEvents
Strongly-typed event definitions
Configuration Reference
Default Values
The observability system uses sensible defaults when values are not specified:
Complete Configuration Interface
- ObservabilityConfig
- Development Config
Worker Mode Setup
Worker mode moves all API communication to a background thread for optimal performance.
Benefits
Zero UI Blocking
High-frequency events don’t affect UI
Automatic Batching
Reduces API calls by 10-50x
Built-in Retry
Failed requests with exponential backoff
Efficient Transfer
Zero-copy audio transfer
Configuration Example
CSP Requirements
Worker Mode CSP
Required CSP Headers
When using absolute URLs (recommended), all observability endpoints are derived from the baseUrl [[memory:5135225]].
Complete Production Example
API Endpoints
When using worker mode, the observability system automatically calls these endpoints:Trace Endpoint
Audio Flush Endpoint
Event Types Reference
Core Event Categories
Filtering Events
Advanced Features
High-Resolution Timestamps
Precise Event Ordering
Events use dual approaches for precise ordering:
- Microsecond timestamps via
performance.now() - Sequence numbers for guaranteed ordering
Session Statistics
Custom Event Tracking
Export Trace Data
Troubleshooting
Common Issues
- Worker Not Sending Events
- Events Not Batching
- Audio Not Flushing
- High Memory Usage
Troubleshooting Steps:
- Check
enabled: truein config - Verify
useWorker: trueis set - Ensure proper authentication token
- Check browser console for worker errors
Debugging Tips
Migration from Callback Mode
- Before (Manual)
- After (Worker)
Performance Considerations
Main Thread Impact
Without Worker: Each event blocks during JSON serializationWith Worker: Events sent via postMessage (microseconds)
Memory Usage
- Audio uses transferable objects (zero-copy)
- Events batched efficiently in worker
- Automatic cleanup on session end
Network Optimization
- Batching reduces API calls by 10-50x
- Automatic retry with exponential backoff
- Failed events don’t block new ones
Known Limitations
- Worker Initialization: Worker mode requires proper authentication setup and may fail silently if auth is misconfigured
- Audio Format: Audio is sent as PCM data, which requires server-side processing to convert to playable formats
- Memory Usage: High-frequency events can consume significant memory if not properly filtered
- Browser Compatibility: Worker mode uses data URLs which work in all modern browsers but may have issues in some extensions
Best Practices
1
Start Simple
Begin with basic observability enabled and add worker mode later
2
Filter Events
Always use
disableEventTypes to filter out noisy events in production3
Monitor Performance
Watch for memory usage and batch sizes in production
4
Test Worker Mode
Thoroughly test worker initialization in your deployment environment
Quick Start Checklist
Implementation Checklist
- Set
observability.enabled: true - Configure authentication with
baseUrl - Add event filtering for production
- Test worker mode if using high-frequency events
- Monitor console logs during development
- Verify API endpoints are receiving data