Observability

Traces to your own collector, metrics for your own Prometheus, a ready-made Grafana dashboard, and an audit log kept apart from the diagnostic logs.

Rikoo reports nothing to its vendor. Everything below goes to infrastructure you run, and if you run none of it, nothing fails.

Traces

Each run is exported as an OpenTelemetry trace that follows the generative-AI semantic conventions: a span for the run, one per model call and one per tool call, with tokens, cost and latency as attributes. A run started by an HTTP request joins that request's trace, so one trace follows the work from the API server to the worker that executed it.

Traces leave over OTLP on HTTP (http/protobuf by default, or http/json). gRPC is not supported. The worker and the API server each have their own collector setting, and the API server exports nothing until you give it one.

.env

OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.internal:4318       # worker
OTEL_EXPORTER_OTLP_ENDPOINT_API=http://collector.internal:4318   # API server
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=false          # leave off unless you mean it

Conversation content is opt-in, media never

Spans carry the shape of a run, not its content. Prompts and answers are attached only when an operator turns on OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT (the older name OTEL_GENAI_CAPTURE_CONTENT is still read), and it is off by default. Tool arguments and results are never attached. A media file never enters a span: its reference does, never its bytes and never a signed URL.

Metrics

The worker serves Prometheus metrics at /metrics on its internal health port, 3100 by default, with nothing to turn on: run counts and durations, queue depth and wait, outbox lag, model call latency and token usage, failed provider attempts, and the Node.js process metrics. Scrape it with whatever you already run.

The API server serves its own on port 9464 (latency per route, rate-limit refusals, process metrics) once OTEL_METRICS_EXPORTER_API=prometheus is set. Neither port is published outside the deployment's network. Infrastructure lists the health and metrics endpoints of each service.

A ready-made dashboard

Building panels from an empty Grafana takes days before the first useful graph. Rikoo provides a Grafana dashboard on request: a single JSON file, built from the metrics the platform actually exposes instead of adapted from a generic template.

Import it into your Grafana, pick your datasource, and the panels fill in. It opens on two rows only: whether every component is up, and the few numbers that matter. Per-queue detail, model providers with token usage, and process metrics start collapsed, one click away.

Any store that speaks PromQL will do

The dashboard runs the same queries whatever is behind the datasource: Prometheus, VictoriaMetrics, Thanos and Mimir all work. The only prerequisite is that your store already scrapes the worker endpoint above.

On Kubernetes, the Helm chart can create a ServiceMonitor for the worker and one for the API server (both off by default), so a cluster running the Prometheus Operator discovers them. See Kubernetes (Helm).

The audit log

The audit log is separate from the diagnostic logs, and it is the one that carries weight. It records who did what: a version published, grants changed, a secret accessed, a member invited, an API key revoked. It is append-only, enforced by the database, and it does not depend on the retention of your logs. The Studio shows it on the Audit log screen, under Monitor. In the Community edition nothing purges it by age. The full audit Enterprise module adds filters, CSV export and a retention period, see Enterprise modules.