Telemetry and Monitoring

remoteEaze emits OpenTelemetry traces and metrics from the API and worker services.

What the app emits today

API

The API exports:

• traces
• metrics

It also applies:

• HTTP instrumentation
• Fastify instrumentation
• Prisma instrumentation
• Redis instrumentation
• Pino instrumentation

Worker

The worker exports:

• traces
• metrics

It also applies:

• Prisma instrumentation
• Redis instrumentation
• Pino instrumentation

Logs

Structured logs still exist, but they are not currently shipped through OTLP logs by the application runtime.

Treat logs and telemetry as two related but separate operator concerns:

• traces and metrics through OTLP
• logs through your normal container or host log pipeline

Telemetry envs

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SAMPLING_RATIO=1.0

Notes:

1. OTEL_EXPORTER_OTLP_ENDPOINT is used by both API and worker.
2. OTEL_SAMPLING_RATIO is currently applied by the API runtime.

Compatible backends

The app is vendor-neutral at the OTLP layer. Compatible options include:

• SigNoz
• Grafana Tempo
• New Relic
• other OTLP-compatible collectors or backends

Useful references:

• SigNoz self-hosted ingestion overview
• Grafana Tempo documentation

Current known setup

SigNoz is a known-compatible setup in the current development environment, but it is not mandatory.

Example endpoint values

Local collector

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SAMPLING_RATIO=1.0

SigNoz

OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-otel-collector:4317
OTEL_SAMPLING_RATIO=0.1

Grafana Tempo

OTEL_EXPORTER_OTLP_ENDPOINT=http://tempo:4317
OTEL_SAMPLING_RATIO=0.1

Suggested operator posture

For production:

1. start with traces and metrics first
2. decide sampling intentionally
3. aggregate structured logs separately
4. alert on worker failures, queue growth, and API availability outside the app itself

Next step

If anything still fails after deployment, use Troubleshooting.