Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Named meter namespace clarification #408

Merged
merged 12 commits into from
Jan 22, 2020
Merged

Named meter namespace clarification #408

Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
7570973
remove named meter / namespace conflation
dyladan Jan 8, 2020
130c536
add obtaining a meter section
dyladan Jan 8, 2020
82e074b
Update specification/api-metrics-user.md
arminru Jan 9, 2020
f6feff0
Add note that metric namespace != meter name
arminru Jan 9, 2020
08203ca
Add line breaks
arminru Jan 13, 2020
a4ecef2
grammar
arminru Jan 13, 2020
96d0629
Indent bullet point
arminru Jan 13, 2020
5b49eac
remove confusing observability unrelated sentence
dyladan Jan 14, 2020
5b9e36f
Remove confusion between namespace and named meter
dyladan Jan 14, 2020
86f02ea
clarify component wording
dyladan Jan 15, 2020
1b5a023
Merge remote-tracking branch 'origin/master' into named-meter-namespa…
dyladan Jan 21, 2020
b4d0689
Merge branch 'master' into named-meter-namespace-clarification
carlosalberto Jan 22, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update specification/api-metrics-user.md 
Co-Authored-By: Wolfgang Ziegler <wolfgang.ziegler@dynatrace.com>
  • Loading branch information
@arminru @z1c0
arminru and z1c0 authored Jan 9, 2020
commit 82e074b71f4f915ef203e69191d18cbc3b915393
2 changes: 1 addition & 1 deletion specification/api-metrics-user.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Metric instruments are the entry point for application and framework developers
New `Meter` instances can be created via a `MeterFactory` and its `getMeter` method. `MeterFactory`s are generally expected to be used as singletons. Implementations
SHOULD provide a single global default `MeterFactory`. The `getMeter` method expects two string arguments:

- `name` (required): This name must identify the instrumentation library (also referred to as integration, e.g. `io.opentelemetry.contrib.mongodb`) and *not* the instrumented library. In case an invalid name (null or empty string) is specified, a working default Meter implementation as a fallback is returned rather than returning null or throwing an exception. A library, implementing the OpenTelemetry API *may* also ignore this name and return a default instance for all calls, if it does not support "named" functionality (e.g. an implementation which is not even observability-related). A MeterFactory could also return a no-op Meter here if application owners configure the SDK to suppress telemetry produced by this library.
- `name` (required): This name must identify the instrumentation library (also referred to as integration, e.g. `io.opentelemetry.contrib.mongodb`) and *not* the instrumented library. In case an invalid name (null or empty string) is specified, a working default `Meter` implementation as a fallback is returned rather than returning null or throwing an exception. A library, implementing the OpenTelemetry API *may* also ignore this name and return a default instance for all calls if it does not support "named" functionality (e.g. an implementation which is not even observability-related). A `MeterFactory` could also return a no-op `Meter` here if application owners configure the SDK to suppress telemetry produced by this library.
- `version` (optional): Specifies the version of the instrumentation library (e.g. `semver:1.0.0`).

### Metric names
Expand Down