* moved deprecated messages to the bottom of metrics.proto to help with
readability (especially for newbies!)
* Declare Logs Beta (#311)
The Log SIG discussed and made a decision to declare Log data model and Log part of OTLP Beta.
(See SIG meeting notes here https://docs.google.com/document/d/1cX5fWXyWqVVzYHSFUymYUfWxUK5hT97gc23w595LmdM/edit#heading=h.28y76as82bvu)
* incorporated feedback from PR review
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* Refine descriptions of Histogram+Summary for explicit OpenMetrics compatibility
Fixes#187.
- Summary data points must record non-negative values
- Histogram sum can only be present if underlying measurements are non-negative. (Opening a bug to expand our API to allow this to present in more scenarios later)
* Update CHANGELOG.md
* Update CHANGELOG.md
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Call out openmetrics specification
* Update metrics.proto
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Co-authored-by: Bogdan Drutu <lazy@splunk.com>
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Add comments about StartTimeUnixNano
* Apply suggestions from code review
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* From review feedback
* more text about unbroken sequence of observations
* Gauge overlap: delta or cumulative
* Update for gauges
* Fixes
* Remove detail text as being for the data model spec
* Remove 134-154
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Contributes to:
https://github.com/open-telemetry/opentelemetry-specification/issues/780https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/3267
Issue https://github.com/open-telemetry/opentelemetry-specification/issues/780
nicely describes why the data type is needed. There are several use cases
for binary data, both for trace and log attributes and for log record Body.
This is a backward compatible addition. After this change is merged no senders
will initially exist that emit binary data. Nevertheless, if such data is received
by the Collector it will correctly pass such data intact through the pipeline
when receiving/sending OTLP (no Collector code changes are needed for this).
We do not yet have binary data type in the OpenTelemetry API, so no existing
sources can emit it yet.
The receivers that do not understand the binary data type should also continue
functioning normally. Collector's current implementation treats any unknown
data type as NULL (and this would apply to binary data type until we teach
the Collector to understand binary specifically). I checked the Collector source
code and this should not result in crashes or overly surprising behavior
(NULL is either ignored or treated as an "unknown" branch in the code which
does not care about it).
We will add full support for binary data to the Collector, particularly to
support translating it correctly to other formats (e.g. Jaeger, which supports
binary type natively).
Note: the addition of this data type to the protocol is not an obligation to
expose the data type in the Attributes API. OTLP has always been a superset of
what is possible to express via the API. The addition of the data type in the
Attributes API should be discussed separately in the specification repo.
This move is explicitly a nod to the OpenMetrics form of Exemplar, which support a similar oneof form, allowing both integer and gauge values to co-exist in a Exemplar.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Setup template for Release Listings
* Add Entries for 0.3.0 to 0.7.0 and unreleased in progress
* Only mentione changes as it related protos, full commit history left
to user including changes in build process and things unrelated to
changes in the protocol or maturity of the protocols.
* Add Errata for consistency sake about stability of certain protos.
Relates to #271
1. Renamed Status.code field to Status.deprecated_code.
2. Renamed StatusCode enum to Status.DeprecatedStatusCode.
3. Introduce new Status.code with corresponding StatusCode enum.
4. Added guidelines about how to use the fields to ensure backward compatibility.
In other protos "dropped" is used to refer to counts of
how many of an item were discarded because did not meet
the spec (such as an attribute key being too long) or
because there is a limit on the total number.
This field is not labels dropped for not conforming to
a spec but labels filtered out because they were not
included in the aggregations definition of labels to
include. So this commit renames to `filtered` instead
of `dropped` to avoid confusion.
This PR does not change any semantics, it just re-organize the protos:
* Removes MetricDescriptor and adds fields to the Metric directly
* Combines MetricDescriptor.Type with specific DataPoints.
This has the following advantages:
* Require only one allocation more than the initial version (v0.4.0). When using gogo proto.
* In-memory representation is smaller than the initial version (v0.4.0).
* Extensible: allows to add new data types in the Metric.
* Groups together metadata and points about different aggregation types.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Bogdan Drutu
Victor Lu
Vamsee Lakamsani
Tigran Najaryan
Josh Suereth
Joshua MacDonald
Rodolfo Carvalho
Josh Suereth
Harold Dost
Fred Moyer
Andrew Hsu
Yuke Zhuge
Gianluca
dengliming
Tristan Sloughter