b6896c2400
1. Dead link to the HA guide. Added a comment regarding availability and reliability. 2. Hyper-v link re-routed to Azure instead of Hyper-V. Updated this so it reflects Hyper-V docs. Suggestion: Might be worth mentioning which Hyper-V servers ceilometer actually supports. Change-Id: I4a56ee26ae39ab02bed8bac8d0e364322617622c backport: stein rocky
35 lines
1.2 KiB
ReStructuredText
35 lines
1.2 KiB
ReStructuredText
Telemetry best practices
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The following are some suggested best practices to follow when deploying
|
|
and configuring the Telemetry service.
|
|
|
|
Data collection
|
|
---------------
|
|
|
|
#. 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 ``polling.yaml`` and
|
|
``pipeline.yaml`` configuration files to include select meters to
|
|
generate or process
|
|
|
|
- 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.
|
|
|
|
.. warning::
|
|
|
|
If the polling interval is too short, it will likely increase the
|
|
stress on the service APIs.
|
|
|
|
#. 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
|
|
<https://docs.openstack.org/ha-guide/>`_.
|
|
|
|
.. note::
|
|
|
|
The High Availability Guide is a work in progress and is changing
|
|
rapidly while testing continues.
|