anchor.diff:  volume claims] is handled by the
   xref:../install_config/cluster_metrics.adoc#metrics-deployer[Metrics Deployer].
   
  -If you would like to use xref:../install_config/persistent_storage/dynamically_provisioning_pvs.adoc#install-config-persistent-storage-dynamically-provisioning-pvs[dynamically provisioned
  -persistent volumes] you will need to set the `*DYNAMICALLY_PROVISION_STORAGE*`
  -xref:../install_config/cluster_metrics.adoc#modifying-the-deployer-template[template
  -option] to `true` for the Metrics Deployer.
  +{product-title} metrics also supports
  +link:https://github.com/openshift/origin-metrics/blob/master/metrics.yaml#L130[dynamically
  +provisioned persistent volumes]. To use this feature with {product-title}
  +metrics, it is necessary to add an additional flag to the metrics-deployer:
  +`DYNAMICALLY_PROVISION_STORAGE=true`.
  +
  +At this time, EBS, GCE, and Cinder storage back-ends can be used to
  +xref:../install_config/persistent_storage/dynamically_provisioning_pvs.adoc#install-config-persistent-storage-dynamically-provisioning-pvs[dynamically
  +provision persistent volumes].
   
   [[metrics-non-persistent-storage]]
   === Non-Persistent Storage
  
positive.code: your metrics will be stored to a
  xref:../architecture/additional_concepts/storage.adoc#persistent-volumes[persistent
  volume] and be able to survive a pod being restarted or recreated. This is
  ideal if you require your metrics data to be guarded from data loss.
  
  The size of the persisted volume can be specified with the `CASSANDRA_PV_SIZE`
  xref:../install_config/cluster_metrics.adoc#deployer-template-parameters[template
  
negative.code:     | oc create -f -
  ----
  
  The size requirement of the Cassandra storage is dependent on the number of pods.
  It is the administrator's responsibility to ensure that the size requirements
  are sufficient for their setup and to monitor usage to ensure that the disk does
  not become full.
  
  If you would like to use xref:../install_config/persistent_storage/dynamically_provisioning_pvs.adoc#install-config-persistent-storage-dynamically-provisioning-pvs[dynamically provisioned
  persistent volumes] you will need to set the `*DYNAMICALLY_PROVISION_STORAGE*`
  xref:../install_config/cluster_metrics.adoc#modifying-the-deployer-template[template
  option] to `true` for the Metrics Deployer.
  
  [[capacity-planning-for-openshift-metrics]]
  === Capacity Planning for {product-title} Metrics
  
  After the metrics deployer runs, `oc get pods` output should look like:
  
  ====
  ----
   # oc get pods -n openshift-infra
   NAME                                          READY             STATUS      RESTARTS          AGE
   hawkular-cassandra-1-l5y4g                    1/1               Running     0                 17h
   hawkular-metrics-1t9so                        1/1               Running     0                 17h
   heapster-febru                                1/1               Running     0                 17h
  ----
  ====
  
  {product-title} metrics uses the Cassandra database as datastore for metrics.
  Currently, Cassandra is deployed with `*MAX_HEAP_SIZE=512M*` and
  `*NEW_HEAP_SIZE=100M*`. It is assumed that these values should cover most of
  {product-title} metrics installations. It is possible to change these values in
  the
  link:https://github.com/openshift/origin-metrics/blob/master/cassandra/Dockerfile[Cassandra
  Docker file] prior to deploying {product-title} metrics.
  
  By default, metrics data is stored for 7 days.  This is configurable by
  specifying the `*METRIC_DURATION*` parameter in the
  link:https://github.com/openshift/origin-metrics/blob/master/metrics.yaml[*_metrics.yaml_*
  configuration file]. After 7 days, Cassandra begins to purge older metrics data.
  Metrics data for pods and name spaces that were deleted is not automatically
  purged. These metrics are removed once they are 7 days old.
  
  In a test scenario including 10 nodes and 1,000 pods, 2.5GB of metrics data was
  accumulated over a 24-hour period.
  
  In a test scenario including 120 nodes and 10,000 pods, 25GB of metrics data was
  accumulated over a 24-hour period.
  
  Thus, a capacity planning formula for {product-title} metrics is:
  
  ====
  ----
  (((2.5*10^9)/1000)/24)/10^6 = ~0.125 MB/hour per pod.
  ----
  ====
  
  In a test scenario including 120 nodes and 10,000 pods, 25GB of metrics data was
  accumulated over a 24-hour period.
  
  ====
  ----
  (((11.410*10^9)/1000)/24)/10^6 = 0.475 MB/hour
  ----
  ====
  
  [width="80%"]
  |================================================
  | |1000 pods| 10000 pods
  | Cassandra load over 24 hours - default metrics parameters   |2.5GB| 11.4GB
  |================================================
  
  These two test cases are presented on the graph below.
  
  image::https://raw.githubusercontent.com/ekuric/openshift/master/metrics/1_10kpods.png[1000 pods vs 10000 pods monitored during 24 h]
  
  If the default value of 7 (days) for `*METRIC_DURATION*` and
  `*METRIC_RESOLUTION*` of 10 (seconds) are preserved, then it is expected that
  storage requirements for the Cassandra pod would be:
  
  [width="80%"]
  |================================================
  | |1000 pods | 10000 pods
  | Cassandra storage over 7 days - default metrics parameters | 20GB | 90GB
  |================================================
  
  In the last table, an additional 10% was added to the expected storage space as
  a buffer for unexpected monitored pod usage.
  
  [WARNING]
  ====
  