add metric annotation instrumentation

[Duncan-tree-zhou]

refer to #7030
add metric annotation instrumentation

[steverao]

There are some CI failures, firstly you can solve them by referring to https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/contributing/running-tests.md#troubleshooting-ci-test-failures

[Duncan-tree-zhou]

Hi @steverao, I found that there are lots of fails "to connect to localhost/127.0.0.1:4318". So I want to rerun the task, but I can't see the rerun button. Is it disabled for contributors?

[steverao]

Is it disabled for contributors?

Yes, you can fix the problems firstly and push relevant commits. It will trigger to rerun the CI tasks.

[Duncan-tree-zhou]

I mean I guest the failure is caused by the CI run time environment crush..... if it's able to rerun a task, It might save some time....

[Duncan-tree-zhou]

I turn it ready for reviewing, and get some questions for discuss:

1. the module naming of the @Counted and @Timed instrumentation.
   • I avoid using the opentelemetry-instrumentation-annotations prefix because it's already been used for @Withspan. I am not sure if using opentelemetry-instrumentation-annotations-coutned would cause some problem somewhere.
   • I have no idea if there is a better module naming rule for metrics annotations instrumentations.
2. I am not sure if we should put the instance of meter, LongCounter and DoubleHistogram in another module where can be loaded without javaagent?
3. I am doubted about allowing the return value to be an attributes because most of time the return value is unpredictable. would it be possible to design some static api to allow user to post the attributes to the metrics via threadlocal?

[laurit]

@open-telemetry/java-instrumentation-approvers could you please review

[trask]

I wonder if it's worth renaming this to name (even though it would then require providing name = ), so that it's not confusing that this is the "metric value", and consistent with @StaticMetricAttribute which uses name/value

[laurit]

I don't really like forcing users to use name = "foo" Micrometer https://github.com/micrometer-metrics/micrometer/blob/main/micrometer-core/src/main/java/io/micrometer/core/aop/MeterTag.java defines key and value and says that both represent the name of the tag and value is an alias for key.

[trask]

Can we doc the attribute type that will be used for the metric attribute?

[laurit]

The attribute type is chosen based on the same logic as with SpanAttribute. The logic for choosing the type in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-annotations-support/src/main/java/io/opentelemetry/instrumentation/api/annotation/support/AttributeBindingFactory.java is quite complicated but in my opinion still not complete. For example it does not handle byte and short and their arrays as numeric types. In the span attribute code there are differences between attribute types used in the default and kotlin coroutine implementation.

[brunobat]

I would call this @Attribute and would use it both for metrics and tracing...
We have the @SpanAttribute witch can record high cardinality data. However, @Attribute could have a field stating if we want it or not in the trace...
This would avoid having a ton of annotations in method params.

[laurit]

I totally agree that the current names are not ideal, but I think they are good enough for the first prototype and give a good base to build upon. To be honest I wasn't really interested in driving this effort I only wanted to help getting this PR into mergeable shape.

[brunobat]

It's probably worth to discuss this a bit because if we have to change it in the future, it will be yet another breaking change.

[brunobat]

@ StaticMetricAttribute is a very long name.