Orbital

Querying

Observability

Orbital automates API integration, and provides rich data discovery, so you can spend less time plumbing, and more time building.

Observing queries

As queries are executed by Orbital, full call histories are captured and persisted

This gives rich debugging tools to understand exactly how a query was executed, which services were called and what they returned.

Every query that runs in a workspace - whether submitted from the Code editor, over the API, through a published endpoint or on a schedule - is recorded on the Activity page:

The Activity page lists each query run, with its status, duration and record count

The Activity page lists each query run, with its status, duration and record count

The Activity page lists each query run, with its status, duration and record count

Open a run to see its query details: the results it returned, and a Profiler tab that explains how the result was built. The profiler has four views:

  • Lineage - a graph showing which operations were called, and how their outputs fed each field of the result
  • Sequence - the list of calls made (with status and timing), as a sequence diagram
  • Stats - call counts, response times and response codes per operation
  • Trace - a timeline of the query’s execution
Lineage: the database table and two API calls that produced each field of the result

Lineage: the database table and two API calls that produced each field of the result

Lineage: the database table and two API calls that produced each field of the result
Sequence: every call Orbital made, with timings

Sequence: every call Orbital made, with timings

Sequence: every call Orbital made, with timings

The same Profiler tab is available in the Code editor immediately after running a query, so you don’t need to go via the Activity page while you’re writing one.

Configuring what’s captured

What Orbital records can be tuned - or turned off entirely - at three levels: server-wide defaults, per workspace, and per query.

When fully enabled, the following detail is captured and written to a database:

  • Requests and Responses sent to services - such as APIs and Databases
  • Metadata - such as URLs, response times, payload sizes, response codes and headers
  • Message payloads for streaming event sources such as message brokers
  • Variations of the above data to build query plan charts visualised in the Orbital UI

Server defaults are set with the orbital.history.* settings (previously vyne.analytics.*). Workspaces can override them from the Workspace settings page, and individual queries can carry a @QueryTelemetry annotation. See Query history settings for the full list of settings and how the levels interact.

Performance metrics - Prometheus

Orbital publishes metrics available for prometheus to collect.

If Orbital is connected to a Prometheus endpoint, performance data is made available on the Endpoints page.

Performance metrics

Performance metrics

Performance metrics

Streaming queries

The following metrics are published for persistent queries (both streaming and request / response queries)

  • Count of requests processed
  • Processing duration
  • Error Counts

Prometheus can then provide this data in histogram, providing min / max and averages

Configuring Prometheus

An example prometheus configuration is shown below

   - job_name: 'Orbital Metrics'     metrics_path: '/api/actuator/prometheus'     scrape_interval: 3s     static_configs:        #        172.17.0.1 is the ip address of localhost        #        from within docker        - targets: ['172.17.0.1:9022']          labels:             application: 'Orbital'