Skip to main content
Openlayer traces the Google Cloud Discovery Engine ConversationalSearchService through the openlayer Ruby gem. Once you trace a client, every answer_query call it makes is published to Openlayer with the query, the grounded answer, latency, and the retrieval steps Discovery Engine ran to produce that answer.
This tracer is Ruby only, and it is separate from the Dialogflow CX integration. Dialogflow CX reads agent logs from BigQuery; this tracer wraps a Discovery Engine SDK client in your own process.

​
Install and require

Install the Openlayer gem alongside the Google Discovery Engine client:
The tracer is not loaded by require "openlayer", so require it explicitly:
Prerequisites:
  • A project in Openlayer with monitoring mode enabled.
  • An Openlayer API key.
  • The inference pipeline ID of the data source you want to publish to.

​
Trace a ConversationalSearchService client

Pass your Google client to trace_client. It patches answer_query on that client instance, so you keep calling the Google SDK exactly as you did before:
Both calling styles work: pass a request object positionally, or pass serving_config and query as keyword arguments as above.
Tracing never breaks your application. If publishing a trace fails, the error is swallowed and answer_query still returns Google’s response. Set OPENLAYER_DEBUG in your environment to print those failures to stderr while you are setting the integration up.

​
Sessions, users, additional columns

trace_client takes the following keyword arguments: When you do not set session_id, Openlayer falls back to the session on the request, and when you do not set user_id, it falls back to user_pseudo_id on the response’s session. Either way, you can group and filter traces by session and user in Openlayer. To attach data to a single call rather than to every call, pass additional_columns to answer_query. The tracer strips that argument before forwarding the call, so Google never sees it:
On a key conflict, the per-call value wins over the static default. Keys that collide with a column the tracer computes itself are dropped: query, answer, latency_ms, timestamp, metadata, steps, context, session_id, and user_id.

​
What is captured

Each answer_query call becomes one row with the query, the answer text, the latency, and the request timestamp. The row carries a single top-level step named Conversational Search answer_query, recorded with provider Google and model google-discovery-engine. Underneath that step, Openlayer captures:
  • Retrieval steps: each execution step Discovery Engine reports becomes a retriever step, showing the rephrased query next to your original one and the documents it returned.
  • Grounding: citations, references, and related questions, when the answer includes them.
  • Context: the content of the answer’s references, so the context column is populated for retrieval-based tests.
  • Metadata: the serving config, the grounding score, the answer state, citation and reference counts, and any reasons the answer was skipped.
With calls flowing into Openlayer, you can create tests that run continuously on top of them.