Quarkus 3 中的可观察性
Quarkus 中的可观测性
软件系统的可观测性可以描述为允许人类提出和回答问题的能力。为了使开发人员和支持工程师能够理解其应用程序的行为，Quarkus 3.3 包含对其主要可观测性相关扩展的许多改进。
-
quarkus-opentelemetry(tracing) -
quarkus-micrometer(metrics)
OpenTelemetry
OpenTelemetry tracing 用于了解请求在穿越多个服务时的流向。
quarkus-opentelemetry 扩展在 Quarkus 3.0 中已经进行了重大升级，其中的配置与 OpenTelemetry (OTel) 社区使用的配置保持一致。这使得许多以前在 Quarkus 中不可用的配置可用。其他改进包括：
-
OpenTelemetry 扩展可以在开发模式下使用，并且现在可以正确重新加载。
-
OTel 服务提供商接口 (SPI) 挂钩 Sampler 和 SpanExporter 已与现有的用户实现一起通过 CDI 提供，适用于许多 OTel 类：
IdGenerator、Resource 属性、Sampler和SpanProcessor。 -
同时，JDBC tracing 的激活变得更简单，只需使用一个属性即可。
quarkus.datasource.jdbc.telemetry=true在 Quarkus 3.3 中，对 quarkus-opentelemetry 扩展进行了许多改进。影响最大的改进是：
移除 OkHttp 依赖
在以前的版本中，Quarkus 导出器使用上游 OTel 库，并利用 OkHttp 库将 spans 发送到 OTel Collector。这个不必要的依赖已被移除，并被 Quarkus 特定的 Vert.x GRPC 和 HTTP 客户端取代。与之前一样，导出器仍然通过 CDI 自动连接，这就是为什么在 Quarkus 3+ 中 quarkus.otel.traces.exporter 属性默认设置为 cdi。
导出器支持 HTTP 协议
直到 Quarkus 3.2，OTel 导出器只能使用 GRPC 协议，而 Quarkus 现在也支持 HTTP。要使用新的 HTTP 协议，必须将 quarkus.otel.exporter.otlp.traces.protocol 属性设置为 http/protobuf。quarkus.otel.traces.exporter.endpoint 属性也必须设置为 OTel Collector 的 HTTP 端点。以下是使用 OTel Collector 的默认 HTTP 端口 4318 时的示例：
quarkus.otel.exporter.otlp.traces.protocol=http/protobuf
quarkus.otel.exporter.otlp.endpoint=https://:4318导出器支持 TLS
GRPC 和 HTTP 导出器现在都支持传输层安全 (TLS) 和自定义证书。
与 Quarkus 中的其他 REST 客户端一样，如果您设置了以下内容，导出器的证书验证也将被禁用：
quarkus.tls.trust-all=true|
此设置不应在生产环境中使用，因为它将禁用任何 SSL 验证。 |
自定义传播头
我们添加了一种自定义传播头的方法。
您可以创建一个实现 TextMapPropagatorCustomizer 接口的 CDI bean。
这可以用于限制 OpenTelemetry trace 头部的传播，并防止潜在的敏感数据发送到第三方系统。
这是一个移除 Baggage 头部的自定义器的示例：
@Singleton
public static class TestTextMapPropagatorCustomizer implements TextMapPropagatorCustomizer {
@Override
public TextMapPropagator customize(Context context) {
TextMapPropagator propagator = context.propagator();
if (propagator instanceof W3CBaggagePropagator) {
return TextMapPropagator.noop();
}
return propagator;
}
}在 spans 中识别用户
通过设置以下内容，可以将有关用户的重要调试信息添加到每个 span 中：
quarkus.otel.traces.eusp.enabled=true如果可用，用户的 ID 和角色将添加到 span 属性中。
Micrometer
Quarkus 中的指标基于 Micrometer 库。数据可以直接使用 quarkus-micrometer-registry-prometheus 扩展导出到 Prometheus。如果您想将数据发送到 OTel Collector，可以使用 quarkus-micrometer-registry-otlp Quarkiverse 扩展，以及 其他选项。
这些是 quarkus-micrometer 扩展最近的一些改进。
Netty 分配器指标
该扩展现在默认提供 Netty 分配指标。Netty 使用内存分配器来池化内存缓冲区以供重用。这些指标将使您更深入地了解应用程序的内存使用情况。将报告直接内存和堆内存使用情况。
要禁用这些指标，请设置：
quarkus.micrometer.binder.netty.enabled=falseHTTP 服务器数据的自定义标签
通过创建实现 HttpServerMetricsTagsContributor 接口的 CDI bean 来自定义发出的标签。这允许用户代码根据 HTTP 请求的详细信息计算任意标签。这是一个实现示例，其中 Foo 头的值用于设置 foo 标签。
@Singleton
public class HeaderTag implements HttpServerMetricsTagsContributor {
@Override
public Tags contribute(Context context) {
String headerValue = context.request().getHeader("Foo");
String value = "UNSET";
if ((headerValue != null) && !headerValue.isEmpty()) {
value = headerValue;
}
return Tags.of("foo", value);
}
}|
仅设置具有低基数值的标签，这意味着可能不同值的数量很少。例如，一个带有 HTTP 方法的标签是一个好的候选，但一个带有 HTTP 完整路径的标签不是。 |
使用 MeterRegistryCustomizer 对 Meter Registries 进行任意自定义
通过提供实现 io.quarkus.micrometer.runtime.MeterRegistryCustomizer 的 CDI bean，用户代码可以更改任何已激活的 MeterRegistry 的配置。除非实现被注解为 @io.quarkus.micrometer.runtime.MeterRegistryCustomizerConstraint，否则自定义将应用于所有 MeterRegistry 实例。
这是一个方法示例，其中自定义器会为所有指标设置 foo 标签。
@Produces
@Singleton
public MeterRegistryCustomizer customizeAllRegistries() {
return new MeterRegistryCustomizer() {
@Override
public void customize(MeterRegistry registry) {
registry.config()
.meterFilter(MeterFilter.commonTags(List.of(
Tag.of("foo", "foo-value"))));
}
};
}通过实现 MeterRegistryCustomizer 来发出的指标。
