* Update types to reflect the names in proto
NON_MONOTONIC_SUM will be soon merged with SUM and offer the "isMonotonic" as a property.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Update names to follow, type + aggregation pattern
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
This PR fixes a small bug where the AllLabels implementation was expecting "unmapped" boolean, which was passed correctly by the Sync instruments, but incorrectly by the Async.
This causes an unnecessary allocation for all the async instruments recordings.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Rename batcher to instrumentaccumulator, remove active batcher (not used)
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Fix tests, add back check for has records
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
CHANGELOG: the SDK will no longer throw an exception with a null instrumentation name on tracers or meters, but this is still not recommended usage.
* Provide a default Tracer and Meter for invalid instrumentation names
According to the spec, https://github.com/open-telemetry/opentelemetry-specification/blob/v0.6.0/specification/trace/api.md#tracerprovider-operations both a null and empty instrumentation name are invalid and a default implementation should be provided.
However, the spec is vague on what default means. See https://github.com/open-telemetry/opentelemetry-specification/issues/586#issuecomment-669856711
This change interprets "default" as meaning, "it should still work, but it's not ideal". Accordingly, a real Tracer or Meter implementation from the SDK is used. It meets the requirements of exporters and such by using a valid instrumentation name. It meets the requirements of application developers by producing valid tracing data. It also warns library and application developers by logging at the WARN level that an invalid value has been given.
The rational for this interpretation is that things should always work for the application developer. If an app developer doesn't provide a name, they should be chided, but they are instrumenting their own app, and likely don't care about the lack of name. If an app developer incorporates a library that doesn't specify the instrumentation name, the instrumentation should still be made available to application devs, but they should be able to turn if off (hence a valid name) and be made aware of something not being right (hence the logging) so they can report it to the library maintainers.
Fies #1879
* Mark instrumentation version nullable in MeterProvider and TracerProvider
The spec dictates this to be optional, and the implementations treat it as nullable already.
* Remove ComponentRegistry#get(String) overload
This overload is not no longer used by our code.
* fixup! Mark instrumentation version nullable in MeterProvider and TracerProvider
* fixup! Provide a default Tracer and Meter for invalid instrumentation names
* fixup! Provide a default Tracer and Meter for invalid instrumentation names
* fixup! Remove ComponentRegistry#get(String) overload
This reverts commit db56814c
* Revert "Mark instrumentation version nullable in MeterProvider and TracerProvider"
This reverts commit 7e92b396
* Make the BatchRecorderSdk actually batch the recordings
Rather than just forwarding them immediately.
* rework the batch recorder to use a queue of recordings
* remove an allocation per recording by introducing some typed classes
* Use LongAdder instead of AtomicLong
Now that we're based on Java 8, we can use LongAdder instead.
* Use DoubleAdder instead of AtomicDouble
Co-authored-by: Anuraag Agrawal <aanuraag@amazon.co.jp>
* subsume methods from AttributesKeys to AttributeKey
* remove missed instance of AttributesKeys
* make javadoc wording more representative of method intent
* Remove Descriptor from metrics data to be consistent with proto
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Remove references to descriptor
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Add a generic type for the key on the ImmutableKeyValuePairs.
This necessitated changing the `get` to `getValue` to avoid clashing with the java.util.Map interface.
Also introduced convenience sub-interfaces for consuming labels and attributes, so consumers don't have to worry about the types if they don't want to.
* Make AttributesMap not extend map, and restore the get method name for Attributes.
* key class and implementation
* key class and implementation
* The code compiles
* little tweaks
* some cleanup, tests are passing
* remove AttributeValue and clean up misc. references to it.
* clean up some unused bits
* add a TODO
* a bit of cleanup; fix a todo
* update for changes from the main branch
* Change method to get the underlying key.
Move the key creators to a AttributesKeys class.
Hide the implementation classes and replace with interface use.
* use autovalue for the key implementations
* fix javadoc issues
* update benchmark keys, and a few tweaks from PR review
* Add javadoc notes to encourage using the lower-overhead attribute options.
* Add javadoc clarifying subclass responsibilities around empty keys.
* make the compareTo on AttributeKeyImpl null-safe, for extra safety
* fix formatting
* switch to java 8
* update the READMEs and use Object.equals in a couple of cases to test that we're really compiling for java 8/android 24.
* formatting
* use the newer release options for the build, and change the int test to not be java 7 any more.
* switch back to source/target compatibility
* sure wish I could run docker locally to test this out.
* Split single "sdk" module into separate pieces for common, correlationcontext, metrics, tracing, and the combination of them all
* Modify comment to not reference implementation class
* Moved JMH code to /sdk/all
* Move new files to adjusted location
* Move new files from rebase
Bogdan Drutu