Micrometer metrics from wildfly. How to overwrite the {job="wildfly"} tag?

[ralfbat...@gmail.com]

Dear Wildfly Team

I  am switching to micrometer and pushing metrics to the otel collector. Since we are pushing from several independent processes to the same collector instance, we need to be able to differentiate wildfly metrics which are not in the context of a deployment. Here is an example:

jvm_uptime_seconds{job="wildfly"} 49.984

Is there a way if overwriting the default value "wildfly" ? So that we can identify the uptime for the different processes. 

Best Regards, Ralf

[ralfbat...@gmail.com]

I forgot to mention:

• We are using Wildfly 38.0.0
• Setting of otel.service.name has only affect for opentelemetry metrics but not for the wildfly produced tags

To be honest, I am confused about the three metrics types available. The admin documentation suggests to use one of them because of performance issues but there no clear instructions which kind of metrics are exposed by these 3 metrics implementation.

As far as I can see:

• application specific metrics are exposed by Micrometer system only
• jvm metrics are exposed by the opentelemetry metrics system only
• wildfly metrics? No idea

But I am may wrong

[Jason Lee]

There are several issues/questions here, so I’ll do my best to address them this way:

• I don’t believe that tag can be overridden currently for the Micrometer subsystem. The otel.* system properties only affect the OpenTelemery/MicroProfile Telemetry subsystems.
• There is an open RFE to address this here: https://issues.redhat.com/browse/WFLY-18290 I don’t have an update on what that might look like or when it might be addressed, but it is certainly in the back of my mind as we continue to work on these subsystems. It comes down to time and competing priorities, but I’m trying to get there. :)
• If you would like to file a Jira to address this meter attribute explicitly, it would certainly raise the visibility of the issue and make sure it is addressed at some point in the hopefully near future.
• The lack of system metrics from Micrometer is a bug that was recently discovered and fixed: https://issues.redhat.com/browse/WFLY-21065 It is currently scheduled to ship with WildFly 39.0.0.Beta1
• There are, indeed, three different metrics systems, which can be, no doubt confusing. WildFly Metrics is a much older system that was intended to provide JVM and system metrics only. After surveying the metrics landscape a few years ago, we added support for Micrometer metrics to the server to allow deployments to register and report metrics as well as an alternative to MicroProfile Metrics, which were deemed less than adequate. OpenTelemetry/MP Telemetry came along a bit later as the MicroProfile Working Group added the then-new MicroProfile Telemetry specification to the MP Platform to fill the role formerly held by MP Metrics. Which you use of the three depends on your needs. If you just need system metrics, then WildFly Metrics should be sufficient. If you also want application metrics, then you are free to choose between Micrometer or OpenTelemetry/MP Telemetry as fits your personal preferences or architectural requirements. The latter two provide roughly the same functionality, so you need not use both, generally speaking, though OpenTelemetry/MP Telemetry does also offer tracing and logging support for a more completely observability solution if that fits a need for your environment.

If you have any other questions or concerns, please let me know. Your feedback definitely helps how we evolve the system.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/f230a22d-974d-4f26-8a2c-1d989b6d172fn%40googlegroups.com.

-- 
Jason Lee
Principal Software Engineer
IBM Java Middleware
Java Champion