Prometheus

Erato provides a Prometheus endpoint based on metrics.rs.

What it exposes

• Tokio runtime metrics via tokio-metrics + metrics-rs integration
• erato_info gauge with labels:
  • version
  • environment
  • service
  • deployment_version
  • pod_name
  • node_name

Configuration

Enable the integration in erato.toml:

[integrations.prometheus]
enabled = true
host = "127.0.0.1"
port = 3131

When enabled, Erato starts a dedicated listener and prints the metrics URL at startup:

http://<host>:<port>/metrics

integrations.prometheus.port must be different from http_port.

For all configuration fields, see Configuration Reference.

Exposed metrics

Erato currently exposes these application-specific metrics:

Info metrics

For background on _info metrics, see Prometheus Info Metrics .

• erato_info (gauge)
  • Always 1
  • Labels: version, environment, service, deployment_version, pod_name, node_name
• erato_chat_provider_info (gauge)
  • Always 1 per configured chat provider
  • Labels: chat_provider_id, provider_kind, model_name

Chat provider metrics

• erato_chat_provider_time_to_first_token_seconds (histogram)
  • Time from dispatching a chat generation request until the first streamed token, reported in seconds with millisecond precision
  • Labels: chat_provider_id
• erato_chat_provider_time_to_last_token_seconds (histogram)
  • Time from dispatching a chat generation request until the last streamed token, reported in seconds with millisecond precision
  • Labels: chat_provider_id
• erato_chat_provider_generation_errors_total (counter)
  • Total number of chat generation failures
  • Labels: chat_provider_id, error_type

MCP metrics

• erato_mcp_active_sessions (gauge)
  • Current number of active MCP sessions for each configured MCP server
  • Labels: server_id

Cache metrics

• erato_cache_max_size_bytes (gauge)
  • Maximum configured cache capacity in bytes
  • Labels: cache
• erato_cache_used_size_bytes (gauge)
  • Current weighted cache usage in bytes
  • Labels: cache
• erato_cache_fill_ratio (gauge)
  • Current cache utilization ratio in the range 0..1
  • Labels: cache
• erato_cache_entries (gauge)
  • Current number of entries in the cache
  • Labels: cache
• erato_cache_time_to_live_seconds (gauge)
  • Configured cache TTL in seconds, or 0 when disabled
  • Labels: cache
• erato_cache_time_to_idle_seconds (gauge)
  • Configured cache TTI in seconds, or 0 when disabled
  • Labels: cache

Database metrics

• erato_postgres_query_duration_seconds (histogram)
  • Execution time of Postgres queries, reported in seconds with millisecond precision
  • Labels: query_id, status
  • Known raw SQL statements use centrally defined query IDs
  • All other queries fall back to generated IDs in the form hash-<hash-based-on-query-with-placeholders>

Opt-in latency diagnostics

Set ERATO_LATENCY_DIAGNOSTICS=1 in addition to enabling Prometheus:

• erato_latency_stage_duration_seconds (histogram), label stage
  • Wall time for authentication, configuration, policy, generation dispatch/run, provider connection, SSE channel sends, final/shared-event persistence, and policy/generation lock waits and holds. Includes failed/cancelled operations.
  • policy.evaluation_queue_wait: waiting for the process-wide policy concurrency limit (four jobs), before freshness checks or snapshot cloning.
  • policy.blocking_dispatch_wait: snapshot ready to blocking job start.
  • policy.engine_read_hold covers only snapshot cloning; policy.evaluate measures input preparation and queries on the blocking pool.
• erato_latency_stage_in_flight (gauge), label stage
  • Operations currently in each stage. generation.dispatch_wait counts dispatched tasks not yet polled; this is not a global executor queue length. policy.evaluation_queue_wait counts callers waiting for policy capacity, and policy.blocking_dispatch_wait counts submitted jobs not yet started.
• erato_runtime_timer_lateness_seconds (histogram)
  • Lateness of a 250 ms Tokio timer, with missed ticks skipped.

Stage durations include scheduling and I/O waits, not just CPU execution. Diagnostic stages also produce latency.stage trace spans and debug timing events. SQLx pool acquisition logs (sqlx::pool::acquire=debug) distinguish connection acquisition from the query execution histogram, which excludes pool acquisition. Recording these diagnostics has overhead; compare with an uninstrumented release build at the same concurrency.

Erato also exposes Tokio runtime metrics via tokio-metrics, but those are produced by the upstream integration rather than defined directly by Erato, so they are not enumerated here.