Telemetry Capabilities

StarlingX OpenStack includes an optional Telemetry stack that gives operators visibility into resource consumption, performance trends, and notable events across the cloud. The stack collects usage data from StarlingX OpenStack services, stores it as time-series metrics, and evaluates alarm conditions.

The Telemetry services are disabled by default. Enable them individually using Helm chart overrides when your deployment requires metering or threshold alarming. Collected metrics are stored in Prometheus, which is supplied by the StarlingX Prometheus application (see app-prometheus).

Ceilometer

Ceilometer acts as the data-collection pipeline for the Telemetry stack. It gathers resource-usage samples from StarlingX OpenStack services in two ways:

  • Notification listener — Consumes events published to the message bus by Nova, Neutron, Cinder, Glance, and other services.

  • API polling — Queries service APIs at configurable intervals to capture metrics that are not emitted as notifications.

Ceilometer exposes the collected samples through its exporters, and the StarlingX Prometheus application scrapes and stores them as time-series metrics. The service covers a broad set of resource types:

  • Compute instances (CPU, memory, disk, network I/O)

  • Block storage volumes (Cinder)

  • Images (Glance)

  • Networks and ports (Neutron)

  • Object storage (Swift)

Note

Enabling Ceilometer without Prometheus is not supported because Prometheus serves as the required storage backend for all collected metrics.

Prometheus

Prometheus provides the time-series storage backend that underpins Telemetry metric storage and querying, replacing the previously used Gnocchi database. It is supplied by the StarlingX Prometheus application (app-prometheus) rather than by the StarlingX OpenStack application itself.

Key capabilities:

  • Metrics storage — Scrapes and stores the metrics exposed by the Ceilometer exporters, so operators can query usage data by resource and label.

  • Retention — Configurable retention of stored time-series data for trend analysis and capacity planning.

  • PromQL and API — Exposes metrics through the Prometheus query language and HTTP API for dashboards, capacity-planning tools, and custom integrations.

For details on deploying and configuring the Prometheus application, see the StarlingX Prometheus application documentation.

Aodh

Aodh delivers threshold-based and event-driven alarming against the metrics stored by the Telemetry stack. Operators define alarm rules, and Aodh evaluates them on a recurring cycle, triggering configured actions when conditions are met.

Supported alarm types:

  • Threshold alarms — Fire when a metric value crosses a defined upper or lower bound (for example, average CPU utilization exceeding 80 % over five minutes).

  • Composite alarms — Combine multiple conditions using logical operators (AND/OR), enabling complex multi-metric rules in a single alarm definition.

  • Event alarms — Fire in response to specific StarlingX OpenStack events, such as an instance entering an error state.

Alarm actions can include HTTP callbacks (webhooks), log entries, or integration with Heat for auto-scaling — automatically adding or removing instances in response to load changes.

Enable Telemetry Services

The Telemetry services are disabled by default to conserve resources on size-constrained deployments. Operators enable individual services using Helm chart overrides when their deployment requires metering or threshold alarming. Enabling Ceilometer without Prometheus is not supported because Prometheus serves as the required storage backend for all collected metrics.