Telemetry best practices

Telemetry best practices

The following are some suggested best practices to follow when deploying and configuring the Telemetry service. The best practices are divided into data collection and storage.

Data collection

  1. The Telemetry service collects a continuously growing set of data. Not all the data will be relevant for an administrator to monitor.

    • Based on your needs, you can edit the pipeline.yaml configuration file to include a selected number of meters while disregarding the rest. Similarly, in Ocata, you will need to edit polling.yaml to define which meters to generate.

    • By default, Telemetry service polls the service APIs every 10 minutes. You can change the polling interval on a per meter basis by editing the polling.yaml configuration file.

      Note

      Prior to Ocata, the polling configuration was handled by pipeline.yaml

      Warning

      If the polling interval is too short, it will likely increase the stress on the service APIs.

    • Expand the configuration to have greater control over different meter intervals. For more information, see the Pipeline configuration.

  2. You can delay or adjust polling requests by enabling the jitter support. This adds a random delay on how the polling agents send requests to the service APIs. To enable jitter, set shuffle_time_before_polling_task in the ceilometer.conf configuration file to an integer greater than 0.

  3. If polling many resources or at a high frequency, you can add additional central and compute agents as necessary. The agents are designed to scale horizontally. For more information refer to the high availability guide.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.