anchor.diff:  * 200 for successful retrieval of an object
   * 204 when retrieving a subtree that would exist, but has no content. E.g. when the application-specific subtree has no application specific metrics defined.
   * 404 if a directly-addressed item does not exist. This may be a non-existing sub-tree or non-existing object
  -* 406 if the HTTP Accept Header in the request header cannot be handled by the server.
  +* 406 if the HTTP Accept Header in the request cannot be handled by the server.
   * 500 to indicate that a request failed due to "bad health". The body SHOULD contain details if possible { "details": <text> }
   
   The API MUST NOT return a 500 Internal Server Error code to represent a non-existing resource.
  
positive.code: export MP_METRICS_TAGS=app=shop,tier=integration
  ----
  
  Global tags and per-metric tags are included in the output returned from the REST API.
  
  [[meta-data-def]]
  ==== Metadata
  
  For all exposed metrics, matching metadata is exposed and needs to be provided by the setup. This is true for all scopes.
  
  TIP: While technically it is possible to expose metrics without (some) of the metadata, it helps tooling and also
  operators when correct metadata is provided, as this helps getting a context and an explanation of the metric.
  
negative.code: 
  To ensure reliable operation of the software it is necessary to monitor essential
  system parameters. This enhancement proposes the addition of well-known monitoring
  endpoints and metrics for each process adhering to the Eclipse MicroProfile standard.
  
  This proposal does not talk about health checks. There is a separate specification for
  https://github.com/eclipse/microprofile-health[Health Checks].
  