Skip to content

Observability and data sharing

LunarGate separates local metrics from optional cloud observability.

data_sharing also contains the remote_control toggle, which is related to the LunarGate Dashboard control plane on app.lunargate.ai rather than request-log export itself. Gateway identity for these integrations is configured once in top-level general.api_key.

Default behavior

By default, Dashboard data sharing and remote control are disabled. Prometheus metrics remain available locally, and ordinary client prompt and response bodies do not leave your infrastructure. The default-on release check is independent and sends only the gateway version and CPU architecture; see update_check.

Data-sharing modes

Metrics-only mode

Use this when you want traffic visibility without exporting prompt content.

data_sharing:
  enabled: true
  share_prompts: false
  share_responses: false

This sends request metrics and timing to the LunarGate Dashboard while keeping ordinary client prompt and response bodies private. To keep collector metrics local as well, set enabled: false and use the gateway's /metrics endpoint.

Debug mode

Use this when you want request inspection in the LunarGate Dashboard on app.lunargate.ai.

general:
  api_key: ${LUNARGATE_GATEWAY_API_KEY}
  backend_url: ${LUNARGATE_BACKEND_URL}

data_sharing:
  enabled: true
  share_prompts: true
  share_responses: true

Create that gateway API key in the Gateways section of app.lunargate.ai.

Prometheus endpoint

The gateway exposes metrics at:

GET /metrics

Health endpoint

Use the health check endpoint for container orchestration and smoke tests:

GET /health

What the LunarGate Dashboard receives

Depending on your config, the collector payload can include:

  • gateway version and identity, request ID, timestamp, client and upstream request types
  • duration, time to first/last token, provider, model, route, status, and bounded error class
  • token and prompt-cache usage, estimated cost, cache hit, fallback, retry, target-index, and circuit-breaker state
  • optional user/session identifiers and a fixed tag allowlist, including environment, team, app, client coordinates, resolved provider/model, inference controls, and a credential-stripped upstream base URL
  • optional prompt content when share_prompts: true
  • optional response content when share_responses: true

Only this caller-header allowlist is eligible to become collector tags: X-Environment, X-LunarGate-Request-Type, X-LunarGate-Provider, X-LunarGate-Model, X-LunarGate-Route, X-LunarGate-Complexity, X-LunarGate-Complexity-Score, X-LunarGate-Skill, X-Team, X-App, X-LunarGate-User, X-LunarGate-SessionID, X-LunarGate-Client-Lat, and X-LunarGate-Client-Lon.

The gateway may add or normalize these derived tags: client and upstream request type, configured gateway coordinates, resolved provider and model, streaming state, credential-stripped upstream base URL, and effective temperature, top_p, or Ollama top_k. Arbitrary client headers are not exported merely because a routing rule matches them.

The fixed metadata allowlist is not automatically anonymous. User, session, team, app, coordinates, and provider endpoint paths can be identifying or sensitive in some deployments. Do not place credentials, secrets, or unnecessary personal data in these fields.

Metrics-only events reduce failures to a bounded error class and do not include provider error text. When either prompt or response sharing enables request logs, those logs can also contain an upstream error code and message. Treat that error text as content-bearing because a provider may echo request fragments or other sensitive details in it.

Remote control

remote_control is the outbound control channel between a connected gateway and the LunarGate Dashboard on app.lunargate.ai.

Right now it is mainly used for the sandbox flow in the LunarGate Dashboard on app.lunargate.ai.

It is intentionally broader than that. The same channel is expected to become the foundation for automated A/B tests, controlled experiments, and other remote gateway-management features over time.

That means remote_control should be thought of separately from prompt/response sharing:

  • enabled is the master switch for all Dashboard connectivity
  • share_prompts and share_responses decide whether ordinary client request and response bodies are included in collector export
  • remote_control decides whether the gateway participates in the Dashboard control plane

For each sandbox execution, the Dashboard sends a complete request through the control channel and the gateway returns the complete response body, bounded to 16 MiB, plus a small safe header allowlist. This sandbox exchange is not controlled by share_prompts or share_responses. Enabling remote control therefore creates a content-sharing path even when collector export is metrics-only.

Remote control requires both data_sharing.enabled: true and data_sharing.remote_control: true, plus a valid gateway identity in general.api_key. If you want the gateway to stay entirely local from a control-plane perspective, keep remote_control: false.

Streaming nuance

When response sharing is enabled, the gateway can accumulate streamed chunks to reconstruct the final response object for downstream inspection.

For GET /v1/responses WebSocket mode, each response.create frame is still handled as a separate upstream request. If the client does not provide x-lunargate-sessionid, the gateway generates one automatically and reuses it across those requests for correlation.

Recommendation

Warning

Treat share_prompts, share_responses, and remote_control as separate privacy decisions. Keep them disabled unless your team needs their respective debugging or control-plane features and understands what data is leaving the environment.