anchor.diff:  Metrics can also help those scheduling systems to make decisions when to scale the application
   to run on more or less machines depending on the metrical values.
   
  -== Format of exposed data (external API)
  -
  +
  +== 2. Architecture
  +
  +=== 2.1 Overview
  +This chapter describes the architectural overview of how metrics are setup, stored and exposed for consumption.
  +
  +See section 3 for more information regarding metrics.
  +
  +See section 4 for more information regarding the application metrics programming model.
  +
  +=== 2.2 Metrics Setup
  +
  +Metrics that are exposed need to be configured in the server.
  +There are two different approaches depending on the scope of the data, which are described next.
  +
  +==== 2.2.1 Required Base and Vendor specific metrics
  +
  +Each vendor of a Microprofile-compliant server can implement setting up the metrics in _base_ and _vendor_ scopes in a
  +vendor-specific way. The metrics can be hard coded into the server or read from a configuration file.
  +The Appendix shows a possible data format for such a configuration.
  +The configuration and set up of  _base_ and _vendor_ scopes  are an implementation detail and are not expected to be portable across vendors.
  +
  +
  +==== 2.2.2 Application metrics
  +
  +Application specific metrics can not be backed into the server as they are supposed to be provided by the application at runtime.
  +
  +To access application metrics and its metadata a class `ApplicationMetric` is made available which can be injected
  +via CDI
  +
  +[source]
  +----
  +@Inject
  +ApplicationMetric applicationMetric;
  +----
  +
  +This can then be used to register MetaData
  +
  +[source]
  +----
  +MetadataEntry demoEntry = new MetadataEntry("demo",  // Name, mandatory
  +        null,                                        // display name
  +        "Just a demo value",                         // description
  +        "gauge",                                     // type
  +        "none");                                     // unit
  +demoEntry.setTags("app=demo");
  +applicationMetric.registerMetric("demo", demoEntry);
  +----
  +
  +Registration of a metric is mandatory before it can be used (and is published over the REST api)
  +
  +Writing a value:
  +
  +[source]
  +----
  +applicationMetric.bumpValue("demo",1);  // Increment by 1
  +----
  +
  +or
  +
  +[source]
  +----
  +applicationMetric.setValue("demo",42);   // set to absolute value 42
  +----
  +
  +==== 2.2.3 Supplying of Tags
  +
  +Tags can be supplied in two ways
  +
  +* At the level of a metric shown in the above examples
  +* At the application server level by passing the list of tags in an environment variable `MP_METRICS_TAGS`
  +
  +`export MP_METRICS_TAGS=app=shop,tier=integration`
  +
  +Global tags will be appended to the per-metric tags.
  +
  +=== 2.2 Metric Registry
  +<TO DO>
  +
  +=== 2.3 Exposing metrics through External API
   Data is exposed via REST over http under the `/metrics` base path in two default data formats for `GET` requests:
   
   * Json format.
  
positive.code: = Metrics via HTTP endpoints
  
  
  * Authors: https://github.com/pilhuhn[Heiko W. Rupp], https://github.com/raymondlam[Raymond Lam], https://github.com/Channyboy[David Chan]
  
  
  
  == Introduction
  
  To ensure reliable operation of the software it is necessary to monitor essential
  system parameters. This enhancement proposes the addition of well-known monitoring
  
negative.code: }
  ----
  
  ==== 4.#.# Application Metrics access
  
  [source]
  ----
  