Tenant Telemetry service

TechPreview

The Tenant Telemetry service exposes OpenStack Ceilometer metrics to tenant users so that they can drive autoscaling decisions through OpenStack Heat. The service is designed around a single supported mode of operation, autoscaling, and, thus, its data retention is intentionally short: Prometheus on the metric-storage side keeps at most 1 GB or 2 hours of data, whichever limit is reached first.

Starting with the OpenStack Gazpacho release, MOSK replaces the deprecated and unsupported Gnocchi time series database with Prometheus as the metrics storage backend for Tenant Telemetry.

Warning

Moving to the new Tenant Telemetry stack is a breaking change. Read about data and user impact in the Migrate Tenant Telemetry from Gnocchi and plan the migration accordingly.

Architecture overview

The Tenant Telemetry service consists of the following components, each with a distinct role in the metrics collection and alarming pipeline:

Aetos

Enforces Keystone authorization and tenant separation in front of the dedicated Prometheus instance, exposing only the subset of the Prometheus API needed for tenant-facing queries.

Introduced in MOSK with the OpenStack Gazpacho release.

Aodh

Enables end-users to create alarms based on metric values from the time series database. Alarms can trigger various web hooks, including generic hooks, OpenStack Heat autoscaling endpoints, and OpenStack Swift objects, when alarm conditions are met.

Ceilometer

Collects metrics from the OpenStack cluster and forwards them to the time series database. Compute-related metrics are sourced from libvirt, the remaining metrics are pulled from OpenStack service APIs. Ceilometer exposes no user-facing API of its own.

Prometheus

Stores the tenant-facing telemetry time series being an industry-standard, cloud-native, CNCF-approved database. MOSK deploys a Prometheus instance dedicated to Tenant Telemetry, kept separate from the StackLight instance, so that tenant workloads and cluster monitoring do not share retention, scrape, or capacity characteristics.

SmartGateway-Core (sg-core)

Ingests the metrics Ceilometer pushes over a TCP socket and re-exposes them for Prometheus to scrape. Runs as a sidecar container alongside each Ceilometer notification agent pod.

Introduced in MOSK with the OpenStack Gazpacho release.

Data flow

Metrics originate in the OpenStack cluster and libvirt, and move through the pipeline as follows:

  1. Ceilometer collects metrics from the cluster and OpenStack APIs.

  2. Ceilometer pushes the collected metrics to its co-located sg-core sidecar over a TCP socket.

  3. sg-core exposes the metrics in a Prometheus-scrapable format.

  4. The dedicated Prometheus instance scrapes and stores the metrics, subject to the 1 GB / 2 h retention limit.

  5. Aodh evaluates alarms against the stored metrics and fires the configured web hooks when thresholds are crossed.

  6. Tenant users and OpenStack Heat access metrics and alarm state through Aetos, which enforces Keystone-based tenant separation on top of the Prometheus API.

Tenant Telemetry enablement

To enable the Telemetry stack, add the following services to your kind:OpenStackDeployment:

spec:
  features:
    telemetry:
      mode: autoscaling
    services:
      - alarming  # Aodh
      - metering  # Ceilometer
      - metric-storage  # Prometheus + SG-core + Aetos

See also