[for reviewer] we use a locally built app instead of downloading one from a remote URL, that removes dependency on network availability and also makes test likely more reliable.

[for reviewer] in practice we could have tested with earlier versions but some metrics are not available with them. 10.x version is has been released ~9 years ago.

I'd prefer having wildfly.transaction.committed.count because it bescribes a data it keeps better than just wildfly.transaction.committed.
Many metrics in this file have .count suffix, but many do not, or even got it removed.
Do you think we could use .count suffix as a standard for counters/updowncounters ? Semconv recommends it for updowncounters anyway.

That's something that I really considered doing, however adding the .count to every counter/updowncounter metric seems a bit redundant so I think it's simpler to use it only when needed, for example in the following cases:

• wildfly.db.client.connection.wait.count adding count helps with the naming as "wait" is not really a noun, also using a similar pattern we could capture the "wait time", for example with wildfly.db.client.connection.wait.duration, in this case it would anticipate a potential future use-case that does not exist yet.
• wildfly.session.active.count because we also have wildfly.session.active.limit, however for sessions we have wildfly.session.{created,expired,rejected}: there isn't any further breakdown possible, hence it should be fine to define them without .count suffix.

The way I understand the semconv specification here is that we could use .count to remove ambiguity or avoid plural terms, not that we have to use this strategy for every counter.

I'm still not 100% convinced, but this is just my personal preference to keep metric names as explicit as possible.
If I see a metric with the name like tomcat.error.count it is obvious that we have number of errors. If I see metric with name tomcat.error it is not obvious what data is there, at least not at the first glance.

And according to the example you brought up:
wildfly.session.active.count, wildfly.session.created, wildfly.session.expired and wildfly.session.rejected share similar category of data, but do not share naming pattern.
I'd really prefer having consitent wildfly.session.{active,created,expired,rejected} or wildfly.session.{active,created,expired,rejected}.count, but I'm not going to hold this PR if nobody else has any objections.

As another point of reference the JVM metrics, which happen to be the only ones that are currently part of semconv tend to only use the .count to indicate the current value, for example we have:

• jvm.class.loaded
• jvm.class.count
• jvm.class.unloaded

And in the case of memory buffers we already have a case where we have "distinct depths" in the same namespace:

• jvm.buffer.count
• jvm.buffer.memory.used
• jvm.buffer.memory.limit