Chapter 1. Introduction to autoscaling components
Chapter 1. Introduction to autoscaling components Use telemetry components to collect data about your Red Hat OpenStack Services on OpenShift (RHOSO) environment, such as CPU, storage, and memory usage. You can launch and scale instances in response to workload demand and resource availability. You can define the upper and lower bounds of telemetry data that control the scaling of instances in your Orchestration service (heat) templates. Control automatic instance scaling with the following telemetry components: Data collection : Telemetry uses the data collection service (Ceilometer) to gather metric and event data. Storage : Telemetry stores metrics data in the time-series database service (Prometheus). Alarm : Telemetry uses the Alarming service (aodh) to trigger actions based on rules against metrics or event data collected by Ceilometer. 1.1. Data collection service (Ceilometer) for autoscaling You can use Ceilometer to collect data about metering information for Red Hat OpenStack Services on OpenShift (RHOSO) components. The Ceilometer service uses three agents to collect data from RHOSO components: A compute agent (ceilometer-agent-compute) : Runs on each Compute node and polls for resource use statistics. A central agent (ceilometer-agent-central) : Runs on the control plane to poll for resource use statistics for resources that are not provided by Compute nodes. A notification agent (ceilometer-agent-notification) : Runs on the control plane and consumes messages from the message queues to build event and metering data. 1.1.1. Publishers In Red Hat OpenStack Services on OpenShift (RHOSO), ceilometer-agent-compute and ceilometer-agent-central metrics use the RabbitMQ bus for transporting metrics to the ceilometer-agent-notification . Ceilometer-agent-notification uses the TCP publisher to transport metrics to the sg-core container, which then exposes them in Prometheus format on the ceilometer-internal.<namespace>.svc:3000/metrics endpoint. From this endpoint, the metrics are either scraped by a Prometheus instance provided by the MetricStorage , or by any external user-provided Prometheus-compatible system. 1.2. Time-series database service for autoscaling Prometheus is a time-series database that you can use for storing metrics. The Alarming service (aodh) and Orchestration service (heat) use the data that is stored in Prometheus for autoscaling. Prometheus uses the query language, PromQL. 1.3. Alarming service (aodh) You can configure the Alarming service (aodh) to trigger actions based on rules against the metrics data that is collected in Prometheus. Alarms can be in one of the following states: Ok : The metric or event is in an acceptable state. Alarm : The metric or event is outside of the defined Ok state. insufficient data : The alarm state is unknown, for example, if there is no data, or the check has not been executed yet, and so on. 1.4. Orchestration service (heat) for autoscaling The Orchestration service (heat) uses templates in YAML format. The purpose of a template is to define and create a stack, which is a collection of resources that the Orchestration service creates, and the configuration of the resources. Resources are objects in Red Hat OpenStack Services on OpenShift (RHOSO) and can include compute resources, network configuration, security groups, scaling rules, and custom resources.