anchor.diff:  
   Tags (or labels) play an important role in modern microservices and microservice scheduling systems (like e.g. Kubernetes).
   Application code can run on any node and can be re-scheduled to a different node at any time. Each container in such
  -an environment gets its own ID; when the container is stopped and a new one started for the same iamge, it will get a
  +an environment gets its own ID; when the container is stopped and a new one started for the same image, it will get a
   different id. The classical mapping of host/node and application runtime on it, therefore no longer works.
   
   Tags have taken over the role to for example identify an application (`app=myShop`), the tier inside the application
  
positive.code:    * @return the matching Enum
     * @throws IllegalArgumentException if in is not a valid enum value
     */
    public static MpMType from(String in) { [..] }
  
    [...]
  }
  
negative.code: [[app-metrics-api]]
  == Application Metrics Programming Model
  
  Microprofile Health provides a way to register Application-specific metrics to allow applications to expose metrics in
  the _application_ scope (see <<_scopes>> for the description of scopes).
  
  Metrics and their metadata are added to a _Metric Registry_ upon definition and can afterwards have their values set
  and retrieved via the Java-API and also be exposed via the REST-Api (see <<rest-api>>).
  
  NOTE:: Implementors of this specification can use the Java API to also expose metrics for _base_ and _vendor_ scope by
  using the respective Metric Registry.
  
  In order to make setting the values easier, Annotations are made available.
  
  .Example set-up of two Gauge metrics
  [source,java]
  ----
  @Gauge(unit = MetricUnit.MEGABYTE) <1>
  int diskUsage;
  
  @Gauge(name = "queueSize")         <2>
  public int getQueueSize() {
    return queue.size;
  }
  ----
  <1> The metric is of type Gauge and the values are in Megabytes
  <2> No unit is given, to `MetricUnit.NONE` is used, an explicit name is provided
  
  INFO:: The programming API follows Dropwizard Metrics 3.2.3 API, but with local changes.
  It is expected that many existing DropWizard Metrics based applications can easily be
  ported over by exchanging the package names.
  
  It will be possible to use the non-annotations API, but using the annotations is preferred.
  
  === Responsibility of the Microprofile Metrics implementation
  
  * The implementation must scan the application at deploy time for <<api-annotations>> and register the
  Metrics along with their metadata in the MetricsRegistry.
  * The implementation must watch the annotated objects and update its internal data structures when the values of the
  annotated objects change.
  * The implementation must expose the values of the objects registered in the MetricsRegistry via REST-API as described
  in <<rest-api>>.
  * Metrics registered via non-annotations API need their values be set via updates from the application code.
  * The implementation must flag duplicate metrics upon registration and reject the duplicate.
  A duplicate metric is a metric that has the same scope and name as an existing one.
  
  
  === Base Package
  
  All Java-Classes are in the top-level package `org.eclipse.microprofile.metrics` or one of its sub-packages.
  
  [[api-annotations]]
  === Annotations
  
  All Annotations are in the `org.eclipse.microprofile.metrics.annotation` package
  
  The following Annotations exist, see below for common fields:
  
  @Counted::
      An annotation for marking a method or field of as a counter.
  @Gauge::
      An annotation for marking a method of field as a gauge.
  @Metered::
      An annotation for marking a constructor or method as metered. The meter counts the invocations
      of the constructor or method.
  @Metric::
  
  TODO
  
  
  @Timed::
      An annotation for marking a constructor or method of an annotated object as timed.
      The metric of type Timer records the time it took to invoke the annotated object.
  
  @RegistryType::
      Qualifies the type of Metric Registry to inject. Default is _application_ (scope).
  
  ==== Fields
  
  All annotations (Except `RegistryType`) have the following fields that correspond to the metadata fields described
  in <<meta-data-def>>.
  
  `String name`::  the name of the metric. If not explicitly given it is determined from the annotated object and the
  fully qualified name of the surrounding class, unless `absolute` is true.
  `boolean absolute`:: If `true` use the given name as an absolute name. If `false`, use the given name relative to
  the annotated class
  `String displayName`:: Optionally provide a human readable display name for metadata.
  `String description`:: Optionally provide a description of the metric.
  `MetricUnit unit:: Unit of the metric
  `String[] tags`:: Array of Strings in the `<key>=<value>` format to supply special tags to a metric.
  
  NOTE:: Implementors are encouraged to issue warnings in the server log if metadata is missing. While this is
  less important for description and displayName, it is very important for Units.
  
  
  === Metric Registry
  
  
  === Java API Classes
  
  