Skip to content

CTA Metrics#

Warning

Note that CTA Metrics is in its early stages and considered experimental. Published metrics and their attributes are likely to change.

CTA can publish metrics in the OTLP format. This feature is disabled by default and has to be explicitly configured. This page describes which metrics CTA can publish, the prerequisites, and how to enable metrics.

Info

To see which metrics are published by CTA, see Supported Metrics.

Prerequisites#

In order to ingest OTLP metrics, an endpoint must be available for CTA to push metrics to. In practice, this means you will need to deploy your own OpenTelemetry Collector.

The collector can then export metrics to a time-series database such as Prometheus or Grafana Mimir, where they can be visualized in Grafana or other compatible dashboards.

Setting up and managing this infrastructure is outside the scope of this documentation. Refer to the respective documentation for installation and configuration guidance:

Enabling Metrics#

CTA services expose metrics publishing as a configurable option. To enable OTLP metrics, set the appropriate configuration parameter in each service’s configuration file.

At the time of writing, cta-taped and cta-frontend use different configuration formats, and must be configured separately.

cta-taped#

To enable OTLP metrics publishing in cta-taped, set the following options in its configuration file:

# Telemetry is an experimental feature and must be explicitly enabled before it can be used.
# Note that this flag alone is not sufficient to start producing telemetry.
experimental telemetryEnabled true

# As cta-taped forks, this option gives it a deterministic `service.instance.id`.
# If this option is disabled, a new unique `service.instance.id` will be generated each time a new process starts
# This will result in high cardinality metrics, due to drive sessions starting new processes.
telemetry retainInstanceIdOnRestart true

# Metrics backend to use. Possible options are NOOP, OTLP_HTTP, OTLP_GRPC, STDOUT, FILE
# We have tested OTLP_HTTP, but in theory OTLP_GRPC should work in the same way
telemetry metricsBackend OTLP_HTTP

# Amount of time in milliseconds between exports
telemetry metricsExportInterval 15000

# Timeout for a single export
telemetry metricsExportTimeout 3000

# Service location of the OTLP collector in case the OTLP backend is used
telemetry metricsExportOtlpEndpoint endpoint:port

# File location containing "username:password" (not base64 encoded) to set up basic auth for push metrics over HTTP
# Adds the header "authorization: Basic <base64(username:password)>"
# If your collector requires authorization, add this option.
telemetry metricsExportOtlpBasicAuthFile /path/to/base64/encoded/username/password

After updating the configuration, restart cta-taped for the changes to take effect.

cta-frontend#

cta-frontend supports similar metrics publishing, but its configuration names are slightly different:

# Telemetry is an experimental feature and must be explicitly enabled before it can be used.
# Note that this flag alone is not sufficient to start producing telemetry.
cta.experimental.telemetry.enabled true

# Similar to above, this option can be used to control cardinality.
# However, the cta-frontend should not restart frequently, so this option can be left off if desired.
cta.telemetry.retain_instance_id_on_restart false

# Metrics backend to use. Possible options are NOOP, OTLP_HTTP, OTLP_GRPC, STDOUT, FILE
# We have tested OTLP_HTTP, but in theory OTLP_GRPC should work in the same way
cta.telemetry.metrics.backend OTLP_HTTP

# Amount of time in milliseconds between exports
cta.telemetry.metrics.export.interval 15000

# Timeout for a single export
cta.telemetry.metrics.export.timeout 3000

# Service location of the OTLP collector in case the OTLP backend is used
cta.telemetry.metrics.export.otlp.endpoint endpoint:port

# File location containing "username:password" (not base64 encoded) to set up basic auth for push metrics over HTTP
# Adds the header "authorization: Basic <base64(username:password)>"
# If your collector requires authorization, add this option.
cta.telemetry.metrics.export.otlp.basic_auth_file /path/to/base64/encoded/username/password

Restart cta-frontend after applying the changes. If metrics are correctly enabled, you should begin to see metric data arriving at your collector within a few seconds.

Verifying Metrics Collection#

Once metrics publishing is enabled and the OpenTelemetry Collector is receiving data:

  1. Confirm that CTA is not showing any error logs related to OpenTelemetry.
  2. Confirm that your collector logs show incoming OTLP data from CTA services.
  3. Query the metrics backend (e.g., Prometheus) for metrics that CTA publishes.
  4. Use Grafana to visualize the metrics.

A minimal verification query in Prometheus might look like:

db_client_operation_duration_count

Recommendations#

Telemetry data is primarily useful for monitoring system health, usage and saturation. It is typically not intended for long-term archival or audit purposes.

  • Retention: Keep metrics retention short (for example, 1-2 weeks). This minimizes storage overhead while retaining enough history for operational analysis.
  • Resource attributes: Many queries and dashboards rely on resource context (such as service.name, host.name, or process.title). Configure your metrics backend or OpenTelemetry Collector to attach resource attributes to every metric, or enable automatic resource-to-metric label conversion if your backend supports it.