Chapter 2. Planning for operational measurements The resources that you monitor depend on your business requirements. You can use Ceilometer or collectd to monitor your resources. For more information on collectd measurements, see Section 2.2, "Collectd measurements" . For more information on Ceilometer measurements, see Section 2.1, "Ceilometer measurements" . 2.1. Ceilometer measurements For a full list of Ceilometer measures, see https://docs.openstack.org/ceilometer/train/admin/telemetry-measurements.html 2.2. Collectd measurements The following measurements are useful collectd metrics: disk interface load memory processes tcpconns 2.3. Planning for data storage Gnocchi stores a collection of data points, where each data point is an aggregate. The storage format is compressed using different techniques. As a result, to calculate the size of a time-series database, you must estimate the size based on the worst-case scenario. Warning The use of Red Hat OpenStack Platform (RHOSP) Object Storage (swift) for time series database (Gnocchi) storage is only supported for small and non-production environments. Procedure Calculate the number of data points: number of points = timespan / granularity For example, if you want to retain a year of data with one-minute resolution, use the formula: number of data points = (365 days X 24 hours X 60 minutes) / 1 minute number of data points = 525600 Calculate the size of the time-series database: size in bytes = number of data points X 8 bytes If you apply this formula to the example, the result is 4.1 MB: size in bytes = 525600 points X 8 bytes = 4204800 bytes = 4.1 MB This value is an estimated storage requirement for a single aggregated time-series database. If your archive policy uses multiple aggregation methods (min, max, mean, sum, std, count), multiply this value by the number of aggregation methods you use. Additional resources Section 1.3.1, "Archive policies: Storing both short and long-term data in a time-series database" Section 2.4, "Planning and managing archive policies" 2.4. Planning and managing archive policies An archive policy defines how you aggregate the metrics and for how long you store the metrics in the time-series database. An archive policy is defined as the number of points over a timespan. If your archive policy defines a policy of 10 points with a granularity of 1 second, the time series archive keeps up to 10 seconds, each representing an aggregation over 1 second. This means that the time series retains, at a maximum, 10 seconds of data between the more recent point and the older point. The archive policy also defines the aggregate method to use. The default is set to the parameter default_aggregation_methods , where the default values are set to mean , min , max . sum , std , count . So, depending on the use case, the archive policy and the granularity can vary. To plan an archive policy, ensure that you are familiar with the following concepts: Metrics. For more information, see Section 2.4.1, "Metrics" . Measures. For more information, see Section 2.4.2, "Creating custom measures" . Aggregation. For more information, see Section 2.4.4, "Calculating the size of a time-series aggregate" . Metricd workers. For more information, see Section 2.4.5, "Metricd workers" . To create and manage an archive police, complete the following tasks: Create an archive policy. For more information, see Section 2.4.6, "Creating an archive policy" . Manage an archive policy. For more information, see Section 2.4.7, "Managing archive policies" . Create an archive policy rule. For more information, see Section 2.4.8, "Creating an archive policy rule" . 2.4.1. Metrics Gnocchi provides an object type called metric . A metric is anything that you can measure, for example, the CPU usage of a server, the temperature of a room, or the number of bytes sent by a network interface. A metric has the following properties: A UUID to identify it A name The archive policy used to store and aggregate the measures Additional resources For terminology definitions, see Gnocchi Metric-as-a-Service terminology . 2.4.1.1. Creating a metric Procedure Create a resource. Replace <resource_name> with the name of the resource: Create the metric. Replace <resource_name> with the name of the resource and <metric_name> with the name of the metric: When you create the metric, the archive policy attribute is fixed and unchangeable. You can change the definition of the archive policy through the archive_policy endpoint. 2.4.2. Creating custom measures A measure is an incoming datapoint tuple that the API sends to Gnocchi. It is composed of a timestamp and a value. You can create your own custom measures. Procedure Create a custom measure: 2.4.3. Default archive policies By default, Gnocchi has the following archive policies: low 5 minutes granularity over 30 days aggregation methods used: default_aggregation_methods maximum estimated size per metric: 406 KiB medium 1 minute granularity over 7 days 1 hour granularity over 365 days aggregation methods used: default_aggregation_methods maximum estimated size per metric: 887 KiB high 1 second granularity over 1 hour 1 minute granularity over 1 week 1 hour granularity over 1 year aggregation methods used: default_aggregation_methods maximum estimated size per metric: 1 057 KiB bool 1 second granularity over 1 year aggregation methods used: last maximum optimistic size per metric: 1 539 KiB maximum pessimistic size per metric: 277 172 KiB 2.4.4. Calculating the size of a time-series aggregate Gnocchi stores a collection of data points, where each point is an aggregate. The storage format is compressed using different techniques. As a result, calculating the size of a time-series is estimated based on a worst case scenario, as shown in the following example. Procedure Use this formula to calculate the number of points: number of points = timespan / granularity For example, if you want to keep a year of data with one-minute resolution: number of points = (365 days X 24 hours X 60 minutes) / 1 minute number of points = 525600 To calculate the point size in bytes, use this formula: size in bytes = number of points X 8 bytes size in bytes = 525600 points X 8 bytes = 4204800 bytes = 4.1 MB This value is an estimated storage requirement for a single aggregated time-series. If your archive policy uses multiple aggregation methods - min, max, mean, sum, std, count - multiply this value by the number of aggregation methods you use. 2.4.5. Metricd workers You can use the metricd daemon to processes measures, create aggregates, store measures in aggregate storage and delete metrics. The metricd daemon is responsible for most CPU usage and I/O jobs in Gnocchi. The archive policy of each metric determines how fast the metricd daemon performs. Metricd checks the incoming storage for new measures periodically. To configure the delay between each check, you can use the [metricd]metric_processing_delay configuration option. 2.4.6. Creating an archive policy Procedure Create an archive policy. Replace <archive-policy-name> with the name of the policy and <aggregation-method> with the method of aggregation. Note <definition> is the policy definition. Separate multiple attributes with a comma (,). Separate the name and value of the archive policy definition with a colon (:). 2.4.7. Managing archive policies To delete an archive policy: To view all archive policies: To view the details of an archive policy: 2.4.8. Creating an archive policy rule An archive policy rule defines a mapping between a metric and an archive policy. This gives users the ability to predefine rules so an archive policy is assigned to metrics based on a matched pattern. Procedure Create an archive policy rule. Replace <rule-name> with the name of the rule and <archive-policy-name> with the name of the archive policy: 2.5. Verifying the Red Hat OpenStack Platform deployment You can use the openstack metric command to verify a successful deployment. Procedure Verify the deployment:

Commands:
openstack metric resource create <resource_name>
openstack metric metric create -r <resource_name> <metric_name>
openstack metric measures add -m <MEASURE1> -m <MEASURE2> .. -r <RESOURCE_NAME> <METRIC_NAME>
openstack metric archive policy create <archive-policy-name> --definition <definition> --aggregation-method <aggregation-method>
openstack metric archive policy delete <archive-policy-name>
openstack metric archive policy list
openstack metric archive-policy show <archive-policy-name>
openstack metric archive-policy-rule create <rule-name> / --archive-policy-name <archive-policy-name>
(overcloud) [stack@undercloud-0 ~]USD openstack metric status +-----------------------------------------------------+-------+ | Field | Value | +-----------------------------------------------------+-------+ | storage/number of metric having measures to process | 0 | | storage/total number of measures to process | 0 | +-----------------------------------------------------+-------+