| A set of user-defined (key, value) data that provides additional information about the log entry. | Attributes |
-| All other fields | | | Attributes["google.*"] |
+| All other fields | | | `Attributes["google.*"]` |
## Elastic Common Schema
@@ -1070,37 +1070,37 @@ Rest of SDIDs -> Attributes["syslog.*"]
| agent.name |
string |
Name given to the agent |
- resource["telemetry.sdk.name"] |
+ `Resource["telemetry.sdk.name"]` |
| agent.type |
string |
Type of agent |
- resource["telemetry.sdk.language"] |
+ `Resource["telemetry.sdk.language"]` |
| agent.version |
string |
Version of agent |
- resource["telemetry.sdk.version"] |
+ `Resource["telemetry.sdk.version"]` |
| source.ip, client.ip |
string |
The IP address that the request was made from. |
- attributes["net.peer.ip"] or attributes["net.host.ip"] |
+ `Attributes["net.peer.ip"]` or `Attributes["net.host.ip"]` |
| cloud.account.id |
string |
ID of the account in the given cloud |
- resource["cloud.account.id"] |
+ `Resource["cloud.account.id"]` |
| cloud.availability_zone |
string |
Availability zone in which this host is running. |
- resource["cloud.zone"] |
+ `Resource["cloud.zone"]` |
| cloud.instance.id |
@@ -1124,31 +1124,31 @@ Rest of SDIDs -> Attributes["syslog.*"]
cloud.provider |
string |
Name of the cloud provider. Example values are aws, azure, gcp, or digitalocean. |
- resource["cloud.provider"] |
+ `Resource["cloud.provider"]` |
| cloud.region |
string |
Region in which this host is running. |
- resource["cloud.region"] |
+ `Resource["cloud.region"]` |
| cloud.image.id* |
string |
|
- resource["host.image.name"] |
+ `Resource["host.image.name"]` |
| container.id |
string |
Unique container id |
- resource["container.id"] |
+ `Resource["container.id"]` |
| container.image.name |
string |
Name of the image the container was built on. |
- resource["container.image.name"] |
+ `Resource["container.image.name"]` |
| container.image.tag |
@@ -1166,7 +1166,7 @@ Rest of SDIDs -> Attributes["syslog.*"]
container.name |
string |
Container name. |
- resource["container.name"] |
+ `Resource["container.name"]` |
| container.runtime |
@@ -1178,31 +1178,31 @@ Rest of SDIDs -> Attributes["syslog.*"]
destination.address |
string |
Destination address for the event |
- attributes["destination.address"] |
+ `Attributes["destination.address"]` |
| error.code |
string |
Error code describing the error. |
- attributes["error.code"] |
+ `Attributes["error.code"]` |
| error.id |
string |
Unique identifier for the error. |
- attributes["error.id"] |
+ `Attributes["error.id"]` |
| error.message |
string |
Error message. |
- attributes["error.message"] |
+ `Attributes["error.message"]` |
| error.stack_trace |
string |
The stack trace of this error in plain text. |
- attributes["error.stack_trace] |
+ `Attributes["error.stack_trace] |
| host.architecture |
@@ -1226,26 +1226,26 @@ For example, on Windows this could be the host’s Active Directory domain or Ne
It normally contains what the hostname command returns on the host machine.
-resource["host.hostname"] |
+`Resource["host.hostname"]` |
| host.id |
string |
Unique host id. |
- resource["host.id"] |
+ `Resource["host.id"]` |
| host.ip |
Array of string |
Host IP |
- resource["host.ip"] |
+ `Resource["host.ip"]` |
| host.mac |
array of string |
MAC addresses of the host |
- resource["host.mac"] |
+ `Resource["host.mac"]` |
| host.name |
@@ -1254,14 +1254,14 @@ It normally contains what the hostname command returns on the host machine.
It may contain what hostname returns on Unix systems, the fully qualified, or a name specified by the user.
-resource["host.name"] |
+`Resource["host.name"]` |
| host.type |
string |
Type of host. |
- resource["host.type"] |
+ `Resource["host.type"]` |
| host.uptime |
@@ -1287,19 +1287,19 @@ It may contain what hostname returns on Unix systems, the fully qualified, or a
service.name |
string |
Name of the service data is collected from. |
- resource["service.name"] |
+ `Resource["service.name"]` |
| service.node.name |
string |
Specific node serving that service |
- resource["service.instance.id"] |
+ `Resource["service.instance.id"]` |
| service.state |
string |
Current state of the service. |
- attributes["service.state"] |
+ `Attributes["service.state"]` |
| service.type |
@@ -1311,7 +1311,7 @@ It may contain what hostname returns on Unix systems, the fully qualified, or a
service.version |
string |
Version of the service the data was collected from. |
- resource["service.version"] |
+ `Resource["service.version"]` |
|
diff --git a/oteps/metrics/0088-metric-instrument-optional-refinements.md b/oteps/metrics/0088-metric-instrument-optional-refinements.md
index c96f573a3c2..6e3dd5aab85 100644
--- a/oteps/metrics/0088-metric-instrument-optional-refinements.md
+++ b/oteps/metrics/0088-metric-instrument-optional-refinements.md
@@ -246,7 +246,7 @@ properties, it is natural to compute the sum.
When performing spatial aggregation over data without additive
properties, it is natural to combine the distributions. The
distinction is about how we interpret the values when aggregating.
-Use one of the sum-only refinments to report a sum in the default
+Use one of the sum-only refinements to report a sum in the default
configuration, otherwise use one of the non-sum-only instruments to
report a distribution.
@@ -260,7 +260,7 @@ to type names like `Int64Measure` and `Float64Measure`.
A language with support for unsigned integer types may wish to create
dedicated instruments to report these values, leading to type names
like `UnsignedInt64Observer` and `UnsignedFloat64Observer`. These
-would naturally apply a non-negative refinment.
+would naturally apply a non-negative refinement.
Other uses for built-in type refinements involve the type for duration
measurements. For example, where there is built-in type for the
@@ -280,7 +280,7 @@ instrument. There are a total of twelve hypothetical instruments
listed in the table below, of which only one has been standardized.
Hypothetical future instrument names are _italicized_.
-| Foundation instrument | Sum-only? | Precomputed-sum? | Non-negative? | Non-negative-rate? | Instrument name _(hyptothetical)_ |
+| Foundation instrument | Sum-only? | Precomputed-sum? | Non-negative? | Non-negative-rate? | Instrument name _(hypothetical)_ |
| --- | ---- | ---- | ---- | --- | --- |
| Measure | sum-only | | non-negative | non-negative-rate | Counter |
| Measure | sum-only | precomputed-sum | | non-negative-rate | _CumulativeCounter_ |
@@ -296,7 +296,7 @@ Hypothetical future instrument names are _italicized_.
| Observer | | | | | _LastValueObserver_ |
To arrive at this listing, several assumptions have been made. For
-example, the precomputed-sum and non-negative-rate refeinments are
+example, the precomputed-sum and non-negative-rate refinements are
only applicable in conjunction with a sum-only refinement.
For the precomputed-sum instruments, we technically do not care
@@ -352,7 +352,7 @@ one of the additive methods (`Inc`, `Dec`, `Add`, and `Sub`).
If we restrict Prometheus Gauges to support only a `Set` method, or to
support only the additive methods, then we can model these two
-instruments seprately, in a way that is compatible with OpenTelemetry.
+instruments separately, in a way that is compatible with OpenTelemetry.
A Prometheus Gauge that is used exclusively with `Set()` can be
modeled as a Measure instrument with Last Value aggregation. A
Prometheus Gauge that is used exclusively with the additive methods be
@@ -464,7 +464,7 @@ We have identified important cases that should be standardized:
Observer refinements that could be standardized in the future:
-- _UpDownCumulativeObserver_: Observe a non-monotonic cumluative counter
+- _UpDownCumulativeObserver_: Observe a non-monotonic cumulative counter
- _UpDownDeltaObserver_: Observe positive and negative deltas
- _AbsoluteLastValueObserver_: Observe non-negative current values.
diff --git a/oteps/metrics/0090-remove-labelset-from-metrics-api.md b/oteps/metrics/0090-remove-labelset-from-metrics-api.md
index aedeef3bea4..e6070d2d8fb 100644
--- a/oteps/metrics/0090-remove-labelset-from-metrics-api.md
+++ b/oteps/metrics/0090-remove-labelset-from-metrics-api.md
@@ -20,7 +20,7 @@ cleaner code and OpenTelemetry needs to address them as well, so this means that
it is important for OpenTelemetry to support record APIs where users can pass
directly the labels.
-OpenTelementry can always add this optimization later (backwards compatible
+OpenTelemetry can always add this optimization later (backwards compatible
change) if we determine that it is very important to have.
## Trade-offs and mitigations
diff --git a/oteps/metrics/0098-metric-instruments-explained.md b/oteps/metrics/0098-metric-instruments-explained.md
index b6429cd41e1..5b0f77da66d 100644
--- a/oteps/metrics/0098-metric-instruments-explained.md
+++ b/oteps/metrics/0098-metric-instruments-explained.md
@@ -205,7 +205,7 @@ This proposal continues to specify the use of MinMaxSumCount for these two instr
There has been a question about labeling `ValueObserver` measurements with the temporal quality Delta vs. Instantaneous. There is a related question: What does it mean aggregate a Min and Max value for an asynchronous instrument, which may only produce one measurement per collection interval?
-The purpose of defining the default aggregation, when there is only one measurement per interval, is to specify how values will be aggregated across multiple collection intervals. When there is no aggregation being applied, the result of MinMaxSumCount aggregation for a single collection interval is a single measurement equal to the Min, the Max, and the Sum, as well as a Count equal to 1. Before we apply aggregation to a `ValueObserver` measurement, we can clearly define it as an Intantaneous measurement. A measurement, captured at an instant near the end of the collection interval, is neither a cumulative nor a delta with respect to the prior collection interval.
+The purpose of defining the default aggregation, when there is only one measurement per interval, is to specify how values will be aggregated across multiple collection intervals. When there is no aggregation being applied, the result of MinMaxSumCount aggregation for a single collection interval is a single measurement equal to the Min, the Max, and the Sum, as well as a Count equal to 1. Before we apply aggregation to a `ValueObserver` measurement, we can clearly define it as an Instantaneous measurement. A measurement, captured at an instant near the end of the collection interval, is neither a cumulative nor a delta with respect to the prior collection interval.
[OTEP 88][otep-88] discusses the Last Value relationship to help address this question. After capturing a single `ValueObserver` measurement for a given instrument and label set, that measurement becomes the Last value associated with that instrument until the next measurement is taken.
@@ -224,7 +224,7 @@ Aggregating `ValueObserver` measurements across both spatial and time dimensions
3. For each distinct label set and timestamp, compute the spatial aggregation using the last-value definition at that timestamp. This results in a set of timestamped aggregate measurements with comparable counts.
4. Aggregate the timestamped measurements from step 3.
-Steps 2 and 3 ensure that measurements taken less frequently have equal representation in the output, by virtue of computing the spatial aggregation first. If we were to compute the temporal aggregation first, then aggreagate across spatial dimensions, then instruments collected at a higher frequency will contribute correspondingly more points to the aggregation. Thus, we must aggregate across `ValueObserver` instruments across spatial dimensions before averaging across time.
+Steps 2 and 3 ensure that measurements taken less frequently have equal representation in the output, by virtue of computing the spatial aggregation first. If we were to compute the temporal aggregation first, then aggregate across spatial dimensions, then instruments collected at a higher frequency will contribute correspondingly more points to the aggregation. Thus, we must aggregate across `ValueObserver` instruments across spatial dimensions before averaging across time.
## Open Questions
@@ -242,7 +242,7 @@ This may be revisited in the future.
A cumulative measurement can be converted into delta measurement by remembering the last-reported value. A helper instrument could offer to emulate synchronous cumulative measurements by remembering the last-reported value and reporting deltas synchronously.
-A delta measurement can be converted into a cumluative measurement by remembering the sum of all reported values. A helper instrument could offer to emulate asynchronous delta measurements in this way.
+A delta measurement can be converted into a cumulative measurement by remembering the sum of all reported values. A helper instrument could offer to emulate asynchronous delta measurements in this way.
Should helpers of this nature be standardized, if there is demand? These helpers are excluded from the standard because they carry a number of caveats, but as helpers they can easily do what an OpenTelemery SDK cannot do in general. For example, we are avoiding synchronous cumulative instruments because they seem to imply ordering that an SDK is not required to support, however an instrument helper that itself uses a lock can easily convert to deltas.
diff --git a/oteps/profiles/0212-profiling-vision.md b/oteps/profiles/0212-profiling-vision.md
index 8ce90303444..2cadd225986 100644
--- a/oteps/profiles/0212-profiling-vision.md
+++ b/oteps/profiles/0212-profiling-vision.md
@@ -151,7 +151,7 @@ However, the output of OpenTelemetry's standardization effort must take into
account that some existing profilers are designed to be low overhead and high
performance. For example, they may operate in a whole-datacenter, always-on
manner, and/or in environments where they must guarantee low CPU/RAM/network
-usage. The OpenTelemetry standardisation effort should take this into account
+usage. The OpenTelemetry standardization effort should take this into account
and strive to produce a format that is usable by profilers of this nature
without sacrificing their performance guarantees.
diff --git a/oteps/profiles/0239-profiles-data-model.md b/oteps/profiles/0239-profiles-data-model.md
index dff615e8a20..a4a0458e81f 100644
--- a/oteps/profiles/0239-profiles-data-model.md
+++ b/oteps/profiles/0239-profiles-data-model.md
@@ -1129,7 +1129,7 @@ Offset in the binary that corresponds to the first mapped address.
The object this entry is loaded from. This can be a filename on
disk for the main binary and shared libraries, or virtual
-abstractions like "[vdso]".
+abstractions like "[vDSO]".
##### Field `build_id`
diff --git a/oteps/trace/0002-remove-spandata.md b/oteps/trace/0002-remove-spandata.md
index 1a7c9b5b61e..75e5727cdd4 100644
--- a/oteps/trace/0002-remove-spandata.md
+++ b/oteps/trace/0002-remove-spandata.md
@@ -12,7 +12,7 @@ SpanData has a couple of use cases.
The first use case revolves around creating a span synchronously but needing to change the start time to a more accurate timestamp. For example, in an HTTP server, you might record the time the first byte was received, parse the headers, determine the span name, and then create the span. The moment the span was created isn't representative of when the request actually began, so the time the first byte was received would become the span's start time. Since the current API doesn't allow start timestamps, you'd need to create a SpanData object. The big downside is that you don't end up with an active span object.
-The second use case comes from the need to construct and report out of band spans, meaning that you're creating "custom" spans for an operation you don't own. One good example of this is a span sink that takes in structured logs that contain correlation IDs and a duration (e.g. from splunk) and converts them to spans for your tracing system. Another example is running a sidecar on an HAProxy machine, tailing the request logs, and creating spans. SpanData allows you to report the out of band reporting case, whereas you can’t with the current Span API as you cannot set the start and end timestamp.
+The second use case comes from the need to construct and report out of band spans, meaning that you're creating "custom" spans for an operation you don't own. One good example of this is a span sink that takes in structured logs that contain correlation IDs and a duration (e.g. from Splunk) and converts them to spans for your tracing system. Another example is running a sidecar on an HAProxy machine, tailing the request logs, and creating spans. SpanData allows you to report the out of band reporting case, whereas you can’t with the current Span API as you cannot set the start and end timestamp.
I'd like to propose getting rid of SpanData and `tracer.recordSpanData()` and replacing it by allowing `tracer.startSpan()` to accept a start timestamp option and `span.end()` to accept end timestamp option. This reduces the API surface, consolidating on a single span type. Options would meet the requirements for out of band reporting.
diff --git a/oteps/trace/0168-sampling-propagation.md b/oteps/trace/0168-sampling-propagation.md
index 723d10b8da9..85444efbb09 100644
--- a/oteps/trace/0168-sampling-propagation.md
+++ b/oteps/trace/0168-sampling-propagation.md
@@ -206,7 +206,7 @@ where `PP` are two bytes of base16 p-value and `RR` are two bytes of
base16 r-value. These values are omitted when they are unknown.
This proposal should be taken as a recommendation and will be modified
-to [match whatever format OpenTelemtry specifies for its
+to [match whatever format OpenTelemetry specifies for its
`tracestate`](https://github.com/open-telemetry/opentelemetry-specification/pull/1852).
The choice of base16 encoding is therefore just a recommendation,
chosen because `traceparent` uses base16 encoding.
@@ -362,7 +362,7 @@ probability is unknown:
The inputs are recognized as out-of-range as follows:
-| Range invariate | Remedy |
+| Range invariant | Remedy |
| -- | -- |
| `p < 0` | drop `p` from tracestate |
| `p > 63` | drop `p` from tracestate |
diff --git a/oteps/trace/0170-sampling-probability.md b/oteps/trace/0170-sampling-probability.md
index 38e1e05a2cf..d7b66556302 100644
--- a/oteps/trace/0170-sampling-probability.md
+++ b/oteps/trace/0170-sampling-probability.md
@@ -155,7 +155,7 @@ interval, begin weighted sampling using the adjusted count of each
span as input weight.
This processor drops spans when the configured rate threshold is
-exceeeded, otherwise it passes spans through with unmodifed adjusted
+exceeded, otherwise it passes spans through with unmodified adjusted
counts.
When the interval expires and the sample frame is considered complete,
@@ -293,7 +293,7 @@ subpopulations being counted. For example, although the estimates for
the rate of spans by distinct name drawn from a one-minute sample may
have high variance, combining an hour of one-minute sample frames into
an aggregate data set is guaranteed to lower variance (assuming the
-numebr of span names stays fixed). It must, because the data remains
+number of span names stays fixed). It must, because the data remains
unbiased, so more data results in lower variance.
### Conveying the sampling probability
@@ -319,7 +319,7 @@ way to understand sampling because larger numbers mean greater
representivity.
Note that it is possible, given this description, to produce adjusted
-counts that are not integers. Adjusted counts are an approximatation,
+counts that are not integers. Adjusted counts are an approximation,
and the expected value of an integer can be a fractional count.
Floating-point adjusted counts can be avoided with the use of
integer-reciprocal inclusion probabilities.
@@ -815,7 +815,7 @@ of composition we assign unknowns `p=64`, which is 1 beyond the range
of the 6-bit that represent known p-values. The assignment of `p=64`
simplifies the formulas below .
-By following these simple rules, any numher of consistent probability
+By following these simple rules, any number of consistent probability
samplers and non-probability samplers can be combined. Starting with
`p=64` representing unknown and `sampled=false`, update the composite
p-value to the minimum value of the prior composite p-value and the
diff --git a/specification/compatibility/opencensus.md b/specification/compatibility/opencensus.md
index fbe3c027d06..18b87ec6998 100644
--- a/specification/compatibility/opencensus.md
+++ b/specification/compatibility/opencensus.md
@@ -63,7 +63,7 @@ Libraries which want a simple migration can choose to replace instrumentation in
Starting with a library using OpenCensus Instrumentation:
-1. Annouce to users the library's transition from OpenCensus to OpenTelemetry, and recommend users adopt OC bridges.
+1. Announce to users the library's transition from OpenCensus to OpenTelemetry, and recommend users adopt OC bridges.
2. Change unit tests to use the OC bridges, and use OpenTelemetry unit testing frameworks.
3. After a notification period, migrate instrumentation line-by-line to OpenTelemetry. The notification period should be long for popular libraries.
4. Remove the OC bridge from unit tests.
@@ -195,11 +195,11 @@ using the OpenCensus <-> OpenTelemetry bridge.
## OpenCensus Binary Context Propagation
-The shim will provide an OpenCensus `BinaryPropogator` implementation which
-maps [OpenCenus binary trace context format](https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#trace-context) to an OpenTelemetry
+The shim will provide an OpenCensus `BinaryPropagator` implementation which
+maps [OpenCensus binary trace context format](https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#trace-context) to an OpenTelemetry
[SpanContext](../overview.md#spancontext).
-This adapter MUST provide an implementation of OpenCensus `BinaryPropogator` to
+This adapter MUST provide an implementation of OpenCensus `BinaryPropagator` to
write OpenCensus binary format using OpenTelemetry's context. This
implementation may be drawn from OpenCensus if applicable.
diff --git a/specification/compatibility/opentracing.md b/specification/compatibility/opentracing.md
index d2b81a5d03d..5a095c1133a 100644
--- a/specification/compatibility/opentracing.md
+++ b/specification/compatibility/opentracing.md
@@ -142,7 +142,7 @@ set to `follows_from` or `child_of`.
If a list of `Span` references is specified, the union of their
`Baggage` values MUST be used as the initial `Baggage` of the newly created
`Span`. It is unspecified which `Baggage` value is used in the case of
-repeated keys. If no such lisf of references is specified, the current
+repeated keys. If no such list of references is specified, the current
`Baggage` MUST be used as the initial value of the newly created `Span`.
If an initial set of tags is specified, the values MUST be set at
diff --git a/specification/compatibility/prometheus_and_openmetrics.md b/specification/compatibility/prometheus_and_openmetrics.md
index 5a8c2ab5ffe..72f525f0b89 100644
--- a/specification/compatibility/prometheus_and_openmetrics.md
+++ b/specification/compatibility/prometheus_and_openmetrics.md
@@ -258,7 +258,7 @@ scope_metrics:
Metrics which do not have any label with `otel_scope_` prefix
MUST be assigned an instrumentation scope identifying the entity performing
the translation from Prometheus to OpenTelemetry (e.g. the collector's
-prometheus receiver).
+Prometheus receiver).
### Resource Attributes
diff --git a/specification/configuration/sdk-environment-variables.md b/specification/configuration/sdk-environment-variables.md
index cf34ca6c5a9..be202a43f43 100644
--- a/specification/configuration/sdk-environment-variables.md
+++ b/specification/configuration/sdk-environment-variables.md
@@ -240,9 +240,9 @@ We define environment variables for setting one or more exporters per signal.
| Name | Description | Default | Type |
|-----------------------|-----------------------------|---------|----------|
-| OTEL_TRACES_EXPORTER | Trace exporter to be used | "otlp" | [Enum][] |
-| OTEL_METRICS_EXPORTER | Metrics exporter to be used | "otlp" | [Enum][] |
-| OTEL_LOGS_EXPORTER | Logs exporter to be used | "otlp" | [Enum][] |
+| OTEL_TRACES_EXPORTER | Trace exporter to be used | `otlp` | [Enum][] |
+| OTEL_METRICS_EXPORTER | Metrics exporter to be used | `otlp` | [Enum][] |
+| OTEL_LOGS_EXPORTER | Logs exporter to be used | `otlp` | [Enum][] |
The implementation MAY accept a comma-separated list to enable setting multiple exporters.
diff --git a/specification/entities/data-model.md b/specification/entities/data-model.md
index 907c8454b8a..06630da065c 100644
--- a/specification/entities/data-model.md
+++ b/specification/entities/data-model.md
@@ -235,7 +235,7 @@ _Note: These examples MAY diverge from semantic conventions._
service.instance.id
service.name
- service.namesapce
+ service.namespace
|
service.version
|
diff --git a/specification/logs/data-model-appendix.md b/specification/logs/data-model-appendix.md
index adfcc3bdb7e..fd6c9658bbc 100644
--- a/specification/logs/data-model-appendix.md
+++ b/specification/logs/data-model-appendix.md
@@ -53,46 +53,46 @@ this data model.
FACILITY |
enum |
Describes where the event originated. A predefined list of Unix processes. Part of event source identity. Example: mail system |
- Attributes["syslog.facility"] |
+ `Attributes["syslog.facility"]` |
| VERSION |
number |
Meta: protocol version, orthogonal to the event. |
- Attributes["syslog.version"] |
+ `Attributes["syslog.version"]` |
| HOSTNAME |
string |
Describes the location where the event originated. Possible values are FQDN, IP address, etc. |
- Resource["host.name"] |
+ `Resource["host.name"]` |
| APP-NAME |
string |
User-defined app name. Part of event source identity. |
- Resource["service.name"] |
+ `Resource["service.name"]` |
| PROCID |
string |
Not well defined. May be used as a meta field for protocol operation purposes or may be part of event source identity. |
- Attributes["syslog.procid"] |
+ `Attributes["syslog.procid"]` |
| MSGID |
string |
Defines the type of the event. Part of event source identity. Example: "TCPIN" |
- Attributes["syslog.msgid"] |
+ `Attributes["syslog.msgid"]` |
| STRUCTURED-DATA |
array of maps of string to string |
- A variety of use cases depending on the SDID:
+ | A variety of use cases depending on the SD-ID:
Can describe event source identity.
Can include data that describes particular occurrence of the event.
Can be meta-information, e.g. quality of timestamp value. |
- SDID origin.swVersion map to Resource["service.version"]. SDID origin.ip map to Attributes["client.address"]. Rest of SDIDs -> Attributes["syslog.*"] |
+ SD-ID origin.swVersion map to `Resource["service.version"]`. SD-ID origin.ip map to `Attributes["client.address"]`. Rest of SD-IDs -> `Attributes["syslog.*"]` |
| MSG |
@@ -127,13 +127,13 @@ Can be meta-information, e.g. quality of timestamp value.
Computer |
string |
The name of the computer on which the event occurred. |
- Resource["host.name"] |
+ `Resource["host.name"]` |
| EventID |
uint |
The identifier that the provider used to identify the event. |
- Attributes["winlog.event_id"] |
+ `Attributes["winlog.event_id"]` |
| Message |
@@ -145,7 +145,7 @@ Can be meta-information, e.g. quality of timestamp value.
Rest of the fields. |
any |
All other fields in the event. |
- Attributes["winlog.*"] |
+ `Attributes["winlog.*"]` |
@@ -168,13 +168,13 @@ Can be meta-information, e.g. quality of timestamp value.
EventType |
string |
Short machine understandable string describing the event type. SignalFx specific concept. Non-namespaced. Example: k8s Event Reason field. |
- Attributes["com.splunk.signalfx.event_type"] |
+ `Attributes["com.splunk.signalfx.event_type"]` |
| Category |
enum |
Describes where the event originated and why. SignalFx specific concept. Example: AGENT. |
- Attributes["com.splunk.signalfx.event_category"] |
+ `Attributes["com.splunk.signalfx.event_category"]` |
| Dimensions |
@@ -211,19 +211,19 @@ We apply this mapping from HEC to the unified model:
host |
string |
The host value to assign to the event data. This is typically the host name of the client that you are sending data from. |
- Resource["host.name"] |
+ `Resource["host.name"]` |
| source |
string |
The source value to assign to the event data. For example, if you are sending data from an app you are developing, you could set this key to the name of the app. |
- Resource["com.splunk.source"] |
+ `Resource["com.splunk.source"]` |
| sourcetype |
string |
The sourcetype value to assign to the event data. |
- Resource["com.splunk.sourcetype"] |
+ `Resource["com.splunk.sourcetype"]` |
| event |
@@ -241,7 +241,7 @@ We apply this mapping from HEC to the unified model:
index |
string |
The name of the index by which the event data is to be indexed. The index you specify here must be within the list of allowed indexes if the token has the indexes parameter set. |
- Attributes["com.splunk.index"] |
+ `Attributes["com.splunk.index"]` |
@@ -258,37 +258,37 @@ When mapping from the unified model to HEC, we apply this additional mapping:
SeverityText |
string |
The severity of the event as a human-readable string. |
- fields['otel.log.severity.text'] |
+ `Fields["otel.log.severity.text"]` |
| SeverityNumber |
string |
The severity of the event as a number. |
- fields['otel.log.severity.number'] |
+ `Fields["otel.log.severity.number"]` |
| Name |
string |
Short event identifier that does not contain varying parts. |
- fields['otel.log.name'] |
+ `Fields["otel.log.name"]` |
| TraceId |
string |
Request trace id. |
- fields['trace_id'] |
+ `Fields["trace_id"]` |
| SpanId |
string |
Request span id. |
- fields['span_id'] |
+ `Fields["span_id"]` |
| TraceFlags |
string |
W3C trace flags. |
- fields['trace_flags'] |
+ `Fields["trace_flags"]` |
@@ -388,37 +388,37 @@ When mapping from the unified model to HEC, we apply this additional mapping:
%a |
string |
Client address |
- Attributes["network.peer.address"] |
+ `Attributes["network.peer.address"]` |
| %A |
string |
Server address |
- Attributes["network.local.address"] |
+ `Attributes["network.local.address"]` |
| %h |
string |
Client hostname. |
- Attributes["client.address"] |
+ `Attributes["client.address"]` |
| %m |
string |
The request method. |
- Attributes["http.request.method"] |
+ `Attributes["http.request.method"]` |
| %v,%p,%U,%q |
string |
Multiple fields that can be composed into URL. |
- Attributes["url.full"] |
+ `Attributes["url.full"]` |
| %>s |
string |
Response status. |
- Attributes["http.response.status_code"] |
+ `Attributes["http.response.status_code"]` |
| All other fields |
@@ -447,25 +447,25 @@ When mapping from the unified model to HEC, we apply this additional mapping:
eventSource |
string |
The service that the request was made to. This name is typically a short form of the service name without spaces plus .amazonaws.com. |
- Resource["service.name"]? |
+ `Resource["service.name"]`? |
| awsRegion |
string |
The AWS region that the request was made to, such as us-east-2. |
- Resource["cloud.region"] |
+ `Resource["cloud.region"]` |
| sourceIPAddress |
string |
The IP address that the request was made from. |
- Attributes["client.address"] |
+ `Attributes["client.address"]` |
| errorCode |
string |
The AWS service error if the request returns an error. |
- Attributes["cloudtrail.error_code"] |
+ `Attributes["cloudtrail.error_code"]` |
| errorMessage |
@@ -477,7 +477,7 @@ When mapping from the unified model to HEC, we apply this additional mapping:
All other fields |
* |
|
- Attributes["cloudtrail.*"] |
+ `Attributes["cloudtrail.*"]` |
@@ -487,7 +487,7 @@ When mapping from the unified model to HEC, we apply this additional mapping:
| ----- | ---- | ----------- | --------------------------- |
| timestamp | string | The time the event described by the log entry occurred. | Timestamp |
| resource | MonitoredResource | The monitored resource that produced this log entry. | Resource |
-| log_name | string | The URL-encoded LOG_ID suffix of the log_name field identifies which log stream this entry belongs to. | Attributes["gcp.log_name"] |
+| log_name | string | The URL-encoded LOG_ID suffix of the log_name field identifies which log stream this entry belongs to. | `Attributes["gcp.log_name"]` |
| json_payload | google.protobuf.Struct | The log entry payload, represented as a structure that is expressed as a JSON object. | Body |
| proto_payload | google.protobuf.Any | The log entry payload, represented as a protocol buffer. | Body |
| text_payload | string | The log entry payload, represented as a Unicode string (UTF-8). | Body |
@@ -495,9 +495,9 @@ When mapping from the unified model to HEC, we apply this additional mapping:
| trace | string | The trace associated with the log entry, if any. | TraceId |
| span_id | string | The span ID within the trace associated with the log entry. | SpanId |
| labels | map | A set of user-defined (key, value) data that provides additional information about the log entry. | Attributes |
-| http_request | HttpRequest | The HTTP request associated with the log entry, if any. | Attributes["gcp.http_request"] |
+| http_request | HttpRequest | The HTTP request associated with the log entry, if any. | `Attributes["gcp.http_request"]` |
| trace_sampled | boolean | The sampling decision of the trace associated with the log entry. | TraceFlags.SAMPLED |
-| All other fields | | | Attributes["gcp.*"] |
+| All other fields | | | `Attributes["gcp.*"]` |
### Elastic Common Schema
@@ -560,37 +560,37 @@ When mapping from the unified model to HEC, we apply this additional mapping:
agent.name |
string |
Name given to the agent |
- Resource["telemetry.sdk.name"] |
+ `Resource["telemetry.sdk.name"]` |
| agent.type |
string |
Type of agent |
- Resource["telemetry.sdk.language"] |
+ `Resource["telemetry.sdk.language"]` |
| agent.version |
string |
Version of agent |
- Resource["telemetry.sdk.version"] |
+ `Resource["telemetry.sdk.version"]` |
| source.ip, client.ip |
string |
The IP address that the request was made from. |
- Attributes["client.address"] |
+ `Attributes["client.address"]` |
| cloud.account.id |
string |
ID of the account in the given cloud |
- Resource["cloud.account.id"] |
+ `Resource["cloud.account.id"]` |
| cloud.availability_zone |
string |
Availability zone in which this host is running. |
- Resource["cloud.zone"] |
+ `Resource["cloud.zone"]` |
| cloud.instance.id |
@@ -614,31 +614,31 @@ When mapping from the unified model to HEC, we apply this additional mapping:
cloud.provider |
string |
Name of the cloud provider. Example values are aws, azure, gcp, or digitalocean. |
- Resource["cloud.provider"] |
+ `Resource["cloud.provider"]` |
| cloud.region |
string |
Region in which this host is running. |
- Resource["cloud.region"] |
+ `Resource["cloud.region"]` |
| cloud.image.id* |
string |
|
- Resource["host.image.name"] |
+ `Resource["host.image.name"]` |
| container.id |
string |
Unique container id |
- Resource["container.id"] |
+ `Resource["container.id"]` |
| container.image.name |
string |
Name of the image the container was built on. |
- Resource["container.image.name"] |
+ `Resource["container.image.name"]` |
| container.image.tag |
@@ -656,7 +656,7 @@ When mapping from the unified model to HEC, we apply this additional mapping:
container.name |
string |
Container name. |
- Resource["container.name"] |
+ `Resource["container.name"]` |
| container.runtime |
@@ -668,31 +668,31 @@ When mapping from the unified model to HEC, we apply this additional mapping:
destination.address |
string |
Destination address for the event |
- Attributes["destination.address"] |
+ `Attributes["destination.address"]` |
| error.code |
string |
Error code describing the error. |
- Attributes["error.code"] |
+ `Attributes["error.code"]` |
| error.id |
string |
Unique identifier for the error. |
- Attributes["error.id"] |
+ `Attributes["error.id"]` |
| error.message |
string |
Error message. |
- Attributes["error.message"] |
+ `Attributes["error.message"]` |
| error.stack_trace |
string |
The stack trace of this error in plain text. |
- Attributes["error.stack_trace] |
+ `Attributes["error.stack_trace] |
| host.architecture |
@@ -710,37 +710,37 @@ When mapping from the unified model to HEC, we apply this additional mapping:
host.name |
string |
Hostname of the host.
It normally contains what the hostname command returns on the host machine. |
- Resource["host.name"] |
+ `Resource["host.name"]` |
| host.id |
string |
Unique host id. |
- Resource["host.id"] |
+ `Resource["host.id"]` |
| host.ip |
Array of string |
Host IP |
- Resource["host.ip"] |
+ `Resource["host.ip"]` |
| host.mac |
array of string |
MAC addresses of the host |
- Resource["host.mac"] |
+ `Resource["host.mac"]` |
| host.name |
string |
Name of the host.
It may contain what hostname returns on Unix systems, the fully qualified, or a name specified by the user. |
- Resource["host.name"] |
+ `Resource["host.name"]` |
| host.type |
string |
Type of host. |
- Resource["host.type"] |
+ `Resource["host.type"]` |
| host.uptime |
@@ -764,19 +764,19 @@ When mapping from the unified model to HEC, we apply this additional mapping:
service.name |
string |
Name of the service data is collected from. |
- Resource["service.name"] |
+ `Resource["service.name"]` |
| service.node.name |
string |
Specific node serving that service |
- Resource["service.instance.id"] |
+ `Resource["service.instance.id"]` |
| service.state |
string |
Current state of the service. |
- Attributes["service.state"] |
+ `Attributes["service.state"]` |
| service.type |
@@ -788,7 +788,7 @@ When mapping from the unified model to HEC, we apply this additional mapping:
service.version |
string |
Version of the service the data was collected from. |
- Resource["service.version"] |
+ `Resource["service.version"]` |
diff --git a/specification/metrics/data-model.md b/specification/metrics/data-model.md
index 362c882a4eb..04b86a05d7d 100644
--- a/specification/metrics/data-model.md
+++ b/specification/metrics/data-model.md
@@ -182,7 +182,7 @@ decisions within the metrics data model.
### Out of Scope Use-cases
-The metrics data model is NOT designed to be a perfect rosetta stone of metrics.
+The metrics data model is NOT designed to be a perfect Rosetta Stone of metrics.
Here are a set of use cases that, while won't be outright unsupported, are not
in scope for key design decisions:
@@ -200,6 +200,7 @@ in scope for key design decisions:
OpenTelemetry fragments metrics into three interacting models:
+
- An Event model, representing how instrumentation reports metric data.
- A Timeseries model, representing how backends store metric data.
- A Metric Stream model, defining the *O*pen*T*e*L*emetry *P*rotocol (OTLP)
@@ -415,7 +416,7 @@ in OTLP consist of the following:
- The time interval is inclusive of the end time.
- Times are specified in Value is UNIX Epoch time in nanoseconds since
`00:00:00 UTC on 1 January 1970`
- - (optional) a set of examplars (see [Exemplars](#exemplars)).
+ - (optional) a set of exemplars (see [Exemplars](#exemplars)).
- (optional) Data point flags (see [Data point flags](#data-point-flags)).
The aggregation temporality is used to understand the context in which the sum
@@ -451,7 +452,7 @@ in OTLP represents a sampled value at a given time. A Gauge stream consists of:
- (optional) A timestamp (`start_time_unix_nano`) which best represents the
first possible moment a measurement could be recorded. This is commonly
set to the timestamp when a metric collection system started.
- - (optional) a set of examplars (see [Exemplars](#exemplars)).
+ - (optional) a set of exemplars (see [Exemplars](#exemplars)).
- (optional) Data point flags (see [Data point flags](#data-point-flags)).
In OTLP, a point within a Gauge stream represents the last-sampled event for a
@@ -498,7 +499,7 @@ Histograms consist of the following:
for buckets and whether not a given observation would be recorded in this
bucket.
- A count of the number of observations that fell within this bucket.
- - (optional) a set of examplars (see [Exemplars](#exemplars)).
+ - (optional) a set of exemplars (see [Exemplars](#exemplars)).
- (optional) Data point flags (see [Data point flags](#data-point-flags)).
Like Sums, Histograms also define an aggregation temporality. The picture above
diff --git a/specification/metrics/sdk_exporters/prometheus.md b/specification/metrics/sdk_exporters/prometheus.md
index 91eef280ec3..b5f2b432321 100644
--- a/specification/metrics/sdk_exporters/prometheus.md
+++ b/specification/metrics/sdk_exporters/prometheus.md
@@ -14,9 +14,9 @@ OpenTelemetry metrics MUST be converted to Prometheus metrics according to the
A Prometheus Exporter SHOULD use
[Prometheus client libraries](https://prometheus.io/docs/instrumenting/clientlibs/)
-for serving Prometheus metrics. This allows the prometheus client to negotiate
+for serving Prometheus metrics. This allows the Prometheus client to negotiate
the [format](https://github.com/prometheus/docs/blob/main/docs/instrumenting/exposition_formats.md)
-of the response using the `Content-Type` header. If a prometheus client library
+of the response using the `Content-Type` header. If a Prometheus client library
is used, the OpenTelemetry Prometheus Exporter SHOULD be modeled as a
[custom Collector](https://prometheus.io/docs/instrumenting/writing_clientlibs/#overall-structure)
so it can be used in conjunction with existing Prometheus instrumentation.
diff --git a/specification/resource/README.md b/specification/resource/README.md
index cbf8d11472a..ef270704dac 100644
--- a/specification/resource/README.md
+++ b/specification/resource/README.md
@@ -87,7 +87,7 @@ storage solution).
For example, in the extreme, OpenTelemery could synthesize a UUID for every
system which produces telemetry. All identifying attributes for Resource and
Entity could be sent via a side channel with known relationships to this UUID.
-While this would optimise the runtime generation and sending of telemetry, it
+While this would optimize the runtime generation and sending of telemetry, it
comes at the cost of downstream storage systems needing to join data back
together either at ingestion time or query time. For high performance use cases,
e.g. alerting, these joins can be expensive.
diff --git a/specification/resource/data-model.md b/specification/resource/data-model.md
index 94bada584c4..5fa43c193cc 100644
--- a/specification/resource/data-model.md
+++ b/specification/resource/data-model.md
@@ -44,6 +44,6 @@ Entity includes its own notion of identity. The identity of a resource is
the set of entities contained within it. Two resources are considered
different if one contains an entity not found in the other.
-Some resources include raw attributes in additon to Entities. Raw attributes are
+Some resources include raw attributes in addition to Entities. Raw attributes are
considered identifying on a resource. That is, if the key-value pairs of
raw attributes are different, then you can assume the resource is different.
diff --git a/specification/trace/tracestate-probability-sampling.md b/specification/trace/tracestate-probability-sampling.md
index 0c433aaac42..0bea3268801 100644
--- a/specification/trace/tracestate-probability-sampling.md
+++ b/specification/trace/tracestate-probability-sampling.md
@@ -264,7 +264,7 @@ randomness value or a dependent source of randomness (it can use
Sampling stages that yield spans with unknown sampling probability,
including parent-based samplers when they encounter a Context with
-no parent thresohld, must erase the OpenTelemetry threshold
+no parent threshold, must erase the OpenTelemetry threshold
value in their output.
Sampling stages should check for consistency when it is a simple test,
@@ -435,6 +435,7 @@ This package demonstrates how to directly calculate integer thresholds from prob
OpenTelemetry SDKs are recommended to use 4 digits of precision by default.
The following table shows values computed by the method above for 1-in-N probability sampling, with precision 3, 4, and 5.
+
| 1-in-N | Input probability | Threshold (precision 3, 4, 5) | Actual probability (precision 3, 4, 5) | Exact Adjusted Count (precision 3, 4, 5) |
| ------- | ------------------ | ---------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------- |
@@ -451,6 +452,7 @@ The following table shows values computed by the method above for 1-in-N probabi
| 10000 | 0.0001 | fff972
fff9724
fff97247 | 0.00010001659393310547
0.00010000169277191162
0.00010000006295740604 | 9998.340882002383
9999.830725674266
9999.99370426336 |
| 100000 | 0.00001 | ffff584
ffff583a
ffff583a5 | 9.998679161071777e-06
1.00000761449337e-05
1.0000003385357559e-05 | 100013.21013412817
99999.238556461
99999.96614643588 |
| 1000000 | 0.000001 | ffffef4
ffffef39
ffffef391 | 9.98377799987793e-07
1.00000761449337e-06
9.999930625781417e-07 | 1.0016248358208955e+06
999992.38556461
1.0000069374699865e+06 |
+
### Converting integer threshold to a `T`-value