Problem
Multiple components (API, Worker, NATS, Bento) generate telemetry. To simplify deployment, we need a single, consistent way to export this data. Currently, we want to avoid exposing a /metrics scraping endpoint to stay "push-native" for SigNoz compatibility.
Proposed Solution
Update the observability package to initialize a global OTLP gRPC exporter that handles both Traces and Metrics.
- Endpoint: Default to 127.0.0.1:4317 (The SigNoz/OTel Collector address).
- Protocol: Use gRPC for efficiency.
- Implementation: Ensure observability.InitProvider sets up both sdktrace.NewTracerProvider and sdkmetric.NewMeterProvider using the same OTLP client.
Alternatives Considered
Prometheus /metrics endpoint: Exposing stats on port 8080. Did not go through with this as it requires the collector to pull from the app, which is harder to manage in some container environments than a simple push.
Additional Context
The config.yaml should provide a single otel_addr that configures both pipelines simultaneously.
Problem
Multiple components (API, Worker, NATS, Bento) generate telemetry. To simplify deployment, we need a single, consistent way to export this data. Currently, we want to avoid exposing a /metrics scraping endpoint to stay "push-native" for SigNoz compatibility.
Proposed Solution
Update the observability package to initialize a global OTLP gRPC exporter that handles both Traces and Metrics.
Alternatives Considered
Prometheus /metrics endpoint: Exposing stats on port 8080. Did not go through with this as it requires the collector to pull from the app, which is harder to manage in some container environments than a simple push.
Additional Context
The config.yaml should provide a single otel_addr that configures both pipelines simultaneously.