anchor.diff:  cause Cassandra disk usage to unpredictably increase.
   ====
   
  -The link:http://www.hawkular.org/docs/rest/rest-metrics.html[Hawkular Metrics
  -documentation] covers how to use the API, but there are a few differences when
  -dealing with the version of Hawkular Metrics configured for use on
  -{product-title}:
  +The link:http://www.hawkular.org/docs/rest/rest-metrics.html[Hawkular Metrics documentation] 
  +covers how to use the API, but there are a few differences when dealing with the
  +version of Hawkular Metrics configured for use on {product-title}:
   
   [[cluster-metrics-openshift-projects-and-hawkular-tenants]]
   === {product-title} Projects and Hawkular Tenants
  
positive.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 must 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]
  ====
  Data loss will result if the Cassandra persisted volume runs out of sufficient space.
  ====
  
  For cluster metrics to work with persistent storage, ensure that the persistent
  volume has the *ReadWriteOnce* access mode. If not, the persistent volume claim
  will not be able to find the persistent volume, and Cassandra will fail to
  start.
  
  To use persistent storage with the metric components, ensure that a
  xref:../architecture/additional_concepts/storage.adoc#persistent-volumes[persistent
  volume] of sufficient size is available. The creation of
  xref:../architecture/additional_concepts/storage.adoc#persistent-volume-claims[persistent
  volume claims] is handled by the
  xref:../install_config/cluster_metrics.adoc#metrics-deployer[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
  
negative.code: *Authorization* header.
  
  ifdef::openshift-origin[]
  [[cluster-metrics-accessing-heapster-directly]]
  == Accessing Heapster Directly
  
  Heapster has been configured to be only accessible via the
  