Micrometer 建议用于 Quarkus 1.9 的指标
尽管 Quarkus 提供了 MicroProfile 扩展（包括 metrics），但在 1.9 版本发布后，我们现在建议在 Quarkus 中使用 Micrometer 扩展来处理 metrics。
MicroProfile Metrics 简史
在 2017 年创建 MicroProfile Metrics 规范期间，Dropwizard Metrics 是当时最流行的指标库。因此，MicroProfile 自然地以 DropWizard Metrics 作为其指标规范的灵感来源。
自那时以来，云环境的监控生态系统已经发生了巨大变化，这促使我们重新评估我们处理指标的方法。
为什么选择 Micrometer？
在过去的 3-4 年里，人们越来越关注站点可靠性工程师（SRE）在监控各种服务的运行状况方面的需求。这种关注推动了 SRE 世界的简洁性和易用性。我们不想让 SRE 的生活更艰难！
Micrometer 的设计和开发从一开始就专注于 SRE 的需求。该方法的一个关键方面是将指标实现分离到注册表中，允许不同的注册表自定义指标导出的方式，从而与特定的监控工具保持一致。
Micrometer 的构建是为了适应不断变化的云原生格局，同时为应用程序和库提供稳定的 API。每个 MeterRegistry 实现都封装了其特定的聚合和报告要求。有适用于 Prometheus 和 Statsd 等云监控系统以及 Datadog、New Relic 或 Stackdriver 等服务提供商的 MeterRegistry 实现。您也可以同时包含多个这些注册表。
虽然 Micrometer 提供了供应用程序使用的 API，但实际使用更多地侧重于 MeterBinder 抽象。MeterBinder 允许稍后为应用程序库添加仪器。当您的应用程序框架能够代表您注册已发现的 MeterBinder 时，效果会更好。
出于几个原因，Micrometer 的命名约定与 Dropwizard 或 MP Metrics 不同。首先，它对所有指标名称使用点表示法，例如 my.metric.name。然后，每个注册表实现都可以应用自己的命名约定，将其名称转换为符合其约定的名称。例如，Prometheus MeterRegistry 将 my.metric.name 转换为 my_metric_name。其次，Micrometer 是围绕维度指标的概念构建的，而不是稍后进行适应。
使用 Micrometer 的另一个好处是它在更广泛的 Java 生态系统中的应用。Spring Boot 和 Micronaut 等框架都使用 Micrometer。在 SRE 监控不同 Java 框架实例的环境中，让它们都生成具有相同名称和维度的指标是非常有益的。
例如，我们可能有如下 HTTP 端点的指标
http_server_requests{method="GET", uri="/hello", status="200", outcome="SUCCESS"}
http_server_requests{method="GET", uri="/hello", status="500", outcome="SERVER_ERROR"}使用 Quarkus，Micrometer 扩展会发出相同的 HTTP 端点指标，无论该指标是由 JAX-RS、Vert.x 还是 Undertow 创建的，而无需开发人员在其代码中添加任何内容。唯一需要做的就是激活指标。
Micrometer 扩展发出的 http 指标与 Spring Boot 和 Micronaut 发出的指标相同，这使得 SRE 能够处理聚合的 http 指标，而不管使用哪个 Java 框架。
我仍然可以使用 MicroProfile Metrics 吗？
MicroProfile Metrics 扩展 `quarkus-smallrye-metrics` 仍然可用，并且可以被应用程序使用。由于 Why Micrometer? 中概述的所有原因，Quarkus 不再建议应用程序使用该扩展。
在中短期内，我们将与 MicroProfile Metrics 社区合作，以使该规范与 Micrometer 一致。这对于规范意味着什么，可能要到 2021 年的某个时候才能知道。
对于那些即使在 Why Micrometer? 中讨论了问题，但仍然倾向于保持与 MicroProfile Metrics 兼容性的人来说，这仍然是可能的，但这取决于应用程序开发人员做出明智的选择。
