pax_global_header00006660000000000000000000000064152276742170014527gustar00rootroot0000000000000052 comment=790608c4d51e6ffc12210b541e8514cbed9e91a4 open-telemetry-opentelemetry-proto-790608c/000077500000000000000000000000001522767421700210155ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/.gitattributes000066400000000000000000000007521522767421700237140ustar00rootroot00000000000000* text=auto eol=lf # Export substitution for release archive version identification (#434) VERSION export-subst # Exclude spurious internal tooling and CI files from release tar archives (#604) .agents/ export-ignore .bcr/ export-ignore .github/ export-ignore .vscode/ export-ignore .gitignore export-ignore .lychee.toml export-ignore .markdownlint.yaml export-ignore buf.yaml export-ignore dependencies.Dockerfile export-ignore package.json export-ignore package-lock.json export-ignore open-telemetry-opentelemetry-proto-790608c/CHANGELOG.md000066400000000000000000000561131522767421700226340ustar00rootroot00000000000000# Changelog The full list of changes can be found in the compare view for the respective release at . ## Unreleased ### Added ### Changed ### Fixed ### Removed ## 1.11.0 - 2026-07-21 ### Added - docs: add request size limitation for HTTP body and gRPC messages. [#782](https://github.com/open-telemetry/opentelemetry-proto/pull/782) - docs: add response size limitation for HTTP body and gRPC messages. [#781](https://github.com/open-telemetry/opentelemetry-proto/pull/781), [#800](https://github.com/open-telemetry/opentelemetry-proto/pull/800), [#801](https://github.com/open-telemetry/opentelemetry-proto/pull/801), [#802](https://github.com/open-telemetry/opentelemetry-proto/pull/802) - processcontext: add `ProcessContext` message described in [OTEP 4719](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/4719-process-ctx.md). [#783](https://github.com/open-telemetry/opentelemetry-proto/pull/783) ### Fixed - docs: clarify that `Retry-After` header value can be an HTTP-date. [#806](https://github.com/open-telemetry/opentelemetry-proto/pull/806) ## 1.10.0 - 2026-03-09 ### Added - profiles: introduce reference based attributes [#733](https://github.com/open-telemetry/opentelemetry-proto/pull/733) ### Changed - docs: Add more clarity to experiments. [#771](https://github.com/open-telemetry/opentelemetry-proto/pull/771) - profiles: clarify Sample message usage guidance docs. [#742](https://github.com/open-telemetry/opentelemetry-proto/pull/742) - profiles: improve Sample message clarity and usage documentation. [#724](https://github.com/open-telemetry/opentelemetry-proto/pull/724) - profiles: clarify the profile and sample timestamps relationship. [#744](https://github.com/open-telemetry/opentelemetry-proto/pull/744) - common: rename ref suffix to strindex [#768](https://github.com/open-telemetry/opentelemetry-proto/pull/768) ### Fixed - examples: Represent uint64 and fixed64 fields as strings in metrics.json. [#748](https://github.com/open-telemetry/opentelemetry-proto/pull/748) - logs: `SEVERITY_NUMBER_UNSPECIFIED` can be used as the `severity_number` field is optional. [#736](https://github.com/open-telemetry/opentelemetry-proto/pull/736) ## 1.9.0 - 2025-10-31 ### Added - profiles: drop field profile.comment_strindices. [#729](https://github.com/open-telemetry/opentelemetry-proto/pull/729) - profiles: clarify the original payload field comments. [#722](https://github.com/open-telemetry/opentelemetry-proto/pull/722) - profiles: add a note about cardinality implications for attribute values. [#713](https://github.com/open-telemetry/opentelemetry-proto/pull/713) ### Changed - profiles: clarify dictionary guidelines: duplicates and other restrictions. [#732](https://github.com/open-telemetry/opentelemetry-proto/pull/732) - profiles: clarify the original payload field comments. [#722](https://github.com/open-telemetry/opentelemetry-proto/pull/722) - profiles: rename line -> lines and sample -> samples since they are repeated fields. [#712](https://github.com/open-telemetry/opentelemetry-proto/pull/712) - profiles: document more explicitly the dictionary zero element requirement. [#711](https://github.com/open-telemetry/opentelemetry-proto/pull/711) - all: drop attribute values restrictions. [#707](https://github.com/open-telemetry/opentelemetry-proto/pull/707)
⚠️ **IMPORTANT**: OTLP consumers are expected to accept attribute values that were previously considered invalid. All attributes can now contain: - empty values, - bytes values, - array values different than array of string values, bool values, int values, double values, - kvlist values. ### Fixed - all: fix schema_url comments to include scope field coverage. [#727](https://github.com/open-telemetry/opentelemetry-proto/pull/727) - all: add missing field comments. [#717](https://github.com/open-telemetry/opentelemetry-proto/pull/717) ### Removed - profiles: drop field profile.comment_strindices. [#729](https://github.com/open-telemetry/opentelemetry-proto/pull/729) - profiles: remove aggregation temporality enum and field. [#710](https://github.com/open-telemetry/opentelemetry-proto/pull/710) ## 1.8.0 - 2025-09-02 ### Changed - profiles: drop gzip requirement. [#661](https://github.com/open-telemetry/opentelemetry-proto/pull/661) - profiles: avoid `optional` keyword usage. [#659](https://github.com/open-telemetry/opentelemetry-proto/pull/659) - profiles: make `profile_id` optional. [#665](https://github.com/open-telemetry/opentelemetry-proto/pull/665) - profiles: use single `Profile.sample_type` and clarify use of timestamps. [#649](https://github.com/open-telemetry/opentelemetry-proto/pull/649) - all: add notes about the attribute values restrictions. [#683](https://github.com/open-telemetry/opentelemetry-proto/pull/683)
⚠️ **IMPORTANT**: These restrictions can be dropped in a future minor release. - profiles: clarify usage of the zero value as the first element of tables in `ProfilesDictionary`. [#688](https://github.com/open-telemetry/opentelemetry-proto/pull/688), [#698](https://github.com/open-telemetry/opentelemetry-proto/pull/698) - profiles: unsigned `time_nanos` and `duration_nanos` in `Profile`. [#692](https://github.com/open-telemetry/opentelemetry-proto/pull/692) - profiles: improve attribute encoding in `ProfilesDictionary`. [#672](https://github.com/open-telemetry/opentelemetry-proto/pull/672) - profiles: simplify profile stack trace representation. [#708](https://github.com/open-telemetry/opentelemetry-proto/pull/708) ### Fixed - examples: fix OTLP JSON Event example body. [#666](https://github.com/open-telemetry/opentelemetry-proto/pull/666) - docs: minor specification fixes around `UNAVAILABLE` and `RetryInfo`. [#669](https://github.com/open-telemetry/opentelemetry-proto/pull/669) ### Removed - profiles: remove `default_sample_type`. [#679](https://github.com/open-telemetry/opentelemetry-proto/pull/679) - profiles: remove `has_*` debug info fields, they are moving to attributes. [#595](https://github.com/open-telemetry/opentelemetry-proto/pull/595) - profiles: remove `Location.is_folded`. [#690](https://github.com/open-telemetry/opentelemetry-proto/pull/690) ## 1.7.0 - 2025-05-19 ### Added - profiles: introduce Dictionary message in ProfilesData, and move the lookup tables into it. [#650](https://github.com/open-telemetry/opentelemetry-proto/pull/650) ## 1.6.0 - 2025-04-29 ### Added - resource: Add EntityRef. [#635](https://github.com/open-telemetry/opentelemetry-proto/pull/635) ### Changed - logs: Stabilize `event_name` field in `LogRecord` message. [#643](https://github.com/open-telemetry/opentelemetry-proto/pull/643) - profiles: Move the lookup tables to ProfilesData. [#644](https://github.com/open-telemetry/opentelemetry-proto/pull/644) - profiles: Move default sample_type from the string table to sample_type. [#620](https://github.com/open-telemetry/opentelemetry-proto/pull/620) ## 1.5.0 - 2024-12-12 ### Added - all: Add note about `schema_url` format (including version). [#605](https://github.com/open-telemetry/opentelemetry-proto/pull/605) - logs: Add top-level `event_name` field to log records instead of `event.name` attribute. [#600](https://github.com/open-telemetry/opentelemetry-proto/pull/600) ### Removed - profiles: Remove unused `Label` definition. [#602](https://github.com/open-telemetry/opentelemetry-proto/pull/602) - profiles: drop duplicate `attributes` field in message Profile. [#606](https://github.com/open-telemetry/opentelemetry-proto/pull/606) ## 1.4.0 - 2024-11-20 ### Added * metrics: Add resource attributes and scope to metrics proto diagram. [#519](https://github.com/open-telemetry/opentelemetry-proto/pull/519) * metrics: Added json example for exponential histogram. [#580](https://github.com/open-telemetry/opentelemetry-proto/pull/580) ### Changed * metrics: Clarify aggregation temporality for Summary metric type. [#591](https://github.com/open-telemetry/opentelemetry-proto/pull/591) * docs: Remove HTTP 1.1 restriction from Protocol Details [#571](https://github.com/open-telemetry/opentelemetry-proto/pull/571) * docs: Update specification to include development profiles [#582](https://github.com/open-telemetry/opentelemetry-proto/pull/582) * docs: update references to logging exporter [#581](https://github.com/open-telemetry/opentelemetry-proto/pull/581) * Makefile: exclude Profiles protocol from breaking-changes [#576](https://github.com/open-telemetry/opentelemetry-proto/pull/576) * Makefile: exclude Profiles service from breaking changes too [#586](https://github.com/open-telemetry/opentelemetry-proto/pull/586/) * profiles: align type of index into string table [#557](https://github.com/open-telemetry/opentelemetry-proto/pull/557) * profiles: drop Sample.stacktrace_id_index [#575](https://github.com/open-telemetry/opentelemetry-proto/pull/575) * profiles: drop BuildIdKind [#584](https://github.com/open-telemetry/opentelemetry-proto/pull/584) * profiles: drop Sample.label [#583](https://github.com/open-telemetry/opentelemetry-proto/pull/583) * profiles: drop Location.type_index [#578](https://github.com/open-telemetry/opentelemetry-proto/pull/578) * profiles: Rename profiles v1experimental to v1development [#585](https://github.com/open-telemetry/opentelemetry-proto/pull/585) * profiles: Make mapping in Profile optional [#556](https://github.com/open-telemetry/opentelemetry-proto/pull/556) * profiles: Fold the content of pprofextended.proto into profiles.proto, removing ProfileContainer. [#590](https://github.com/open-telemetry/opentelemetry-proto/pull/590) * profiles: Improve lookup table pattern use in profiles. [#592](https://github.com/open-telemetry/opentelemetry-proto/pull/592) * profiles: Renovations to experimental profiling schema. [#596](https://github.com/open-telemetry/opentelemetry-proto/pull/596) ## 1.3.2 - 2024-06-28 ### Changed * profiles: add missing java_package option to pprofextended. [#558](https://github.com/open-telemetry/opentelemetry-proto/pull/558) ## 1.3.1 - 2024-05-07 ### Changed * profiles: fix versioning in selector. [#551](https://github.com/open-telemetry/opentelemetry-proto/pull/551) ## 1.3.0 - 2024-04-24 ### Added * Add new profile signal. [#534](https://github.com/open-telemetry/opentelemetry-proto/pull/534) ## 1.2.0 - 2024-03-29 ### Added * Indicate if a `Span`'s parent or link is remote using 2 bit flag. [#484](https://github.com/open-telemetry/opentelemetry-proto/pull/484) * Add metric.metadata for supporting additional metadata on metrics [#514](https://github.com/open-telemetry/opentelemetry-proto/pull/514) * Add example of an Event [#538](https://github.com/open-telemetry/opentelemetry-proto/pull/538) ### Changed ## 1.1.0 - 2024-01-10 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v1.0.0...v1.1.0). ### Added * Add `flags` field to `Span` and `Span/Link` for W3C-specified Trace Context flags. [#503](https://github.com/open-telemetry/opentelemetry-proto/pull/503) ### Changed * Update and fix OTLP JSON examples. [#516](https://github.com/open-telemetry/opentelemetry-proto/pull/516), [#510](https://github.com/open-telemetry/opentelemetry-proto/pull/510), [#499](https://github.com/open-telemetry/opentelemetry-proto/pull/499) * Remove irrelevant comments from metric name field. [#512](https://github.com/open-telemetry/opentelemetry-proto/pull/512) * Add comment to explain schema_url fields. [#504](https://github.com/open-telemetry/opentelemetry-proto/pull/504) ## 1.0.0 - 2023-07-03 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.20.0...v1.0.0). ### Maturity * Add note about the possibility to have unstable components after 1.0.0 [#489](https://github.com/open-telemetry/opentelemetry-proto/pull/489) * Add maturity JSON entry per package [#490](https://github.com/open-telemetry/opentelemetry-proto/pull/490) ## 0.20.0 - 2023-06-06 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.19.0...v0.20.0). ### Maturity * Declare OTLP/JSON Stable. [#436](https://github.com/open-telemetry/opentelemetry-proto/pull/436) [#435](https://github.com/open-telemetry/opentelemetry-proto/pull/435) * Provide stronger symbolic stability guarantees. [#432](https://github.com/open-telemetry/opentelemetry-proto/pull/432) * Clarify how additive changes are handled. [#455](https://github.com/open-telemetry/opentelemetry-proto/pull/455) ### Changed * Change the exponential histogram boundary condition. [#409](https://github.com/open-telemetry/opentelemetry-proto/pull/409) * Clarify behavior for empty/not present/invalid trace_id and span_id fields. [#442](https://github.com/open-telemetry/opentelemetry-proto/pull/442) * Change the collector trace endpoint to /v1/traces. [#449](https://github.com/open-telemetry/opentelemetry-proto/pull/449) ### Added * Introduce `zero_threshold` field to `ExponentialHistogramDataPoint`. [#441](https://github.com/open-telemetry/opentelemetry-proto/pull/441) [#453](https://github.com/open-telemetry/opentelemetry-proto/pull/453) ### Removed * Delete requirement to generate new trace/span id if an invalid id is received. [#444](https://github.com/open-telemetry/opentelemetry-proto/pull/444) ## 0.19.0 - 2022-08-03 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.18.0...v0.19.0). ### Changed * Add `csharp_namespace` option to protos. ([#399](https://github.com/open-telemetry/opentelemetry-proto/pull/399)) * Fix some out-of-date urls which link to [specification](https://github.com/open-telemetry/opentelemetry-specification). ([#402](https://github.com/open-telemetry/opentelemetry-proto/pull/402)) * :stop_sign: [BREAKING] Delete deprecated InstrumentationLibrary, InstrumentationLibraryLogs, InstrumentationLibrarySpans and InstrumentationLibraryMetrics messages. Delete deprecated instrumentation_library_logs, instrumentation_library_spans and instrumentation_library_metrics fields. ### Added * Introduce Scope Attributes. [#395](https://github.com/open-telemetry/opentelemetry-proto/pull/395) * Introduce partial success fields in `ExportServiceResponse`. [#414](https://github.com/open-telemetry/opentelemetry-proto/pull/414) ## 0.18.0 - 2022-05-17 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.17.0...v0.18.0). ### Changed * Declare logs Stable. [(#376)](https://github.com/open-telemetry/opentelemetry-proto/pull/376) * Metrics ExponentialHistogramDataPoint makes the `sum` optional (follows the same change in HistogramDataPOint in 0.15). [#392](https://github.com/open-telemetry/opentelemetry-proto/pull/392) ## 0.17.0 - 2022-05-06 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.16.0...v0.17.0). ### Changed * Introduce optional `min` and `max` fields to the Histogram and ExponentialHistogram data points. [(#279)](https://github.com/open-telemetry/opentelemetry-proto/pull/279) ## 0.16.0 - 2022-03-31 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.15.0...v0.16.0). ### Removed * Remove deprecated LogRecord.Name field (#373). ## 0.15.0 - 2022-03-19 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.14.0...v0.15.0). ### Changed * Rename InstrumentationLibrary to InstrumentationScope (#362) ### Added * Use optional for `sum` field to mark presence (#366) ## 0.14.0 - 2022-03-08 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.13.0...v0.14.0). ### Removed * Deprecate LogRecord.Name field (#357) ## 0.13.0 - 2022-02-10 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.12.0...v0.13.0). ### Changed * `Swagger` generation updated to `openapiv2` due to the use of an updated version of protoc in `otel/build-protobuf` * Clarify attribute key uniqueness requirement (#350) * Fix path to Go packages (#360) ### Added * Add ObservedTimestamp to LogRecord. (#351) * Add native kotlin support (#337) ### Removed * Remove unused deprecated message StringKeyValue (#358) * Remove experimental metrics config service (#359) ## 0.12.0 - 2022-01-19 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.11.0...v0.12.0). ### Changed * Rename logs to log_records in InstrumentationLibraryLogs. (#352) ### Removed * Remove deprecated messages and fields from traces. (#341) * Remove deprecated messages and fields from metrics. (#342) ## 0.11.0 - 2021-10-07 Full list of differences found in [this compare](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.10.0...v0.11.0). ### Added * ExponentialHistogram is a base-2 exponential histogram described in [OTEP 149](https://github.com/open-telemetry/oteps/pull/149). (#322) * Adds `TracesData`, `MetricsData`, and `LogsData` container types for common use in transporting multiple `ResourceSpans`, `ResourceMetrics`, and `ResourceLogs`. (#332) ## 0.10.0 - 2021-09-07 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.9.0...v0.10.0) ### Maturity * `collector/logs/*` is now considered `Beta`. (#311) * `logs/*` is now considered `Beta`. (#311) ### Added * Metrics data points add a `flags` field with one bit to represent explicitly missing data. (#316) ## 0.9.0 - 2021-04-12 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.8.0...v0.9.0) ### Maturity * `collector/metrics/*` is now considered `stable`. (#305) ### Changed: Metrics * :stop_sign: [DATA MODEL CHANGE] Histogram/Summary sums must be monotonic counters of events (#302) * :stop_sign: [DATA MODEL CHANGE] Clarify requirements and semantics for start time (#295) * :stop_sign: [BREAKING] Deprecate `labels` field from NumberDataPoint, HistogramDataPoint, SummaryDataPoint and add equivalent `attributes` field (#283) * :stop_sign: [BREAKING] Deprecate `filtered_labels` field from Exemplars and add equivalent `filtered_attributes` field (#283) ### Added - Common - Add bytes (binary) as data type to AnyValue (#297) - Common - Add schema_url fields as described in OTEP 0152 (#298) ### Removed * Remove if no changes for this section before release. ## 0.8.0 - 2021-03-23 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.7.0...v0.8.0) ### Historical breaking change notice Release 0.8 was the last in the line of releases marked as "unstable". This release broke compatibility in more ways than were recognized and documented at the time of its release. In particular, #278 created the `NumberDataPoint` type and used it in several locations in place of the former `DoubleDataPoint`. The new `oneof` in `NumberDataPoint` re-used the former `DoubleDataPoint` tag number, which means that pre-0.8 `DoubleSum` and `DoubleGauge` points would parse correctly as a 0.8 `Sum` and `Gauge` points containing double-valued numbers. However, by virtue of a `syntax = "proto3"` declaration, the protocol compiler for all versions of OTLP have not included field presence, which means 0 values are not serialized. **The result is that valid OTLP 0.7 `DoubleSum` and `DoubleGauge` points would not parse correctly as OTLP 0.8 data.** Instead, they parse as `NumberDataPoint` with a missing value in the `oneof` field. ### Changed: Metrics * :stop_sign: [DEPRECATION] Deprecate IntSum, IntGauge, and IntDataPoint (#278) * :stop_sign: [DEPRECATION] Deprecate IntExemplar (#281) * :stop_sign: [DEPRECATION] Deprecate IntHistogram (#270) * :stop_sign: [BREAKING] Rename DoubleGauge to Gauge (#278) * :stop_sign: [BREAKING] Rename DoubleSum to Sum (#278) * :stop_sign: [BREAKING] Rename DoubleDataPoint to NumberDataPoint (#278) * :stop_sign: [BREAKING] Rename DoubleSummary to Summary (#269) * :stop_sign: [BREAKING] Rename DoubleExemplar to Exemplar (#281) * :stop_sign: [BREAKING] Rename DoubleHistogram to Histogram (#270) * :stop_sign: [DATA MODEL CHANGE] Make explicit bounds compatible with OM/Prometheus (#262) ## 0.7.0 - 2021-01-28 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.6.0...v0.7.0) ### Maturity $$$Protobuf Encodings:** * `collector/metrics/*` is now considered `Beta`. (#223) * `collector/logs/*` is now considered `Alpha`. (#228) * `logs/*` is now considered `Alpha`. (#228) * `metrics/*` is now considered `Beta`. (#223) ### Changed * Common/Logs/Metrics/Traces - Clarify empty instrumentation (#245) ### Added * Metrics - Add SummaryDataPoint support to Metrics proto (#227) ## 0.6.0 - 2020-10-28 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.5.0...v0.6.0) ### Maturity * Clarify maturity guarantees (#225) ### Changed * Traces - Deprecated old Span status code and added a new status code according to specification (#224) ** Marked for removal `2021-10-22` given Stability Guarantees. * Rename ProbabilitySampler to TraceIdRatioBased (#221) ## 0.5.0 - 2020-08-31 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.4.0...v0.5.0) ### Maturity Changes **Protobuf Encodings:** * `collector/trace/*` is now `Stable`. * `common/*` is now `Stable`. * `resource/*` is now `Stable`. * `trace/trace.proto` is now `Stable`. (#160) **JSON Encodings:** * All messages are now `Alpha`. ### Changed * :stop_sign: [BREAKING] Metrics - protocol was refactored, and lots of breaking changes. * Removed MetricDescriptor and embedded into Metric and the new data types. * Add new data types Gauge/Sum/Histogram. * Make use of the "AggregationTemporality" into the data types that allow that support. * Rename enum values to follow the proto3 style guide. ### Added * Enable build to use docker image otel/build-protobuf to be used in CI. ** Can also be used by the languages to generate protos. ### Removed * :stop_sign: [BREAKING] Remove generated golang structs from the repository ### Errata The following was announced in the release, but has not yet been considered stable. Please see the latest README.md for actual status. > This is a Release Candidate to declare Metrics part of the protocol Stable. ## 0.4.0 - 2020-06-23 Full list of differences found in [this compare.](https://github.com/open-telemetry/opentelemetry-proto/compare/v0.3.0...v0.4.0) ### Changed * Metrics - Add temporality to MetricDescriptor (#140). ### Added * Metrics - Add Monotonic Types (#145) * Common/Traces - Added support for arrays and maps for attribute values (AnyValue) (#157). ### Removed * :stop_sign: [BREAKING] Metrics - Removed common labels from MetricDescriptor (#144). ### Errata The following was announced in the release, but this was not considered Stable until `v0.5.0` > This is a Release Candidate to declare Traces part of the protocol Stable. ## 0.3.0 - 2020-03-23 * Initial protos for trace, metrics, resource and OTLP. open-telemetry-opentelemetry-proto-790608c/CONTRIBUTING.md000066400000000000000000000041661522767421700232550ustar00rootroot00000000000000# Contributing ## Introduction Welcome, and thank you for your interest in contributing to OpenTelemetry's Protobuf definitions! Your contributions — big or small — are invaluable in shaping and improving this essential part of the OpenTelemetry ecosystem. Whether you are fixing a small issue, updating documentation, or introducing a major improvement, we appreciate your efforts. If you're new to the project, don't hesitate to ask questions and seek guidance from the community. We are here to support you! Before contributing, we encourage you to read the OpenTelemetry project [contributing guide](https://github.com/open-telemetry/community/blob/main/guides/contributor/README.md) for general information about the project. ## Prerequisites - `Docker` ## Making changes to the .proto files After making any changes to .proto files make sure to generate all implementation by running `make gen-all`. ## Style-Guide OpenTelemetry follows the [Protobuf style guide](https://protobuf.dev/programming-guides/style/) with the following clarifications: - All Messages and fields should be documented via comments. - Field comments should document purpose or behavior with active verbs, or a simple definition noun phrase (similar to a dictionary entry). - valid: "Represents ..." valid: "Additional attributes that describe the scope." - not-valid: "used to represent..." - Message and field comments may reference the field or message by name. - valid: "AnyValue ..." - valid: "The value ..." ## Further Help If you have any questions or need assistance while contributing, feel free to reach out to the [`#otel-specification`](https://cloud-native.slack.com/archives/C01N7PP1THC) Slack channel. View meeting notes of previous SIG calls in this [google doc](https://docs.google.com/spreadsheets/d/1SYKfjYhZdm2Wh2Cl6KVQalKg_m4NhTPZqq-8SzEVO6s/edit?gid=0#gid=0) as stated [here](https://github.com/open-telemetry/community/?tab=readme-ov-file#governing-bodies) to stay up to date. Also see the [specification](https://github.com/open-telemetry/opentelemetry-specification?tab=readme-ov-file#questions) repo for more info. Thank you. open-telemetry-opentelemetry-proto-790608c/LICENSE000066400000000000000000000261351522767421700220310ustar00rootroot00000000000000 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. open-telemetry-opentelemetry-proto-790608c/Makefile000066400000000000000000000301261522767421700224570ustar00rootroot00000000000000GOPATH_DIR := $(GOPATH)/src/github.com/open-telemetry/opentelemetry-proto GENDIR := gen GOPATH_GENDIR := $(GOPATH_DIR)/$(GENDIR) # Find all .proto files. PROTO_FILES := $(wildcard opentelemetry/proto/*/*/*.proto opentelemetry/proto/*/*/*/*.proto) # Function to execute a command. Note the empty line before endef to make sure each command # gets executed separately instead of concatenated with previous one. # Accepts command to execute as first parameter. define exec-command $(1) endef .PHONY: all all: gen-all markdown-link-check markdownlint markdown-toc # Generate all implementations .PHONY: gen-all gen-all: gen-cpp gen-csharp gen-go gen-java gen-kotlin gen-objc gen-openapi gen-php gen-python gen-ruby DEPENDENCIES_DOCKERFILE=./dependencies.Dockerfile OTEL_DOCKER_PROTOBUF ?= otel/build-protobuf:0.9.0 BUF_DOCKER ?= bufbuild/buf:1.7.0 PROTOC := docker run --rm -u ${shell id -u} -v${PWD}:${PWD} -w${PWD} ${OTEL_DOCKER_PROTOBUF} --proto_path=${PWD} BUF := docker run --rm -v "${PWD}:/workspace" -w /workspace ${BUF_DOCKER} # When checking for protobuf breaking changes, check against the latest release tag LAST_RELEASE_TAG := $(shell git tag --sort=committerdate | tail -1) # Options are described in https://docs.buf.build/breaking/usage#git BUF_AGAINST ?= "https://github.com/open-telemetry/opentelemetry-proto.git\#tag=$(LAST_RELEASE_TAG)" PROTO_GEN_CPP_DIR ?= $(GENDIR)/cpp PROTO_GEN_CSHARP_DIR ?= $(GENDIR)/csharp PROTO_GEN_GO_DIR ?= $(GENDIR)/go PROTO_GEN_JAVA_DIR ?= $(GENDIR)/java PROTO_GEN_JS_DIR ?= $(GENDIR)/js PROTO_GEN_KOTLIN_DIR ?= $(GENDIR)/kotlin PROTO_GEN_OBJC_DIR ?= $(GENDIR)/objc PROTO_GEN_OPENAPI_DIR ?= $(GENDIR)/openapi PROTO_GEN_PHP_DIR ?= $(GENDIR)/php PROTO_GEN_PYTHON_DIR ?= $(GENDIR)/python PROTO_GEN_RUBY_DIR ?= $(GENDIR)/ruby # Docker pull image. .PHONY: docker-pull docker-pull: docker pull $(OTEL_DOCKER_PROTOBUF) docker pull $(BUF_DOCKER) # Generate gRPC/Protobuf implementation for C++. .PHONY: gen-cpp gen-cpp: rm -rf ./$(PROTO_GEN_CPP_DIR) mkdir -p ./$(PROTO_GEN_CPP_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --cpp_out=./$(PROTO_GEN_CPP_DIR) $(file))) $(PROTOC) --cpp_out=./$(PROTO_GEN_CPP_DIR) --grpc-cpp_out=./$(PROTO_GEN_CPP_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --cpp_out=./$(PROTO_GEN_CPP_DIR) --grpc-cpp_out=./$(PROTO_GEN_CPP_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --cpp_out=./$(PROTO_GEN_CPP_DIR) --grpc-cpp_out=./$(PROTO_GEN_CPP_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --cpp_out=./$(PROTO_GEN_CPP_DIR) --grpc-cpp_out=./$(PROTO_GEN_CPP_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for C#. .PHONY: gen-csharp gen-csharp: rm -rf ./$(PROTO_GEN_CSHARP_DIR) mkdir -p ./$(PROTO_GEN_CSHARP_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --csharp_out=./$(PROTO_GEN_CSHARP_DIR) $(file))) $(PROTOC) --csharp_out=./$(PROTO_GEN_CSHARP_DIR) --grpc-csharp_out=./$(PROTO_GEN_CSHARP_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --csharp_out=./$(PROTO_GEN_CSHARP_DIR) --grpc-csharp_out=./$(PROTO_GEN_CSHARP_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --csharp_out=./$(PROTO_GEN_CSHARP_DIR) --grpc-csharp_out=./$(PROTO_GEN_CSHARP_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --csharp_out=./$(PROTO_GEN_CSHARP_DIR) --grpc-csharp_out=./$(PROTO_GEN_CSHARP_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for Go. .PHONY: gen-go gen-go: rm -rf ./$(PROTO_GEN_GO_DIR) mkdir -p ./$(PROTO_GEN_GO_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command,$(PROTOC) --go_out=plugins=grpc:./$(PROTO_GEN_GO_DIR) $(file))) $(PROTOC) --grpc-gateway_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/trace/v1/trace_service_http.yaml:./$(PROTO_GEN_GO_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --grpc-gateway_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/metrics/v1/metrics_service_http.yaml:./$(PROTO_GEN_GO_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --grpc-gateway_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/logs/v1/logs_service_http.yaml:./$(PROTO_GEN_GO_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --grpc-gateway_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/profiles/v1development/profiles_service_http.yaml:./$(PROTO_GEN_GO_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for Java. .PHONY: gen-java gen-java: rm -rf ./$(PROTO_GEN_JAVA_DIR) mkdir -p ./$(PROTO_GEN_JAVA_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --java_out=./$(PROTO_GEN_JAVA_DIR) $(file))) # Generate gRPC/Protobuf implementation for Kotlin. .PHONY: gen-kotlin gen-kotlin: gen-java rm -rf ./$(PROTO_GEN_KOTLIN_DIR) mkdir -p ./$(PROTO_GEN_KOTLIN_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --kotlin_out=./$(PROTO_GEN_KOTLIN_DIR) $(file))) # Generate gRPC/Protobuf implementation for JavaScript. .PHONY: gen-js gen-js: rm -rf ./$(PROTO_GEN_JS_DIR) mkdir -p ./$(PROTO_GEN_JS_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --js_out=import_style=commonjs:./$(PROTO_GEN_JS_DIR) $(file))) $(PROTOC) --js_out=import_style=commonjs:./$(PROTO_GEN_JS_DIR) --grpc-web_out=import_style=commonjs,mode=grpcweb:./$(PROTO_GEN_JS_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --js_out=import_style=commonjs:./$(PROTO_GEN_JS_DIR) --grpc-web_out=import_style=commonjs,mode=grpcweb:./$(PROTO_GEN_JS_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --js_out=import_style=commonjs:./$(PROTO_GEN_JS_DIR) --grpc-web_out=import_style=commonjs,mode=grpcweb:./$(PROTO_GEN_JS_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --js_out=import_style=commonjs:./$(PROTO_GEN_JS_DIR) --grpc-web_out=import_style=commonjs,mode=grpcweb:./$(PROTO_GEN_JS_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for Objective-C. .PHONY: gen-objc gen-objc: rm -rf ./$(PROTO_GEN_OBJC_DIR) mkdir -p ./$(PROTO_GEN_OBJC_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --objc_out=./$(PROTO_GEN_OBJC_DIR) $(file))) $(PROTOC) --objc_out=./$(PROTO_GEN_OBJC_DIR) --grpc-objc_out=./$(PROTO_GEN_OBJC_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --objc_out=./$(PROTO_GEN_OBJC_DIR) --grpc-objc_out=./$(PROTO_GEN_OBJC_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --objc_out=./$(PROTO_GEN_OBJC_DIR) --grpc-objc_out=./$(PROTO_GEN_OBJC_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --objc_out=./$(PROTO_GEN_OBJC_DIR) --grpc-objc_out=./$(PROTO_GEN_OBJC_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf for openapi v2 (swagger) .PHONY: gen-openapi gen-openapi: mkdir -p $(PROTO_GEN_OPENAPI_DIR) $(PROTOC) --openapiv2_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/trace/v1/trace_service_http.yaml:$(PROTO_GEN_OPENAPI_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --openapiv2_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/metrics/v1/metrics_service_http.yaml:$(PROTO_GEN_OPENAPI_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --openapiv2_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/logs/v1/logs_service_http.yaml:$(PROTO_GEN_OPENAPI_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --openapiv2_out=logtostderr=true,grpc_api_configuration=opentelemetry/proto/collector/profiles/v1development/profiles_service_http.yaml:$(PROTO_GEN_OPENAPI_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for PhP. .PHONY: gen-php gen-php: rm -rf ./$(PROTO_GEN_PHP_DIR) mkdir -p ./$(PROTO_GEN_PHP_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --php_out=./$(PROTO_GEN_PHP_DIR) $(file))) $(PROTOC) --php_out=./$(PROTO_GEN_PHP_DIR) --grpc-php_out=./$(PROTO_GEN_PHP_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --php_out=./$(PROTO_GEN_PHP_DIR) --grpc-php_out=./$(PROTO_GEN_PHP_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --php_out=./$(PROTO_GEN_PHP_DIR) --grpc-php_out=./$(PROTO_GEN_PHP_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --php_out=./$(PROTO_GEN_PHP_DIR) --grpc-php_out=./$(PROTO_GEN_PHP_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for Python. .PHONY: gen-python gen-python: rm -rf ./$(PROTO_GEN_PYTHON_DIR) mkdir -p ./$(PROTO_GEN_PYTHON_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --python_out=./$(PROTO_GEN_PYTHON_DIR) $(file))) $(PROTOC) --python_out=./$(PROTO_GEN_PYTHON_DIR) --grpc-python_out=./$(PROTO_GEN_PYTHON_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --python_out=./$(PROTO_GEN_PYTHON_DIR) --grpc-python_out=./$(PROTO_GEN_PYTHON_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --python_out=./$(PROTO_GEN_PYTHON_DIR) --grpc-python_out=./$(PROTO_GEN_PYTHON_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --python_out=./$(PROTO_GEN_PYTHON_DIR) --grpc-python_out=./$(PROTO_GEN_PYTHON_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # Generate gRPC/Protobuf implementation for Ruby. .PHONY: gen-ruby gen-ruby: rm -rf ./$(PROTO_GEN_RUBY_DIR) mkdir -p ./$(PROTO_GEN_RUBY_DIR) $(foreach file,$(PROTO_FILES),$(call exec-command, $(PROTOC) --ruby_out=./$(PROTO_GEN_RUBY_DIR) $(file))) $(PROTOC) --ruby_out=./$(PROTO_GEN_RUBY_DIR) --grpc-ruby_out=./$(PROTO_GEN_RUBY_DIR) opentelemetry/proto/collector/trace/v1/trace_service.proto $(PROTOC) --ruby_out=./$(PROTO_GEN_RUBY_DIR) --grpc-ruby_out=./$(PROTO_GEN_RUBY_DIR) opentelemetry/proto/collector/metrics/v1/metrics_service.proto $(PROTOC) --ruby_out=./$(PROTO_GEN_RUBY_DIR) --grpc-ruby_out=./$(PROTO_GEN_RUBY_DIR) opentelemetry/proto/collector/logs/v1/logs_service.proto $(PROTOC) --ruby_out=./$(PROTO_GEN_RUBY_DIR) --grpc-ruby_out=./$(PROTO_GEN_RUBY_DIR) opentelemetry/proto/collector/profiles/v1development/profiles_service.proto # The Profiling and Process Context Sharing protos are still development. So they are excluded from the breaking-change check. .PHONY: breaking-change breaking-change: $(BUF) breaking --against $(BUF_AGAINST) --config '{"version":"v1","breaking":{"ignore":["opentelemetry/proto/profiles", "opentelemetry/proto/collector/profiles", "opentelemetry/proto/processcontext"]}}' $(BUF_FLAGS) ALL_DOCS := $(shell find . -type f -name '*.md' -not -path './.github/*' -not -path './node_modules/*' | sort) LYCHEEIMAGE := $(shell awk '$$4=="lychee" {print $$2}' $(DEPENDENCIES_DOCKERFILE)) .PHONY: markdown-link-check markdown-link-check: docker run --rm \ --mount 'type=bind,source=$(PWD),target=/home/repo' \ $(LYCHEEIMAGE) \ --config home/repo/.lychee.toml \ --root-dir /home/repo \ -v \ home/repo MARKDOWNLINTIMAGE := $(shell awk '$$4=="markdownlint" {print $$2}' $(DEPENDENCIES_DOCKERFILE)) .PHONY: markdownlint markdownlint: @for f in $(ALL_DOCS); do \ echo $$f; \ docker run --rm \ --mount 'type=bind,source=$(PWD),target=/workdir' \ $(MARKDOWNLINTIMAGE) \ --config .markdownlint.yaml $$f || exit 1; \ done .PHONY: markdown-toc markdown-toc: @if ! npm ls doctoc; then npm ci --ignore-scripts; fi npx --no -- doctoc . --update-only --mintocitems 1 --toc-pragma-style compact --notitle --entryprefix='-,*,+' || exit 1; .PHONY: markdown-toc-check markdown-toc-check: @if ! npm ls doctoc; then npm ci --ignore-scripts; fi npx --no -- doctoc . --update-only --mintocitems 1 --toc-pragma-style compact --notitle --entryprefix='-,*,+' --dryrun || exit 1; open-telemetry-opentelemetry-proto-790608c/README.md000066400000000000000000000255131522767421700223020ustar00rootroot00000000000000# OpenTelemetry Protobuf Definitions [![Build Check](https://github.com/open-telemetry/opentelemetry-proto/workflows/Build%20Check/badge.svg?branch=main)](https://github.com/open-telemetry/opentelemetry-proto/actions?query=workflow%3A%22Build+Check%22+branch%3Amain) This repository contains the Protocol Buffer definitions for [OTLP](#otlp) (the primary OpenTelemetry data delivery protocol), and other [Protocols](#protocols) that share its common types and release machinery. See [contribution guidelines](CONTRIBUTING.md) if you would like to make any changes. ## Protocols ### OTLP The primary OpenTelemetry data delivery protocol, used to export traces, metrics, logs, and profiles via gRPC and HTTP. - Specification: [docs/specification.md](docs/specification.md) - Proto files: everything under [opentelemetry/proto/](opentelemetry/proto/) except `processcontext/` #### OTLP/JSON See additional requirements for [OTLP/JSON wire representation here](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#json-protobuf-encoding). #### Generate gRPC Client Libraries To generate the raw gRPC client libraries, use `make gen-${LANGUAGE}`. Currently supported languages are: * cpp * csharp * go * java * objc * openapi (swagger) * php * python * ruby ### Process Context Sharing A non-OTLP protocol for sharing process-level resource attributes with external readers (e.g. the [OpenTelemetry eBPF Profiler](https://github.com/open-telemetry/opentelemetry-ebpf-profiler)) via memory-mapped regions. Not exchanged via gRPC, HTTP, or the OpenTelemetry Collector. - Documentation: [docs/process-context/process-context.md](docs/process-context/process-context.md) - Proto file: [opentelemetry/proto/processcontext/v1development/process_context.proto](opentelemetry/proto/processcontext/v1development/process_context.proto) - Design doc: [OTEP 4719](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/4719-process-ctx.md) ## Language Independent Interface Types The proto files can be consumed as GIT submodules or copied and built directly in the consumer project. OpenTelemetry [language libraries](https://opentelemetry.io/docs/languages/) may publish generated language bindings. Check the documentation of the language library you are using for more details. ## Maturity Level 1.0.0 and newer releases from this repository may contain unstable (alpha or beta) components as indicated by the Maturity table below. | Protocol | Component | Binary Protobuf Maturity | JSON Maturity | | ----------------------- | ----------------------------------- | ------------------------ | ----------------------------------------------------------- | | OTLP | common/* | Stable | [Stable](docs/specification.md#json-protobuf-encoding) | | OTLP | resource/* | Stable | [Stable](docs/specification.md#json-protobuf-encoding) | | OTLP | metrics/\*
collector/metrics/* | Stable | [Stable](docs/specification.md#json-protobuf-encoding) | | OTLP | trace/\*
collector/trace/* | Stable | [Stable](docs/specification.md#json-protobuf-encoding) | | OTLP | logs/\*
collector/logs/* | Stable | [Stable](docs/specification.md#json-protobuf-encoding) | | OTLP | profiles/\*
collector/profiles/* | Development | [Development](docs/specification.md#json-protobuf-encoding) | | Process Context Sharing | processcontext/* | Development | N/A | (See [Versioning and Stability](https://github.com/open-telemetry/opentelemetry-specification/blob/a08d1f92f62acd4aafe4dfaa04ae7bf28600d49e/specification/versioning-and-stability.md) for definition of maturity levels). ## Stability Definition Components marked `Stable` provide the following guarantees: - Field types, numbers and names will not change. - Service names and `service` package names will not change. - Service method names will not change. [from 1.0.0] - Service method parameter names will not change. [from 1.0.0] - Service method parameter types and return types will not change. [from 1.0.0] - Service method kind (unary vs streaming) will not change. - Names of `message`s and `enum`s will not change. [from 1.0.0] - Numbers assigned to `enum` choices will not change. - Names of `enum` choices will not change. [from 1.0.0] - The location of `message`s and `enum`s, i.e. whether they are declared at the top lexical scope or nested inside another `message` will not change. [from 1.0.0] - Package names and directory structure will not change. [from 1.0.0] - `optional` and `repeated` declarators of existing fields will not change. [from 1.0.0] - No existing symbol will be deleted. [from 1.0.0] Note: guarantees marked [from 1.0.0] will go into effect when this repository is tagged with version number 1.0.0. The following additive changes are allowed: - Adding new fields to existing `message`s. - Adding new `message`s or `enum`s. - Adding new choices to existing `enum`s. - Adding new choices to existing `oneof` fields. - Adding new `service`s. - Adding new `method`s to existing `service`s. All the additive changes above must be accompanied by an explanation about how new and old senders and receivers that implement the version of the protocol before and after the change interoperate. ## Experiments ### New Experimental Components Sometimes we need to experiment with new components, for example to add a completely new signal to OpenTelemetry. When designing a new signal, we recommend a "development" package to be used. This package will be used throughout development until reaching release candidate, in which case the `development` suffix is removed (e.g. `v1` instead of `v1development`), creating a stable release package. Such isolated experimental components are excluded from above [stability requirements](#stability-definition). We recommend using `Development`, `Alpha`, `Beta`, `Release Candidate` [levels](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0232-maturity-of-otel.md#maturity-levels) to communicate different grades of readiness of new components. These levels MUST be communicated in the documentation of a message, field, etc. when the level does not match the stability of the package. For example, if a package is `Stable` but a field is not, the documentation MUST indicate that the field is experimental with the appropriate level (e.g. `Alpha`, `Beta`, etc). Conversely, individual `Status` annotations are not required if a component is the same maturity level as the package it is defined in. Experimental components may be removed completely at the end of the experiment, provided that they are not referenced from any `Stable` component. Experiments which succeed, require a review to be marked `Stable`. Once marked `Stable` they become subject to the [stability requirements](#stability-definition). ### Experimental Additions to Stable Components New experimental fields or messages may be added in `Development` state to `Stable` components. The experimental fields and messages within `Stable components` are subject to the full [stability requirements](#stability-definition). When the stability of a *portion* of the protocol doesn't match the expectations of the package, there MUST be a stability annotation in the docs. For example: ```protobuf // A reference to an Entity. // Entity represents an object of interest associated with produced telemetry: e.g spans, metrics, profiles, or logs. // // Status: [Development] message EntityRef { // ... } ``` If an experiment concludes and the previously added field or message is not needed anymore, the field/message must stay, but it may be declared "deprecated". During all phases of experimentation it must be clearly specified that the field or message may be deprecated. Typically, deprecated fields are left empty by the senders and the recipients that participate in experiments must expect during all experimental phases (including *after* the experiment is concluded) that the experimental field or message has an empty value. Experiments which succeed, require a review before the field or the message is marked `Stable`. ## Generated Code No guarantees are provided whatsoever about the stability of the code that is generated from the .proto files by any particular code generator. ## Maintainers - [Armin Reuch](https://github.com/arminru) - [Bogdan Drutu](https://github.com/bogdandrutu) - [Carlos Alberto Cortez](https://github.com/carlosalberto) - [Joshua Suereth](https://github.com/jsuereth) - [Robert Pająk](https://github.com/pellared) - [Tigran Najaryan](https://github.com/tigrannajaryan) For more information about the maintainer role, see the [community repository](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer). ## Approvers - [Alex Boten](https://github.com/codeboten) - [Alexey Alexandrov](https://github.com/aalexand) - [Christian Neumüller](https://github.com/Oberon00) - [Christos Kalkanis](https://github.com/christos68k) - [Cijo Thomas](https://github.com/cijothomas) - [Daniel Dyla](https://github.com/dyladan) - [David Ashpole](https://github.com/dashpole) - [Felix Geisendörfer](https://github.com/felixge) - [Florian Lehner](https://github.com/florianl) - [Jack Berg](https://github.com/jack-berg) - [Jonathan Halliday](https://github.com/jhalliday) - [Josh MacDonald](https://github.com/jmacd) - [Juraci Paixão Kröhling](https://github.com/jpkrohling) - [Leighton Chen](https://github.com/lzchen) - [Marc Alff](https://github.com/marcalff) - [Reiley Yang](https://github.com/reyang) - [Severin Neumann](https://github.com/svrnm) - [Ted Young](https://github.com/tedsuo) - [Tristan Sloughter](https://github.com/tsloughter) - [Tyler Yahn](https://github.com/MrAlias) For more information about the approver role, see the [community repository](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#approver). ## Emeritus Maintainers Previously this package was maintained solely by the [OpenTelemetry Technical Committee](https://github.com/open-telemetry/community/blob/main/community-members.md#technical-committee). It now has a dedicated maintainer role that is independent of the OpenTelemetry specification. ## Emeritus Approvers Previously the package had the same approvals as the specification, via [OpenTelemetry Specification Sponsors](https://github.com/open-telemetry/community/blob/main/community-members.md#specifications-and-proto). It now has a dedicated approver role that is independent of the OpenTelemetry specification. open-telemetry-opentelemetry-proto-790608c/RELEASING.md000066400000000000000000000020271522767421700226510ustar00rootroot00000000000000# How to Create a Release _Instruction for Maintainers only._ - Prepare the release by updating [CHANGELOG.md](CHANGELOG.md), see for example [this PR](https://github.com/open-telemetry/opentelemetry-proto/pull/537). Merge the PR. From this point on no new PRs can be merged until the release is complete. - Go to Github [release page](https://github.com/open-telemetry/opentelemetry-proto/releases), click `Draft a new release`. - Click "Choose a tag" and specify the next version number. The Target branch should be "main". - Click "Generate release notes" to get a draft release note. Remove editorial changes from the notes and any other changes that you don't want in the release notes. In addition, you can refer to [CHANGELOG.md](CHANGELOG.md) for a list of major changes since last release. - Click "Publish Release". Our tags follow the naming convention of `v1..`. Increment `minor` by 1 and use `patch` value of 0 for new minor version releases. For patch releases keep `minor` unchanged and increment the `patch`. open-telemetry-opentelemetry-proto-790608c/VERSION000066400000000000000000000002101522767421700220560ustar00rootroot00000000000000open-telemetry/opentelemetry-proto refnames=tag: v1.11.0 commit=790608c4d51e6ffc12210b541e8514cbed9e91a4 date=2026-07-21T15:47:59+02:00 open-telemetry-opentelemetry-proto-790608c/docs/000077500000000000000000000000001522767421700217455ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/docs/README.md000066400000000000000000000006401522767421700232240ustar00rootroot00000000000000# OpenTelemetry Protocol (OTLP) This is the specification of the OpenTelemetry Protocol (OTLP). For other protocols hosted in this repository, see the top-level [README](../README.md). - [Design Goals](design-goals.md) - [Requirements](requirements.md) - [Specification](specification.md) - [SDK Exporter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md) open-telemetry-opentelemetry-proto-790608c/docs/design-goals.md000066400000000000000000000022221522767421700246410ustar00rootroot00000000000000# Design Goals for OpenTelemetry Wire Protocol We want to design a telemetry data exchange protocol that has the following characteristics: - Be suitable for use between all of the following node types: instrumented applications, telemetry backends, local agents, stand-alone collectors/forwarders. - Have high reliability of data delivery and clear visibility when the data cannot be delivered. - Have low CPU usage for serialization and deserialization. - Impose minimal pressure on memory manager, including pass-through scenarios, where deserialized data is short-lived and must be serialized as-is shortly after and where such short-lived data is created and discarded at high frequency (think telemetry data forwarders). - Support ability to efficiently modify deserialized data and serialize again to pass further. This is related but slightly different from the previous requirement. - Ensure high throughput (within the available bandwidth) in high latency networks (e.g. scenarios where telemetry source and the backend are separated by high latency network). - Allow backpressure signalling. - Be load-balancer friendly (do not hinder re-balancing). open-telemetry-opentelemetry-proto-790608c/docs/img/000077500000000000000000000000001522767421700225215ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/docs/img/otlp-client-server.png000066400000000000000000000240201522767421700267630ustar00rootroot00000000000000PNG  IHDR}=AVtEXtmxfile%3Cmxfile%20modified%3D%222019-08-05T20%3A24%3A33.070Z%22%20host%3D%22www.draw.io%22%20agent%3D%22Mozilla%2F5.0%20(X11%3B%20Ubuntu%3B%20Linux%20x86_64%3B%20rv%3A68.0)%20Gecko%2F20100101%20Firefox%2F68.0%22%20etag%3D%22o8U3N8m0FJTt7YJmi9t0%22%20version%3D%2211.1.2%22%20type%3D%22google%22%3E%3Cdiagram%20id%3D%22s0lmM-0tzWFd8UWwOPI1%22%20name%3D%22Page-2%22%3E5VZdb5swFP01SNtDJz5Ckj62JOsmZVWlTFraNwtuwKnxZcYJsF8%2FE0zAIYuWSpEq9Qmf4%2BtrfM71BcsL0vJBkCz5gREwy7Wj0vJmlus63thRj5qpGmYymTZELGikgzpiSf%2BAJm3NbmkEuREoEZmkmUmGyDmE0uCIEFiYYWtk5q4ZiWFALEPChuwvGsmkYae%2B3fHfgMZJu7Nj65mUtMGayBMSYdGjvLnlBQJRNqO0DIDV4rW68Emxe3q8Xe4K%2B8X%2Fnowe716qmybZ10uWHI4ggMs3px7P0409X9PNb0EWs9fFKpne3rhN6h1hW62XPqusWgEhUnpqiEImGCMnbN6x9wK3PIJ6G1uhLmaBmCnSUeQGpKx0cZCtREUlMmV6FkoqV73xc53qi6%2FRrNSZ96BqAZeiWvVBb1UNu2V71K77Ty215jluRQhnBNS1IYmIQZ6J0%2FlqMXt1qZ16AExBvaQK0LesrTkBjEi6M2uZ6CsRH5YdMj0hVcfqQnC9ztV79epCDXobdtS%2BWi6oHHtQOQGjtabH9WNWR5FQCcuM7EUtVMsxK%2BEyd3YgJJRn9Wxn21vd6jvSuOh6wiEm6fWDsf1vzQ1JL9XPGei3BKEO9D7186bvTT9voN%2BnPCM8t9ygbt5qDxpqADL8PJBVHVya2uVS4CsEyFAohiOve9uaMnZEEUZjrmCoNFZ%2Befe1jFR9ce70REqjaN8YT5ll2nktv1zHN%2F2anPDLP%2BGXey2%2FRgO%2FfgKDLvcH8sY9ukv%2B9bxRsPtBaVp%2F95vnzf8C%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22GZocb2n5veWtvEFleT4A%22%20name%3D%22Page-1%22%3E7VrbcpswEP0aP6YDCIzz2Nx7m6Z1Z5I%2BKiCDUowYId%2F69RUggZEcQxxM7KQviXaRVrB79uxKyQCcT5fXFCbhN%2BKjaGAZ%2FnIALgaWZYKhyX9lmlWhcd1RoQgo9sWkSjHGf5FQGkI7wz5KaxMZIRHDSV3pkThGHqvpIKVkUZ82IVF91wQGSFOMPRjp2jvss7DQjhyj0t8gHIRyZ9MQT6ZQThaKNIQ%2BWaypwOUAnFNCWDGaLs9RlDlP%2BqVYd%2FXE0%2FLFKIpZmwXh1fzOvfkC%2FF%2FuJ48%2BjB%2Fpz88nQ%2FFubCU%2FGPn8%2B4VIKAtJQGIYXVbaM0pmsY8yqwaXqjlfCUm40uTKR8TYSgQTzhjhqpBNI%2FEULTG7Xxv%2Fzkx9cIR0sRSWc2ElhZjR1f26sLYqE6tluSTX6V4SjkvJjHpoi2sk2iANENsyzyrmZX5b20DE4BqRKeLvwydQFEGG53VcQQHPoJxXRZAPRBCfEVBhdw6jmdjpDDIvxHHAtT9miGvViHNgJtkwocRDKX%2Bhs0WIGRonMPfPgid2PX4P0PsT5Cj4PmMRjpHQP%2BnrOaIMLbd6Rz4dimwRdAEkDyyq5DNlRoVriSfXde5QV%2FPXfvB%2FYOi3WqIfHBT6R1vpLCbx3vjLPNL42QcVP0tjLz2gUcRrP2pmKZgmRUMwwcss2l3QEwAKPVk6Pdkb2MneFzuZ9msW8KpoH2IKgJYpIEvMgeQA0HJgjGL%2FWAq4bdYzpCzMTQV8byliOf9TpIH9m1PEOagUsd9UioCRniKnvRYRY4M%2FKYZRBm6%2BX%2Bzzn5mHG1rhBpd24DpHPR4YuutGvbpO71jS3FHDiGUoonwUZKOEUZ2GYv9jdkXBJS%2BCaYo9hUNKPqgooDwr7MIHnXXzIhzytCm5Xg%2BGsyEYUteaK8T%2BtwTz76nSyFUqjRrkgv3EqvWLkQZDpqsYKtzWbOjEqhsqZWmITCYpqtnIQVc69gU41LsGTmAdw9CslyXDbCpMuXTLqYR%2FHqLvCp0O6AidjuxfpCHHPT50OsdaYOwNqOm1wMgT8BspMG2vGzan8EnPFcappx5QLxlbVxi1bVENtc3h10thq%2F8C029xeRkyey4uRgOeWhcXoBQX1%2FgwPLryYg01bG7DoLgG9mEa5pXF7IYUdznxPwnXzi632vZM%2FQBX%2FfNO2SU9F7iWcoa2R%2B0YtTPIue8Pcm0vi9oyaT%2BQK9s1iZTTHSGn3v3bas%2B3M%2BS4WP0bQDG9%2BmcKcPkP%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22tKew4vK7WTr1I-XSu-WI%22%20name%3D%22Page-3%22%3E7Vrbdps6EP0aP7qLu%2FGjb02zTtvj1lmraV%2B6dEAGnciIgGzjfn2FEeYiCrgpMW6Sl6BBCLH37JlhzECdbaKbAPjuB2JDPFAkOxqo84GiyKohs3%2Bx5ZBYRiMzMTgBsvmkzLBCPyA3Sty6RTYMCxMpIZgiv2i0iOdBixZsIAjIvjhtTXDxrj5woGBYWQCL1i%2FIpm5iNXUps7%2BDyHHTO8sSP7MB6WRuCF1gk33OpC4G6iwghCZHm2gGcQxeist4tQvDyfT9%2Fh3ekm93t1Cnw2Gy2NtzLjk9QgA9%2BttL083bHcARBObjzPz4PZx%2FHN8O00ejhxQvaDP4%2BJAE1CUO8QBeZNZpQLaeDeNVJTbK5rwnxGdGmRn%2Fh5QeuC%2BALSXM5NIN5mdhhOh97vhrvNQbnY%2FmEV%2F5ODikA48Gh%2Fv8IHdVPMwuO47S61pCxyEOyTawYA1eqQeDwIG0Zp6WzIvBzLkhJ%2BYGkg1km2QTAogBRbuirwLu8s5pXkYrO%2BDMnsEyX5ed2PI7TQG1XOQ5zPppC5m17AbM2f340A%2BIBUO2oeneRRSufHDEZ8%2BCRZHU%2F4D14Bxd498txciD3H4eATsYUBjVQsbPKhr3XR6XVFlPxvtM5XIqXTencEPqCGVFALEbpVyDTrSWOjF6pRO1Nhp6xHvp4a8trealaP1sOJ8X%2Bt231Wx3h%2Bbz%2FShSl%2BluuhamfKUMVmIm9UqYmpDARKVizEpK2JyoQOgndeYaRbELdJahNKmUoRQxQ2kVCUr7AwlKuTEi8OWDjB4f1PuxQ4zH4f1rsXemVoyW0W7cK60YglZW0LOvutbTzKKSTjVcU63XmZRkAcRXKdVJyWwpJVnplZbMv19LVVlp3JGU6qJnCePjC2pD3daAbFcIGuMW0Uh%2BTghT1VwvhlVe%2BMwYjgQMxRjv2ZO4JTk4vQzaIHSPWMpPwa0x2uVQ0StASW2tgyK%2Fw5Igtr2MFL1Iii6XwE7CPL8q32psWEiRSgsleUBY6Ejc6bGfwKUYt18al6eu9VO5LC%2F03Fymt89xOVneinS%2Bll91guBJtrn%2BaunE3DmG0htVGcu%2F47FMfOCQm%2BDHDhT%2B2qHlct2i6bV%2B2zCfHSQ7KF2dboes1yHsJjiJBc%2FE9zGyGHjE62e6blEzms%2BZrFPvyhc8838E7NjT0SJAIQ3IA5wRTIIs8K8RxiUTwMjx2NBiQEJmn8ZYMYrwhJ%2FYINvGv%2Bo2FTnripRyf%2BkUmRv6S0pnrIhl6CLyWaSFQfjCuBmlCrkAN5X93PqfNl50xqzrfzf2ydsmzKeW5qUIrMks8%2Bb%2B9K5qssqHHvXHmUZtvSlzoK8F%2F%2BmVN12s%2B1W367%2B6%2BzUW4%2FKoo0qmEmOxW88QuaS8svh8xm%2Ba8kVjdcVHOVegrooSNu3ZTcKDZwlO0Is3AaFxVyGgzhp3dazmX6diBUnLU6xaEoL7iaZeapRpFa1kU%2F8jYLJh9qliUghkH3yqi58%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22usncUhqpMnfv8iy8fsqG%22%20name%3D%22Page-4%22%3E7VrLkps6EP0aL2eKN3g5D9%2Fc1L1TmZQXcZYKyKCJjCghj%2B18fQQIA5JjsAPEzszKqBENnD59WmozMR9W2w8UJNETCSCeGFqwnZiPE8PQTUfnP5llV1hc1ysMIUWBmFQZ5ugHFEZNWNcogGljIiMEM5Q0jT6JY%2Bizhg1QSjbNaUuCm3dNQAgVw9wHWLV%2BQQGLCqtna5X9X4jCqLyzrokzK1BOFoY0AgHZ1EzmbGI%2BUEJYcbTaPkCcgVfiMrOfFq8vN9%2FmL8hLFovVp6eP8U3h7J9TLtm%2FAoUx69e1YYt3Y7sSMBhw%2FMSQUBaRkMQAzyrrPSXrOICZW42Pqjn%2FE5Jwo86NL5CxnSADWDPCTRFbYXEWbhFb1I6%2FZq5ubTF63ArP%2BWBXDmJGd4v6oHZVNqwuy0fldR2xExinZE19eAwwR3AY0BAec2hMi4kZnDUmith8gGQF%2BWPyCRRiwNBrk65AsD7cz6siyw9EcE8JtHjuV4DX4lb3gPkRikNu%2FbyG3CozgRM%2ByQ4TSnyY8ie630SIwXkCcog2XDCacf0G%2FO9hzo5Pa4ZRDIX9tBi8Qsrg9ihm4qxhidQU2mTqgs6bKtP1Mn2jWpY72lAwuwqKw2TLVeTKtGOumPpl5Yp3VBRjEg%2BmgvrfFVfzsuI6VTRQDTTGfGUC27UOpEmxXFmibcaCwUTO0iSRM1SRsw5onDWUxpmaitp4a4ZqnXA1%2BVLKW3u%2BWBeVL%2BVz1%2FJlDuPgqpcMltfMJsPpuGQYLp0OiNB7OnWoKu3p5F5WOpl%2FfzqZnppO01GzyToIcr7XaVmat0A7FITOVIJQUyH0RoXQViBMOYQTw8EsoxjlR2F2lDCqSlcc3GVdGz7yMUhT5Eu6s9eQSjb2G5reNKS%2FHYcIUum4rBqaEiL7QIhKW2d9Efd%2FJoi%2F5f7mtrTNNSy76aKQTHFVvQXU4kh3JUcFbu2Oboymo%2F24dESWyxQ2fORU3AP7G%2BxUGxlc83omp94scJreVuLy0TOkiL8epO%2BcNRytL85O7aYjx7g%2BzrrXXpSsA5vOcYuS9waKUtd2yeEEvxm5KhnNxDSdczPc1I476prhfzDB1c7S0EXpEgrS7%2FF1ZLq6LSzrSldHkwqSa986V1eSSqE%2B2gutmCl63gFIo7w06f0I6DldiNNI3GNzruvyaxw%2BG5Jq2uaZfDakLbzldZPf3piodhnfKBM797W66u44TDRtiUDTM5ko%2F9NhyXuGoZlo9MnE09hxIbF05Fh62nmxlB3p8l%2FuQ8dSbba%2BtVjK6%2BGzYyk7Gj2Wak%2F37vmjGs73D5eOgWh3rC7ll0KdV%2FXarWlM9XMoy7MP7GoTkoxB6a8Zrcv%2FNoiX%2BhVxW%2Bbzg%2BIJpKtHWH2rLfa7JMHI5%2BCRWGH2RbSEZCz%2FdEfIUhvB88f%2FFOz427EmQCmj5Dt8IJjQSvmXCGPJBDAKYz70OZDZFvo%2Bw4qHCN%2BJEysUBLmuHIpIM2ZDBUVeMu2lueXjEHmj2V9U1FbnbJtwqYU0fWOxcfXRYsOH1XfIhUhVX3Obs58%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%2201LRKRVaTX_zp0Gneu2N%22%20name%3D%22Page-5%22%3E7Vpbc5s4FP41fkwHxMX2Y%2BKk7W63k3S802b7poVj0FZGVIjY7q9fYYS5iATHCSRxnZegg3Qkvu9cNR5Zs%2BX6A8dx%2BJn5QEfI8Ncj63KEkGm5pvyXSTa5ZDye5IKAE19NKgVz8guU0FDSlPiQ1CYKxqggcV3osSgCT9RkmHO2qk9bMFrfNcYBaIK5h6ku%2FUZ8EebSiWOU8o9AgrDY2TTUmyUuJitBEmKfrSoi62pkzThjIn9armdAM%2FAKXOa3Kfo6%2Fn7367tY%2FpxNrj8F6eIsV%2Fb%2BMUt2n8AhEs%2BrGqlPE5sCL%2FAlfGrIuAhZwCJMr0rpBWdp5EOm1ZCjcs5fjMVSaErhfyDERtkCTgWTolAsqXoLayJuK8%2F%2FZKreOWp0uVaat4NNMYgE39xWB5VV2bBcth0V6%2FLvyz6qYQ4dWKp5CUu5Bw%2FMs5RJYx7AQ%2FrGO4ORngZsCfKQch0HigW5qx8OK5MPdvNKWuWDYvYRLKtD3mGaqp0usPBCEgVS%2BiUFKW2agTT2OHuMOfMgkQe6WIVEwDzGWzhWMljUSf0Xez%2BCrWlcp4KSCJRcbQ1cwPoACnTIlBZkK7dUcckynXy8Kr3cLFw3rHi4a%2FSEsq2B2I%2BnvEk%2FGe%2FpJ9OX9BPnwWgYsegU%2Fg6k1bzHmYfh1R3GM82jphChl6RwrKWwz6ksInWHpVRWltCdr3AS5%2BXmgqwzQ%2BgtUdlGI1EhPVHZLXnK7itPTU4139M8Zrpv0HtRj5lqHvNGKz17UnegXQXXVen15kFFb3tyoUNdyCyuAjp9yHpJHyqOeXxO1JaFpoP6ENKg%2FRNDALyjVuvAtS%2F83OkeQcgcFEC9q7%2BOIZpBlKTJ2wCxzQgHBtHWQNRDe%2BSfZxeRo10L6OMk3GJptuF2YNTUUaug4rSAUsj2DoVqhxtG5Gl2pFiNyGA7DbDzYK5WVS8YOxQho6EoD%2Faaoi1xu89%2BApfOb8%2Fl7q76qVw2FQ3OpatxeX7zh07nqep6VNW1b69%2FT9GljOPMeGehqXmIxUrnw5vKhDgzoOR%2BgzabZYvtPGi3HfPlQ36CxuriOGyxSKAfg9YvMM7jmBJPgsei15mu9ygZJ4Mm64mG4fzyk4adREHUAUoEZz9gxijjZeBfEEobIkxJEMmhJ1GThah1kWEqKaLn6sWS%2BD6973KpzllfpDRZMad6Idp2nYR6Y0W%2FaHiPozOWZo4Vkxi23Q3SW%2Bbj5sm2u3kyVXQahqgWCk7581H5sygou%2B%2FK7XbbeGJ55zZLdVNm4sqfM2iNVqBxhJcjLb46HjLTIb0tzXr7v4FCucGrqxe09r4t5A3a3iO9jdBj4HG3hK79TC1hU9HQLSHSK%2BgRcmlWQvjkTj4G2eMNZ4J5LNN2tY5lvgKeFNPktpWZv1k94jpOdz3SVs4fUI%2FIYfmzuJz%2F8seF1tX%2F%3C%2Fdiagram%3E%3C%2Fmxfile%3Eq: 7IDATx/756D"G GiDb^ݤ+W"W"IkSH$IZ}bap.=ag̜b Sxd(`3-Xx0s,}p<9L >A8̜|K fNp>ӂO3'8i'ǃϴ` gZ `3-Xx0s,}p<9L >A8̜|K fNp>ӂO3'8i'ǃϴ`9Bdž+p!pa;!kr ,8i'rDjm* ,XA־*Tץo,i@n>|K Qձy!L >A8KGS=R+HOa{*kniWXi۲ e,ӆ+Zr%T+-X Æ$k ײ tL >A8ItjXAX #8w90Y NL nAؖf;TAA]o MgR"kT3-Xxs*&ai7Kׄ~Зs.=y7HC\jmwH wY*,}p<9~KO)\:.wmi kaB'ݕ(úu>$acSϴ`q'}+8^4'sp;IM ߲1r,,}p<ι< ;uXK]y>{?NDPmD4 ?gZ _*ۀa eBo ~[]iۀHI5xnl!LJdK \>/`-Lji<0VQz>QIy;_k҃RzB!X(K6ʆ$x0oH b?~|.SDʃ'%}C/Ǐg6Sh쨐7('Б~kXç_><8(]yUGEKSA" _|dr$߿O[D[^yK*jϋG_EGițOVGYyݹ&~'}>xoLJ^_b/U5X Jz6G*iG }Xe4vKP>ü'N_^^7F>u-l,FGo츢:9TT?޸Б~7S6$*/D->+{Y^"mO+-8WAFG}b2X†D(TE\*r'Ѿˬ\r^/`;yK Üt`R 7nõ׮y)qz}gX?)gu+w VCOu,aC-[OuY}=>lƀB >AƏGJD;l#T[=01,e^$҅qy)vpLNpzC}_ۼoZ_h'(WN_lV^c VzB R+p w*zCN=CJ)HyXi}ۼ}] x$/`d ܱbiA0}UIog'Th 6 cKN}uSgׄB >A(ǣ+2a2ROokY1:r> `3-Xx0s,}p<9L >A8̜|K fNp>ӂO3'8i'ǃϴ` gZ `3-Xx0s,}p<9Lu0\sIjQIENDB`open-telemetry-opentelemetry-proto-790608c/docs/img/otlp-concurrent.png000066400000000000000000000233771522767421700264010ustar00rootroot00000000000000PNG  IHDRVtEXtmxfile%3Cmxfile%20host%3D%22www.draw.io%22%20modified%3D%222019-09-25T19%3A55%3A45.494Z%22%20agent%3D%22Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010.14%3B%20rv%3A68.0)%20Gecko%2F20100101%20Firefox%2F68.0%22%20version%3D%2211.3.1%22%20etag%3D%223KieJ4jEdKRBIW6kpqUk%22%20type%3D%22google%22%20pages%3D%228%22%3E%3Cdiagram%20id%3D%22qTA36E4-AMplUpZvNs0f%22%3E7Vlds5owEP01vt5JQBQfr%2Fa2felMp3amzxnYC5kGYkP86q9vkCCQaL0iOOroi3CSbMg5u5slDNxZsvkiyCL%2BxkNgAweFm4H7aeA4eIgd9Zcj2wIZu6MCiAQNdacKmNO%2FoEGk0SUNIWt0lJwzSRdNMOBpCoFsYEQIvm52e%2BesOeuCRGAB84AwG%2F1FQxkXqO%2BhCv8KNIrLmTHSLQkpO2sgi0nI1zXIfRu4M8G5LK6SzQxYTl7JSzHu85HW%2FYMJSOVHBmghVoQt9dpmPA2WYjfeQT%2FgzxIymemHlduSAQkbZX8ay4QpAKvLTAr%2BG2accaGQlKeq5%2FSdMmZAhNEoVbeBmgEUPl2BkFRx%2B6obEhqG%2BTTTdUwlzBckyOdcK09SmODLNIT84VFunqdSewf21L1ejDIIm6OE4D3Nyj%2BBJyDFVnXRA4a%2BVqZ0TX27rnQeaiiuSVzqSbRnRXvDFfnqQvN%2FWAvX0sKiHdLwNfffis6aAkVvCC3fPbn22uK8A4srMQGMSLpqmj%2B0Yj3Dd053XlRSO2xS65qkZXwpAtCj6k57whAeGoYkERFIy9BOgP2yP6TJ0I4PRkGbvb2A6CIAHINcfL0I8Cy25yDUah6Xbc905SuyPXrwfOONOso3pqEe8834LE0CRrKMBk1ZzE2xHgQDx0XIJwhZEbNr8cYI3YGwVv4fdSSsg3oT1u9dWPCUXx4UdqrWdRfCntSjbYXg9Bexkwuz6OEa9nY1suoDr61GZlY1DXWnUbmp1kTiC0gtoW6jrOjhrcYdH9nBrlBmYPzc01rsaX5Xe5qpYYdhZZ8ePDe18wVpvamZZU%2BHyp53FvGM2cvKFctF%2BitXsH2i8YzZ8wVpHbNmWu9QWfv0JGA8A0veB65yvAbZLrpilXPpacr9vQcYZOO2ITI6YajDEOn4eOUuUpk%2FemkS7ODJy6T%2Ba7lp%2BeOmWe%2B%2FZjtU0T5L%2BUmTe8hzaNcqlZw8tzLp6hDZfLvz%2Fb7ynrqtPk4W2lWfeN23fw%3D%3D%3C%2Fdiagram%3E%3C%2Fmxfile%3E 6j IDATxLTww{枵;MfMILX6|/q%Ѱeu*Q#]QUY MWkըY`բ%Zi/5V-ZmEP p;af3<$:||n믵e:;;1|(Պ,M͛7c޼y5… ՘5kΜ9Ddff} k,\6 +Wķ~0k,cX,p\'OjvqpRrĬY`XBZvŊ "梴DR@ff& ??_;4?>Gr;(lܸp,XΌ 8N@yyv>lQTTXV(7x۷o(p:PUwƤD׋k׮aѢE "lذ^7\/&aX7r--- ",_\{lxx. vc9eRSS w@Qܺu+d9-[Ƕl"Buu<'NB3==]?4|X$ⴝ?CCCBEE󳳳AD@ffw᜜(Xf A `MwBMNs{k.,?,Ik "tww"ܹsQRR"B}}}2sAdff_\d&r0K/Y_|qRDs}S$= "ڵkG+,,СCa֭8΀'ܾ}͢"l6ܾ}/֖Z, jU{999|rP9YNXN}h"TTTXnݧPUNVݳgIrp):u VUo׮] "䠾^{Wuuu "$''(ISNi݋.,ܿYYYZt)z{{^/G2999PUCܱkhSRROC޽3gjP{ <P<#vޭbZAD8x_ca9.]˗u/[6yj( ׋ܹCOoo/بhmm546`9FPXNadAa9FPXNS TU& 8y%Nj09XNrqFmZdv%x×MS |r.]tԼ֯_oBe`9')c7߀xb@WW222`Z$$$رc4'-- ;vyUUUX`EnǺu088СCHJJ(p\(..ϋ'6l"BQQuw<!;;7na}[,,Y$`]!ƍ "X[AAAЮ "Z Brr2.\«+,@ |Redd`hh]|?I;t6'Grcǎpm{ｇZE_իWٳz c S |rnlڴ 6m>I_뀯ߝ;womm㭣MףV{'<{&99~<9ޥ:;֞kL9P<=}v?uz-kՅXNK۷oewu?1tUUU6-ٖ suTTT|zC$''CQ s׮]8||gg', <Ϥ^X{#k`^>9Ҡ( }]?qqqr<ܾ}9jm6("tuuO>ߎ+,,@\l٨yyuxԧr^t)`EK|y̷X,t] :;;>_߿?"찜3^ׁ xt<}Y[ǭ[PUUF'&;w׮] 8'fa9dąBrrN1n߾ُadAa9FPXNadAa9FPXNadAa9FPXNadAa9FPXNaeJՅ&] &vMN_(~6kG?vp|7p7oHVł#GhrnT]] "ݻw5!^/ `Z122MڰqFX,wy9/^ 9WbΝrn?)."Bcc#%p]}}}(**(Fiiw'|EQðZ(..r@ӕ+WqƀEsǎ "<^{MWΙ3g"''}}}CKK .\_hrF߻,,\IIIE{{_CC:::F VBzz:QXXXf n6ϟ.z{{aZ/xADx񢮜k֬n_#99sS{gSAX,kw(z*l6rss "֭[100'OjҥK;O*|()) ;//駟xt3{DznmxM0o޼oxnc7͛z>DUU܌>,3rʤ+W?R 1ed`9FPXNadAa9FPXNadAa9FPXNadAa9FPXNrss. 2r@/M,#CWh2G|ů$d1 _IcB!<82+~&!Cxqd7h"//Ok'rpmcǐcǎ!>> 999 |M8NXV̛7/Kyc]v6 +W 3^!<82+VRx<JKKZ͛7#??4.\={tBQ\~Nwa߾}Q!<82;–>r`#\x "TVV`9s!ߠz^8sk|Ӊ?X{:XVm(ڝGwu XfNc#C |rvxޠϡ*>3ա'Gc#C*3V!<82r CxqdP===hii w-B!CxqdW MBȐ! e5efDSbe5eH+HaQc Sb E-XN+<U~XN 5<UNXN1*,L6<UlXN gx,xXT1`9%&ᱨrJLcQ )1fǢFSbD E ;Wh"Ǣ}+4 cQ',.2E82+~&!Cx`QCC|ů$do2o/)1Chbȶ,p!ȰfY^^1a9uBA5[Η^z c.r=H-9Ngf9="|{zz@Di!=h{SBBiI|^sI`vx`Q÷wxx/^5ƍ7Ʈ1Jrâ[˷ąAE#߾>ō._ ǃ1Njrâ-m}F͓!_+4  x{?32f=3uFA?=w\Hr3EV 32f],ՖVBUUn! ?SQ_o5W!0/t;v,eck #&?SA{&oтaab&EQ( B{$BeǗ´90}t(*x7Ocx>"돌]rp͐Ƴ:p!9wxd-@d墤wlAͯSPN4vdh"8'a9uBrookY'Zs:mll i<˩z,;D &mjnnYLԅ{G흈D밶 55!e9uBcҟhȩ*l6N:xp/,ChbDz{!?ѐҥK$%%/FyyyHYNqµҟh~駟")) P!g9uBaI!9gMM lقLLJ p𣷽BB彂9σkx`eTrJ  ?zCh2_INu +4 ÓEֲ24ʤ!e!4Yį$DO4QG yHX_BE MB|zNԃ{Mqd/QR!dB!: =& MCWH Wh2g1ԑXHD!4Yį$d/Wcծy7WDQzs;5@IJwJKCD!aY'I/gCVEaժUFbAΉ ,Clق?OʿFY z&=mۆ+˹F䌴zp)((+ g2izp;Xlb&" zΝ;ihx{ ",B1{ٳ c3]H=b{,іSrڴRCh~gh,˩C4›jBNBo[CcYN" 9z/Azz, oJ =%%%3g,zᵗF~㧼\$B2+Ʋ: '}\߾=R+D!tQrdx|S}կ e9u "|;8ɧPo%مGBߐ`h,˩psn_Olj)E_OGi8Ss2'M, CBgΜn=QXN˪vw{e,,M8z=bz;w/ e9uW)"V/CB~)~_[{`9YH{`̙ʿFYd!!T__mh{`INRB/^24V=0ʈ.' )GF?74V=DDW)W\~3CcA9YHԄƊ Cv,C(!?x e9uBl!d>}M'?1<,C(<$?sxp |Wx6m(hhhƈU(9C8!I")~z =l6}YL>?8#Vp!ۯ["}ڒ~ "?aƌ()) 9XN&?SUU|;is=7`9uBYHʕ+SO0}t߿BYNcbEHUʴi@Dxg&<ԁ{ŞDKu駟Ǝ;&<ԁ{ŞDK·W_r=bQ +4 !۰#Cxa]L?2+~&!CxB#CWh2 24dW MB|G|ů$D  >DIį$D ;WhC(a9%{6,p؆!۰=bSbPlrJ mXNB )1C(a9%fuXN=,LBSSbbrJ 1Ƒ!_+4 c#CWh2G|ů$d1 _IcB!<82+~&!CxqdW MBȐ 1Ƒ!_+4 c#CWh2G|ů$d1 _IcB!<82+~&!CxqdW MBȐ 1Ƒ!_+4 c#CWh2G|ů$d1 _IcB!<82; ޽ "Q0ct]]] "8p 刃 1Ƒ!_Sc#C!WXZZ "K/"//vD˅#OСCHJJ(p\(.._RRYfb 11OV@ȐoH}!)) DGsŊ "梴DR@qq1V¡C "… ;w{HII?+ 1Ƒ!ߐ*lp:PU088ݎe˖"˵p\,(ٳg?s̰mt(c^DeADٳgAD "$''ׯ_466,mr8^\m]"N&&<ĄwÍ7/gII ,]DA[[o!>>^QPUU"B|||YYYH694d1 [(Pspp3g믿 g}}=[n xөڵ uvvb૯aٲe8m۶MjC' 1Ƒ!ߐ*"իب}s9UUjEmm-:::PXX"ž={۶m((**BWW>~>{IDATm@bb"Eݻz"o!2G|C!fɞBj爾)''G0SJ7nܿpKDxW100EȐ*>e!x^֢{|UUԄsڵk~###y&:Æ 1Ƒ!_+4 c#CWh2G|ů$d1 _IcBwbe9FPb%JIENDB`open-telemetry-opentelemetry-proto-790608c/docs/img/otlp-multi-destination.png000066400000000000000000000605041522767421700276610ustar00rootroot00000000000000PNG  IHDRF2[tEXtmxfile%3Cmxfile%20modified%3D%222019-09-25T22%3A56%3A43.964Z%22%20host%3D%22www.draw.io%22%20agent%3D%22Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010.14%3B%20rv%3A68.0)%20Gecko%2F20100101%20Firefox%2F68.0%22%20etag%3D%22WgGz-lON30K3CzfSHGTL%22%20version%3D%2211.3.1%22%20type%3D%22google%22%20pages%3D%228%22%3E%3Cdiagram%20id%3D%22IRDf29cn8yx7a37x4A02%22%20name%3D%22Page-1%22%3E7Vtbd6IwEP41PrYHElB8rLa1D3vpqd2z%2B9bDgVRzFogb4qX%2B%2Bg0aFBKtJQp460tlgAmZb76ZSQYasBvOetQdDb8THwUNYPizBrxvAGBaJuD%2FEsnHUtKCzaVgQLEvLloL%2BniOhNAQ0jH2UZy7kBESMDzKCz0SRchjOZlLKZnmL3snQX7UkTtAiqDvuYEq%2FY19NlxKHdtYy58QHgzTkU1DnAnd9GIhiIeuT6YZEXxowC4lhC1%2FhbMuChLjpXZZ3ve45ezqwSiK2FdumPX76Nfdy88%2F9KnXom%2FPNzePvRuhZeIGYzHhPvo35hqxG4jHZh%2BpLRia8ZE6QxYGXGDynzGj5C%2FqkoBQLolIxK%2FsvOMgkERugAcRP%2FS4ZsTlnQmiDHMr34kTIfb9ZJjOdIgZ6o9cLxlzyn2KyygZRz5KpmEk6knEhJ%2BYNj9W7ZBOio%2BBZhmRsEsPkRAx%2BsEvSc82BUbCSR1xOF0jbgnRMAN2iqwrfGywUryGgf8QSBRABSioKFigyL9L3Htt4wwsW02C%2FJy3qwbJzNjeMONURlHgMjzJc2STGcQIzwTzJ1nbG%2BTtbVmSJWMyph4Sd2V9eociU1bEXDpATFG0QGU1bX2goAJUN8BIjHV81DkEVQzJ4mbNXLE2RDDK53O%2BEADZ6euGwD7zcAVg%2B9Y%2BTMBaAVNTwGoWgsoL3DjGXh4tOf9mCdMA0DAc1zAUdi3O2C3jUw4cCd5KVmkeCG1gVIt2q3S0kc09eCPaHT7Zk0B7J0i6xQiomNvOnmH4y4X1kQCnlCK2LnByUJYVlQxcmr8zyJERihT0jqOCKWH9ZW9JinUVNKa6LL6myeLxTjtNOhXzr9h6%2B5onN6OkmyehzOOy4VZX7Vd2F0dJl91QrqbLhlvdIbiyuzhKuuy2Kl7zmOpuhBeQGCmYX0o1tQKgtt1stbz9jIDntzCxTF0uWTsUlcwloNbBXRJ5Y7qwPDBekl5RzOLL4Zbl5BFp1c2tYqXr6e29WnJe0i1DZEVV77yCy%2BsVWcfWqACX1yyyZbevHYNz7xbZzQNFLFlR5RHr2izSSFDazSIZ7qqbReDaLdJgt3a3SPabqrtF4NLaRUo1otsusuS4XHG7CLQV5C6rXQRbWxJjXTUNLLbDcc2USwW6DQQlBlfcQIDltwfPMVMeauUOKm4gwGJ7LFd271cYKX5T9Tu95bcHz5Hdus1%2FxW8qbv5DdU%2FowvpFsJV%2FuRXW3TCC%2B24Rnd7SREJAt2FkNXcoOhyZwtd5F7zck%2Fn8bfDNgT8GkzDe8DnRXqHzFAIhaMovhwOzfdvO%2FulhCaRVDrA%2FVVsysmoN9IrDUwiSxuIs4xCTREv7UB9h2DCHjuk4lQXNjQAduGo5BerZTrMc6tlO64iopxYol009W97%2BKY96%2FHD9ge4Sz%2FVnzvDhPw%3D%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22E_hMsdHh_Q5-RqmYs6Qi%22%20name%3D%22Page-2%22%3E7Vjfj5pAEP5rfKxhWRDvsaf2GtOm19ikd0%2FNFkbYdmXJuij2r%2B8ig4Bc%2FJGK8S71BeZjdtidme9zQo%2BOFtmDYkn0WQYgerYVZD067tk2cYhtLjmyKRCPDgogVDxApwqY8T%2BAoIVoygNYNhy1lELzpAn6Mo7B1w2MKSXXTbe5FM23JiyEFjDzmWij33mgowIdulaFfwQeRuWbiYVPFqx0RmAZsUCuaxCd9OhISamLu0U2ApEnr8xLNnJhOnXWP8KRfD8IN1M%2FYO%2BKYB%2FOWbI7goJYXzY0FnepN2W%2BIDDpQ1MqHclQxkxMKvReyTQOII9qGavy%2BSRlYkBiwF%2Bg9QZ7gaVaGijSC4FPIeP6qXb%2FnIfqu2iNM4y8NTalEWu1eaobtVW5WS3bWuW6E1OHKV7KVPlwwI9iBzMVwqF4XuGXJ7PWhliYB5ALMJs0DgoE03zV7FWGLR%2Fu%2FKqymhus7BlVxl2vmEjxTd9AQLmHMdPMXGbF2ff7wXR9kt8mSvqwNDu7X0dcwyxh20StjWo0q%2FuT%2Bb%2FDbY98SbXgMSB%2BXiVWoDRkB3OHTz2kJ%2BqTTd3CXldsJyWFoxrTB1ZH2XYPciqW8UVJZPU9d9ggErG6oVIe5BEUN1kC1Q29vBPpRchN8WvQqngnGkleg0KeWkLbvqkSei2JbLNYCDO0wHEFZMukmGTmPMt7oDPps%2Bme9jlt7XNekD6nK%2Bmz71pphCwx7f%2FWx4y5jDVuxAzMFydVqXfHhZHeFKvKfdf6YQZxwOPQgF9TSF%2FhvEFJk3RkaLVId3dN0pH2eDcDZQ7Uy8ceSlopbjLrSHq7SuPAOp5GQq4qXtZ%2F8epCvMq%2F0uMjgXNp8cKlj5Kbk%2Bxaz91jMKVWn9Z%2BbjNgsW%2BMsddju039Q9vZb18jd3aN3N5Vue0c1Mj2sHeTGvlSGi%2BlkcasPmUVvV19EKSTvw%3D%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22IaX-2WsKlGNCxiTR1r5e%22%20name%3D%22Page-3%22%3E7VpbV6MwEP41fdQTLuXyWGtd3WO9bN3L8WUPQizZpaSG1FZ%2F%2FQYbWmBQCwtsu%2FapZYAJ5Pu%2BmcmEjtafLD4xZ%2BoPqYeDjoq8RUc77qiqohmK%2BIktT0uLaVpLw5gRT160NozIM5ZGJK0z4uEocyGnNOBkmjW6NAyxyzM2hzE6z152T4PsqFNnjIFh5DoBtH4nHveXVquL1vZTTMZ%2BMrKC5JmJk1wsDZHveHSeMmmDjtZnlPLlv8mij4N48pJ5%2BXw78x5Pvg4ebq%2FPB%2BGXn%2Bh6%2BuNg6eykzC2rV2A45JVdfyffjo3Fl97d3cXg%2FPju4WyknCSuH51gJudLvit%2FSiYQh14vxkEchTQUxiOfTwJxpIi%2FGz6ZHAZ7Gazkc37CdII5exIXzNcIJQD5KXASG8OBw8ljFmFHEmW8crca4YoS8XgqSkhtmIfd5U2S1LqJsk4iOmMulvelJ%2FVdV4qWc8UdNsYcuBJ%2FUq%2B%2BNr2gVgJBFSDYDwiWY6Vx5HjBs%2BBFnNHfuE8Dytbg3pMgyJmcgIxDcegKt1jYjx4x40RIrCdPTIjnxcMczX3C8WjquPGYcxFQhI3RWejh%2BBVQacLEA%2BHFm5RJzuoAiETIKVLpBaRS0ev8yYBVFhkNIDPCTLzRB0NGhRL518joHzHqqVZtUQ%2B6ajvqdUsh6AZOFBE3C%2BI9DbksV5RuTl4dVUPIchACWnw50zVRecVsCQ1gxlp5%2FnsaqHa7NDAapwHuKnoxDY5UhHaXBhtgV70G0lqOBgoMB4PFlDKe3Khsac5llAsQaXyXGh97hIk10NIgpj%2FmQYagjVZQJmCEDvO0ZUJK6k3laQXqu%2Bf%2B3iFQD15CypahakFUbb1NVO198q4teWv11XC60vLKFe2zd321fB686tlbz9eDTfMANqFSUR5yYh%2FlN4jyesEau9Uon4j51ZpsB4D99zWZhfLxvmvCmsxuE1fY1jo8PNx%2BLO3XsGwKO1U18po0oCbVgiTRHHblGl%2FvZtydzZ%2BaYmaQAa3GTbOncJQvr42Wsydc%2B96QCd5SQebZkxdoU2IUdX%2B%2BY2lZQIxNNaGv%2B8%2FDyx%2Fe2c2BwRe9oe2hi%2FuSTej9KuitklXRrWr6LehkWzlX9em3kAbNd7I%2FziIIYFd9ESS8t0oDE9DgVNxFtzSMb1eNDKNBe33Li6lr3%2BiznvYwG%2F666l2Gt9HwoFxjA%2B4v5gW9k%2FIs2JHX1YryLIA456o%2BeRYiClsUffm90nYKNM2g8jvWm4vP1l7bCE6RTCtYn9ZRVhUiBdsOe%2B3F861VTY1wozDvqmHtwYbD5RSHwrLqJwmFYWfywaWYKGpVwBhAiIpiNaRE3D8bjaIr%2B%2Fw0vP4l6k1%2F5lfLgp4T%2BdiTcBXL0t5ZVcJWe3177uBjnhpVWYRupS9H%2F2d0C%2FZkqqK7wadaldEVh%2BtPlpeXrz%2F81gZ%2FAA%3D%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22wGR8hQx8wiE-RgquAzL9%22%20name%3D%22Page-4%22%3E7Zvfd6I4FMf%2FGh%2FrSQiIPFa3054z25mebc%2BZc%2FrGQioZkbgYf81fv0GDEq47LtSgtPalcoEbyefmm5sb7JDhZHWf%2BtPokYc07lgoXHXIHx3LwqSH5b%2FMst5aXLe%2FNYxSFqqL9oZn9osqI1LWOQvpTLtQcB4LNtWNAU8SGgjN5qcpX%2BqXvfFYb3XqjygwPAd%2BDK0%2FWCiirbXvoL39gbJRlLeMkToz8fOLlWEW%2BSFfFkzkrkOGKedi%2B2myGtI467y8X%2FiPlE2cxxVa9H%2BJl%2Fuf%2FwTB3zdbZ1%2Bq3LJ7hJQmorbr6PV7fI%2FX66de%2FEDe2MgarFHueuHHc9Vf6lnFOu9AmoS3GQd5lPBEGgeRmMTyCMuP%2F%2FObqWZoqLFS3%2FOe8gkV6VpesNwTygFFBTi5LaWxL9hCJ%2ByrQBnt3O1aeOJMfj0L5UHtqBBWIU0I0l3M%2BDwNqLqr2KVHHGGn5Ej46YgK4Eh%2BKDz23rQhVoGeBegNY0ZVW0WGgq6EDm4mUj6mQx7zdA%2F2jcVxyeTHbJTIw0C6pdI%2BWNBUMDm8btWJCQvDrJnBMmKCPk%2F9IGtzKcVE2lI%2BT0KaPQLK3PNEKIHAduXgyRqmq9%2BGz060SljyEVwIL%2FtAeFnovyNJQ1eVEwGcnmkqn%2BeTc7LKw%2BfcnJxKahjE%2FmzGgpeIJTqzYv%2BhEq6ORRDq%2BwgBtpszjrs5I1v5wuIPJbLYrSmylqs7slCzIttrJCiog%2B3DQTGQD%2FxRguIoy7ozr1Wewg0HhVspKGDeVIwGp600wTzbq0vTPeLIMM0%2BoDlUq5HLn6CRwQnawzoWuw%2FmZ%2BI1OD9jmEj9RW%2F4lCYbSin1Jy0gVl29K6RUbtfRmNl5nxWY7fKsIrSygJ4Omn3VSqiVNim5qKuVwJFhrcS1kuTf50KtJEpQKQWxvK5X%2FKvHV7otDWGrnDmbJgwz3hc2oS1QVrQ5KyRVnnnxTM6NYHL04OTY6OIVX3PSAzpr2b3T6CxwZHoUwqT0%2BzbRuVtNeSralPGYHYc6JmKDYYhzpW5kHOYxe60iGagiWXWXmKDy4DVcqrcaiYpPWkYqw6xbRiJlVTAdFVDkr1pxKq3YbV2%2FVyuI1%2BwSK5%2FSrlphQCsAzLpaYZe%2Fi%2BGoyAs0hajodrsgMC4j%2ByuvwhrLBpG%2Bdt5t7Z9t6%2FeaDZpTeNs%2BkcLbbsNj%2BZoNmlN4ALOuwjuo4aiA2xvtVHijOxylsquDcWMK%2F%2Fb4ukhfx3fTp%2F7829h%2FGnt%2Ffr2B0%2FKuQLO5D18%2BQEzkcchSGiiDHDFZXxahegaZ4l5PYyqFHTDtu5CpbYopnLRvg3GLgN5sCrhnJUp0oq4HiHp2g0ThJuSDvItfPsqzj818Nt294wr3ORodm3D%2FUdfbb1emx5naGlOS722ciynccSzobQuAXoDelqoc59bb925GVuuoC1mJgAVE7Zc8yqVMx9hK5CC9amVpRS%2F0ZxENFb%2BP9rbHUSK10Zp7c%2FUg2mq15Q8yMEERmKD8JZv3lo6wA1wZJojhivOzj07A18Gn4nsgVEzz%2FZQ%2Fyiv3u5w7T4YQRoNphBZACBYpgxbUEc6%2BUOnpb%2FfYlp2TPFtpCBZp9bVKG7hewHoF6WB76ADYE61Y5OH%2BV9rbIb7%2FrTu5%2Bxc%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22ghyUgH_bz2XzRrIPQe7R%22%20name%3D%22Page-5%22%3E7Vpdc6IwFP01PtYhCQg8Vrfb3ZndbWfcmX3OQCqZAnFirLq%2FfoMEIYlthYrVbZ%2BEA9yQnHM%2FuHGAJtn6luN58pPFJB1AJ14P0JcBhACNgPwpkE2J%2BH5QAjNOY3VTDUzpX6JAR6FLGpOFdqNgLBV0roMRy3MSCQ3DnLOVftsDS%2FVR53hGLGAa4dRG%2F9BYJCUaeE6NfyN0llQjA0ddyXB1swIWCY7ZqgGhmwGacMZEeZStJyQtFq9aF3539yNxN2x8v1lmo%2B9L9IvNr0pjX9s8spsCJ7k4rmlYmn7C6VKtl5qr2FQLSPL4uuBBnuUsl%2BA4EVkqz4A8PPDN1AxIrHGl3vOWsIwIvpE3rGqGKoKSBjkVxkmKBX3SGcZKKLOdud0I94zK14NOJWofDL3yISVqFDi6kQVb8oio55qLapvSDAFkGBKYz4iwDMmDxsRraMtZC%2F6Qxd8kpUSN1WRRkLXQqVsIzh7JhKWM19Q%2B0DQ1IJzSWS5PI2mWSHz8RLig0sGu1YWMxnExzHiVUEGmcxwVY65kOJEYZ8s8JsUUnMI8y4UKEcBtLZ9iYLJ%2BUUDVVdc3GN65dUNi7h6JQed5NWnktWXKtZiaEi5n9MGZgqOzY8r7iDERhkeLidLUu8bEUSv%2BohQvFjTSKWyq3zOcbQCR4wTYcSzP3F7x%2FO2VixSBlc1GR5IAdE4rAb93CRAPuPslMJaTvVwJvMpc18poF8NPJIHAksDNes74uVZGnAlJGyuegsV5TLn8GioBueQF85ok2wusRfUUGGHAszNy4NsSNBk%2BWkYOLS6vo8fzJ%2FJqGzjOisnQZjJ0T8hk1RX4TM5vTs7wWPUZMivpniMzAL1r4KNkZ4u6rtkZmZVe3xqwG0%2BfIb1TSEfgvUO63YP6rLQOJtPVY%2FrItyut8JRk2m2q4XB4%2FkyGzzHZF3OymjD7Jb7tiHBPKuiPu3aNq1fz6sVmSQR83au6ZklpyCAZnjpP2s2s3zQjZ%2BqQpnpMB%2B3LGWVlbzaRg8ByxpM2kWG7Dx27i2xWuBfpicAzvj9d2M0TgdlTNg317IfQ%2FmZhc5JfgB%2B235FoUb5UzUGz099QF9pTvvTndXb5coDXxXiRbNcOPOuC4cV6oLXX7b6ho%2FvaFlHfXthpa%2B5%2FptfetutM7wE7gJ3plaf1%2F2TK2%2Bt%2FG6Gbfw%3D%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22k3X8Zwa5KakJDf3goSyI%22%20name%3D%22Page-6%22%3E7Ztdc5s6EIZ%2FjS%2Fj0QcYuIzdpO1FO%2BeMM%2B303HFAMZpg5JGV2Omvr7BFDKyTAjEQEucmsMAK9OyupBc8orPl9rP0V9E3EbJ4RFC4HdFPI0IwnWD9L7U87i2O4%2B4NC8lDc9LBMOe%2FmTEiY73nIVsXTlRCxIqvisZAJAkLVMHmSyk2xdNuRVxsdeUvGDDMAz%2BG1p88VNHe6troYP%2FC%2BCLKWsbIHFn62cnGsI78UGxyJno1ojMphNpvLbczFqedl%2FVL8GN9Lf5Fv39eXwV3i%2BhhEi7nF3tn13UueXoEyRLV2DW68SYXW%2Fv229cf4f%2B%2FGF3%2Fl9jmEvTgx%2Femv8yzqsesA1kSXqYc9F4iEm2cRmoZ6z2sNyvemXkCFhZYmfv8zMSSKfmoT9gcCGWAohyczCZZ7Cv%2BUCTsm0BZPLl7auEfwfXtEZQFtYPG9v4iE9SUoqKTtbiXATPX5TsVuMIFR6TsSPlywRRwpDdyD34w7ZjV4IcBv1nMmWkrT1GxrSqiWysp7thMxEIe0N7yOC6Z%2FJgvEr0baLdM26cPTCquE%2BzSHFjyMEybmW4irth85QdpmxtdTrRNivskZOkjoNS9SJQpEdiqHT5pw2z7YgBlR%2B0yYewZMLkQs46EGEHPR1MBXl1SBJCaM6mf6IOTIiAXeyflAFKSXYgVS3acJPOXA2BWvzhXZ5bRMMAsTAEwTI4QK9fGkxFzXzmK5TvOHuyoBmqeRUtOKo9q3l9dtTyuebWIBrG%2FXvPgeahoqFApKZMgLh57%2Bb9miCkpTlxo1sNdTVzgzPOGL9kAKivaHVWaqki9ePVjq3qlpYiW8ds9j44YTjnPxTbtcGtyqmILXLWdi3Buup%2FuDCIX28o9C5exUAukHkZul7lHmwyLNxFPXh4a88RGuugg10cI4N0dsZ3dEd3KNY%2FfmQpAJg1VAAJT2OtYB7A6iQxmY%2Bt4ZEwJQu8lMirgrK4PAampXB3ajgz7XDPaVA4nDddYMMio1%2B0aC0%2FONaPFmgFwNq8ZVvl%2B2o4MKIGNx2MQHG9jPlhei3U1P9ScnnuL0NvarJ4Qdq719Wq9ZZ2s1ltOxxndSFA71%2FqmOJvXeht1GxkECnHDrPVtvvEgQIa1Mx2st%2FeJUIe72q6EVNmF%2BO0zxFTvh1yywBh02qSdmefqtfma2HGB9AY1HteBWK3WsEIt7jK4GxDTi52o2ytUuwzV8QBUz%2BoSKlRnirn6%2Fe1z7T1X3Ul5up3J5L3lKpRWcrk6AKb956oLVs2952o9VeTdfhJnN%2F54AGpkdsdTWihfVEAY%2BuuIhQbie%2FuOoAKUV%2FDt%2BKNH8trvfQaJ8IjCSJ8s9RWJfr9bJfX0iI%2BQokf42rg53wrB0jJjCpWFD5mmeiQ9IUYYE21j%2FJvQoCe60wEsTPtfwJQ%2FKLGIlVn6WsLQF%2BWGgZDtfxnjkDLaCTqC9kQLGb17%2BNXRPs0Pv92iV38A%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22d3OQnVQmloDNO6n8YHQR%22%20name%3D%22Page-7%22%3E7Zzdc6M2EMD%2FGs%2B0D%2BdBEmDzeJeP67S5j8bTafLUUUCxaTDygJzY99efMJIBS4lN4sAm7b2ctRby8dvV7mql04CczFefM7qYfeERSwbYiVYDcjrAGBEfyb8KybqUjEbjUjDN4qgUOZVgEv9g6kktXcYRy5WsFAnOExEvmsKQpykLRUNGs4w%2FNLvd8iRqCBZ0ygzBJKSJKf07jsSslI49p5L%2FxuLpTP8yctQ3c6o7K0E%2BoxF%2FqInI2YCcZJyL8tN8dcKSAp7m8ld0c3fhzq7%2FuL760%2F%2Baul9Ofyw%2FlIOdt3lk%2BwoZS8Vxh%2FYC9W5irYGxSPJTTZ6JGZ%2FylCZnlfRTxpdpxIphHdmq%2BlxwvpBCJIX%2FMiHWyhjoUnApmol5or5lq1hcFY8PPdW6rn1zulIjbxpr1cgFzcTHwiCkIExonsehFp%2FHiR76QFQKac6XWcie6IeVsctfmbKnBsQKZEGvZnhKFZ8ZnzORrWWHjCVUxPdN66TKyKfbfpUi5QelyxZ6DdQ%2F554mS%2FVTfSoa1dRcKd2uaKm4bH1Vb9SeKprVY5uW1UBSnrId63B6tA6Cj20dm0fl29J1rcOCx6nIayN%2FLwSyg%2FLmrrZS5cuRh5ouY09%2Fgtwn%2BxPnRd19b8fuy%2FerZsEW1PMnhlZZbWJcspBJ5Jk5QZJERqnCjh5msWCTBd1Yw4MMlE0zp%2FmiDF238aqYLi3tTP62YKsn7UIT04akFYjwsITmPFTBbTQqRbNaXNOyo3sabHqaS6ZmDnZOaDhjBlgZSRfFx3CdxNLBZPsJ35Se6OJmK6Dh3XTjn74thRyFPcv%2FtyHvNshvs4I6d9fkPnZeiTtBBneDcwFo8UIi28yM3uhhnSdJec5Q5lDVn6bFEjewWGzgmOTIq5HDpsUig10z9u0xzwMZk8PNrgaHdAqHGHAm4ODsxI%2FeWLkmK3MSwmDl98wKjYC6K7eZhCCvd%2F%2BELClKN2a1VRJc%2F4TMdGPiQ4MDxD%2FpFKXOagSUVd%2F%2BCUNNp5B3iIPyO2VlJlCTcSd2heEnUNiSFMCwJOzAsyTPhGVWJF%2FFktxHsAKyJN%2BEo6vqcOhAiXVmfjkRGaNzKSvkv9SKEnwh4nn8g0W%2FGjDl24omsVxk%2FI6d8IRng21d8TZOkh0RTeJpKpuhJLupaBTs4pAmH9UX8ziKkseKSU0lvtAzPJ7rooYD2O7R1JSGETK1hl8tm3szURe5fftKizcgnTgDBD%2FoWia%2FC40NEEeJzOQNxpTb3Q4AMOXMhfjE68as8CNU4Uw5ZMlzdcBF%2Fwdca8AdIUu8JR3GW3Pud1T5bk%2FuEGfQbbXXtHeg7Ebg2PVWKG%2FNDu0ukvuHR8zMD%2BqsJQQP%2FQY%2F%2B35ft%2Fws2WFHmXNrfj5EfpaSe0fZdWt%2BAUB%2Brun9oM5fl4wA8rMUCTtKw1vz8yHys8QPqNHXI0O%2F7eGRbmFa1oQd7T%2B2hjkGD9MSWTraoGwLU67TgMP0zFoq1GmOvQCem%2FT2xRTg55%2F3H%2Bdup869p58PPhqvOgI5Gu%2BZW9Xv7CT8kfWs9yHfmqJHB%2FwfCIAnZF1dvunr%2FJk%2Bstz9emWrMbhl77EZZTsqA7aAA2SraYxNVt1kJO1Z9X3%2BbGwpLwMtUiG3tf%2FqFqWl2gy0XoVGwFG%2BndILdoCjfDtVGAkBNkpLQR9oDUbGlSECRs9SwYJadAng0bOUrLo5%2B9x%2BMwSDoxeYS4uOzvu2p%2BfBo2dbe3RzILg9vjE8fJblCNCpi8cAC6SBuUSBmsF4yN%2BxPgj8LOsSoM7PcwHy2x7N6flSk0MuGnl2Ef8ZZeJ2RrC33BscWu7VdcIjX2piXBOCHa9hip6u7ughyldST1VGZgzkkeY4xGuOU76xMc6xrh5BTi%2Fm%2Bs7v4Am8A81V2zWQ3YnAUlqBmsx5I4DhIDALKp%2BoCGdv4iIfXwbYplcjeputg4t8bu9%2Bj%2BYhi1frr%2BHlP%2Fn3b%2Fd%2B%2FsGy66NO8OdSHLHtIf5Bsb11vpkoueBZIdjh%2Fb4P9RdHQXZ1Z7uGCev12rGP9lvVZ1kbLmiab9QU8vlNnG40R9Oo1FxNs9Fy8d9TIm6q0HXRK6pQNqt7Ist8orptk5z9BA%3D%3D%3C%2Fdiagram%3E%3Cdiagram%20id%3D%22IxW81jKd7tkMHuM8PaGb%22%20name%3D%22Page-8%22%3E7VhLj5swEP41HLsCnOcxm%2BxD6kORcuhubxZ2wF2HQY6zkP762sEEHNNsUgWVQy%2BJ57M9xt%2FMZw94aL4pngTOkq9AKPdCnxQeWnhhGKBRoP40si%2BR8XhSArFgxAyqgRX7RQ3oG3THCN1aAyUAlyyzwQjSlEbSwrAQkNvD1sDtVTMcUwdYRZi76HdGZFKik6Ff48%2BUxUm1cuCbng2uBhtgm2ACeQNCDx6aCwBZtjbFnHJNXsUL%2BjzjEwgn89XbU776kT9%2F49NPpbPHa6YctyBoKm%2Freli6fsd8Z%2Fgye5X7ikABu5RQ7cT30H2eMElXGY50b65SRmGJ3HBlBap54ZOaHb1TIWnRiJN58icKGyrFXg0pjmEpp5gsDAbGzuuYBiODJY14hlU4scmj%2BOi75ko1DF1XUDd2mKJEZZ4xQcgEYkgxf6jRe5vLeswXgMww%2BJNKuTcywjsJNr%2B0YPKl0X7Vru6GxloUxvPB2FdGqrb70jQas7RZTztY1bzrYrmFnYjomXEmsyQWMT3nD5XjNJlnM0NQjiV7t2V%2B8yiHjkBmWcZZpJaG1NPnwKP6XQLpqW7QiW5GLboJW3Qz6ko2k%2F%2ByuUo26ELZDHolG%2BTKJtZ89FIkKLzgcmkTSdDZ5RIEDlU9lcmN0%2F3maWymLoHp9KtCPj4N%2BfQkkqXezKyTYB4f4%2B%2FjO3D0MQfOVf0Lop8aGZ4ShoYXaiToSiMjh8O3yVa%2FSfDdVlKXR7VTaZO1lQLeqGJesY4WKaRaRWvG%2BQmEOYtTZUaKVOUY3WveVA3AZ6Zjwwg5SLAtOnb8Orvpx3aAUOAeYoPWArmrI8x34qNvMLV3XSz5LF3Dvzzj6nPttdHzQSkQ3Pn%2ByC4Hph%2BUAwdrSQVTrOrc6eLQnF5YIwx7VSNM%2F6BfieO4Rb79OAYHtsrCFpVNW1SGOlOZ%2B4KCyUFfmV6OkJ4Siar7oyLSd%2B%2BTGxGpzPojTXmB15%2B60MNv%3C%2Fdiagram%3E%3C%2Fmxfile%3EY) IDATx{PTg>wƭgVt0[K7&==2EXXȰ +D]a7A3BBA+Rb$(&Z Q,) T4gi>|~\G4KK9v Fo$9C"װhC 15Hq 0>$r 61i\M D:C"װhC 15Hq 0>$r 61iLss3ZZZ\^#V#)@"װhC y:!44T),j4qСQ/IpEAe.{$\M D !222с:@ֳ҂3gθm#Hmb$8O!p 峮.l6Ξ= Yf֭[ȲӧݻJiiiBŋ8<"##;UUBBB5k`֬Y6t?!H<`V+z=$I’%KPPP`wB,^%%%d%ܥc޽e^0h4*! D\\ۇiӦAWjGGhxHq0@``r_`RRat: !@CCҔ@˗/ǜ9sp5!p=@EEŰ!$ H@"uhC y2tww]+WE`PYY4)]Άy__߰!}ϭV+C ?!H<`>aXD[[`Xy)B\qq1JY7oͿgH>;wTvGmm-Um0i'˗!@ff&, QXX!qq!PRR.CeXaCb$IBggHCam۶ .d٩vS4嫯r:^aZY!,X` 5~=x.\P555a~4&;;RNÚ5k8YQ\\ qlܸѮ$ItcCm\h!pQo#Cq}!id&O ???_xݻq5X,Ac媴/d2Qى]v)WTkC y#tvv7ot8ݻDwwy=\~]ydZZZ>X,]^ @u8*/Ӄ0dddf3F#~z,˘;w.x< !Cx999$ 'NĄ AGlldPXX]v<^ `0`ǎ%K, hhh@tt4dYFhh(***;v@jj*`!mш8zdffl6#::!\7j?bbbe ǻ̱}BvR.GGGh4 B`ӦML@a8y$VXIԄR!O>Da߾}42SLQ?{{{U=(@HH6n܈ ~aJܻw/>S!_+Ite9K>L&`0",[ BbժUB ,,̮*0{*77,>`ҥKQXXL21`nܸ7bɒ%q#݇78+/4000t:!P]] HHH@XXrLrssGB*$IZƍgϟ!~̚5 $A9C.^X 999v$[H @vv6!7eXjdYa@Ywٍg$'VUUt:u~ Z Yy!(++Є$''+?9sBl޼v7ذaJKK!I9 GN4 ~~~Xn,jU' D``A?::Z W\Qp[lU0gڼy3"##!I!@bb"n߾LHD#rE,[ ?яsꯔx 0W^u;} @DDrfv&!!.~'e%%%ve IN:&{ RȲ>3B555=zT|k{}FeϟݻwK.!** x뭷SNW!g?&L?0~xdddx=cΜ9vm8ym 笼О={ e`Ʉ0 !!$͛#$Iغu+V+ !IV !Tz۱c^{5go]INNdm7VfeA2&%%!11iwa$r 61:G?zt 0'O{U>KOOGyy9$IBVVm VTT(!YY)ˍ@bb Hmb$A7nߎhZoNRtww+PeYFWWR:::0o<%:+ GAף.\P:+. Da&@"w?v>"##.vl۶ A۸Xrʂ[R:& /. Da&@"RSS3ӷQ+<|ʽسg2m"Õ۷G Da&@"Q]]{`\}Hmb$W\~Q:C"װhC *++u܇Da&@"]t ?]Z\M D*@``aq!k?!HG,u܇Da&@"/;{,^~e-u܇Da&@"/:s ɭt^]1& """`/Bbb ""@L,ZHfyCxyև~VDDD1<^n:$%% """`?;|0RSS1c x_|/2f̘T9r^h5o`Ԙ~ ݻqAΝ;;wĮ]o`ܸqo Y5ko{{ST1cxW^%Ko>?}}}/oW_EYY`ժUX|'LDD5f, d2oqN> ш_ei CƌԄ)S#/,,ԩS2@+ʕ+ez /OGCDDk5f,+W_:CCCQ]]u!PcYUY?﫲n"""ocԘxM2㗀ЀSn"""osk}6XV!r)n߾}~ojjMWPRYY4̝;WY[!=z!pΜ9!@MM hѢ!4\,((Pʚ!66VY$ICܱG;?=bgQDDD8m4}6B+`0iPVVł43|ؿ?8z!F#֭[IPRR2d fBDD`ҥ6mn޼sM>pPXX;v3{ԡXTTP匒hqBԲ,#??k('_~Ͱ_ ::Zfy&B`ww7ەrJ!pDGG#))I!ˇ$x֭[?dyyymٲŃ[<<-'uj7… qADD1ِey:6lʕ+|軄SRR W^8qBXV56n܈ǏCFtvvϟWމmZ8^ꫯj7PZZ ɤv3|BTUUy}?Oo,++hTW^y| ""(M@`lࣗcu:֬Y`>ٳg+zȲgnݺNc2B`uu?XY`˗{[mj 4#Gh"U@DD `Jܼyxٌj咮M?n߾k:::PYYz]B-ј:u*TYw}}=t:*&""6M@zC`ss3^xU=ydn"""ocԘp?!44ԫկ~'"" 5fj<4\__ɓ'ܹsu@K:u*;B)/^Ⱥ| CƌpB(++sJKK+8| ѣȗ1jX=^Ohěo$..999O4XBcyۉ| 610;vlӏ 4ȗiC  ĥKF4A---#nۓZY C o`&@"w}t BEEE U F:thTm$Ix" ˲[ 0 7mb$Q}}}7ncM@]]RRR pYA[lii3gܶ\@"M D>:4 B555Bĉg]]]HKKl={& ,#66["55111eӧOWXVVV"$$HKK/^YfB]][܏M|ܹs`0>8q"N> `tAjBC$,Yvg!ŋQRRpL&P]zz: Y C^^Fl@a߾}6mzo{iC  ""cL0?`A T LJJB?6lN@uu5hhh@ZZ`3g]!ݻ6:$b<H oH[lABB~C'FޮЀ+WB`ѢEJ0|tDZZy׮]Hdgg_oh> AAAV!H#ߴ!H#a2sAI&aTA(;;Ӻ:6l+`0ىN iii7o2-Cy!{$Iܹs!H#oE@"s{rV?v9 te! ł~Bb?~B eVugX I٩_8q"y˳3guζ[NÚ5k8YQ\\ qlܸѮ$ItcCm\h!pQmCr}!ɽ&O ???_xݻq5X,Ac媴/d2Qqa!wQ} DqX?<}Y咰+AywEee%G{C%#҂|b# Qy!##`6a4QTTwEDDdYܹs+W I`0PVV`(`!8"drrr I&N & jXv0x&.%%zAAA0xϲ`;%K ))IYFUU Z[[ЀhȲPTTT|H/55X`}hD\\z=233tR$&&*mڴ#G!H?<5Aj111زe lYy]v)a4ׇ!i&LNff&zzz0}t sr)S(g B $$7nDEEr_1%ݻ~)믕$IBzz>L&`0",[ BbժUB ,,̮*0,77,>`ҥKQXX˗/^6&&f Df{pnܸ7bɒ%y컇?8+/4000t:!P]] HHH@XXrrssGB*$IO0n80|c֬Y$ B cp9C.^X 999lC7n 2j*Ȳ<(<,2~޼yBԩS1# `$2g| cy}BPVV!} HNNV~>s ؼy3o4aB$sy 4in:X,[kkb__a!VB+We!!!Ayz}9\Ɩ-[j*̙3a6oތHHx!۷oAe9}4Abիn}0g ""B9cc;` ?ȲA$ Nb2=GdYg}f!pAX]]uH=\vAccݻNCKd[Sۋ*H Kj`$8wv̙3]^'O{ڳg l2$$$@$ܼySy`$66$ [njEaa!$Ij[[[!@UU[>a2P]] !H`4:::ڪ;wV QyHS۴i۷Nq XYY!--M˗CRaƍZU~ ooݺ333dff ˫T*TVV #11QLՏ{]vJ?ݻw kWEE{\555YfaºiiiXv^/ԩSz{-))J³>+:99Vڵ+ZZZm >qqqe*~ OGvC?T*N< puuťKm}ᾠ---ׯ=޺u 7n. zT*%#F 66VL]uu5nݺ+WRAaѢE駟0az}l[/(pZ[[v_P o!\.ݻ8p@︻PVAByyyqY4\vvvFnnp>FQЛ7oSL+W~dMOOGq)aَH(lرc8p ~v4== } cǎr ^0jtvvvm>( ~Zj !C矅e| NNNXv-abb'''9s7ny0h CxΓjWz }]ŋ˲𬨨xg<߷ZN۽QF>+)(!ƈ JQA Q0*(! F%D(`TPB JQA Q0*(! F%D(A0&/AcCʟPF&&&ȋ| <H!_*(C.]VH| <H!_*(C׮]2 | d RAxC-;0ydDEEn=sAhh(\\\3C@NNz-,\SL_~X`^u<ɑ< ze·yfxyy aɒ%FX[[ѣ8s |I7bzY1l0VzCD<etÆ puu.WVVLxbN֭ç~Gy3g̙31uTxxxb<#zeRg?;333ş9rp֭= :zh|Gذa^zVۺzg___\ΝxĈ9s澻wu.n޽?~z[nҐD۷oǤI0o_|!ܾxb˖-É'tQA9C ']zyaȐ!<Ձ0a[IIIطoqA*_}2"@mZYY(5 6mBcc#j5e:.]\...#GĒ%K# s}ŋ vڔUV!!!?~<233QVVDaػw=> HIIA||pŋ>):_1 rMYquXt).\;R gdd`ڴiz*<==Kb^JB圵5.\ Zsɓ'1k,DFF 3)))E``pxbH(Re2W8Rh[f 0WFII RRR`oo& 6 uvvƾ}Ç#22£̈#m(1߻QAZQQ$HLL .̙3D}}={n@hh(0sL8::{J2ϟ{i HOOGppp9-++ܹsQXXgggѣ¹#44sETT_(2`{ GAA***PQQ0$''Zvvv?a'O=Am۶ ފ?ԋRj:߳gϢWƮ]Dm  z-DDD`Æ ˗/c۶m8r̓駔w߅7^|E5 Zo `oo'N=0m4$%%iQ}w)5I… > &&FmPA+`kk7ob޼y?$u/FGGk *(àAڼTΫcm߲e *#++KﻹrRj֢Dm 0x`;vL1tv%,ZpppN#k.=uJKKZbС&w)5/;ȑ#HMMxzzb*XZZڵkRSS1c ȩRj!_*(_=zT1tk"==!!!FNN 88gFuu5ϟrl8QqCTPcŊw amm;v@V#//:7M)ZK| O==Ζ-[K. ݻw oCTP~ZoJQWWq ϥCTP4c)&2<3C6XJMoqH3R򍋋. ZeK,&C۵kW2888r7,4SR533Í7DKe0R)P>)Ee_r5*e*ߞ={ի֥2TP* EKexK1JCkee%~IRꏡ򵶶ƅ DKeptt4>J) Cܹs֥2YP* jjjDKe2d޾B)ML`|PUU%j]*(!RP}GqiQRA$@T.瀡23@*ޓ gTb}קR*۽7]Beh//7ݻ]JCToPA 2٬,[Z"8l%@JEDPA4QRAf}=Q8qP2NI2TAGbQRA 1Tnnnؽ{u TPf|=<}__Ը"ߘiiiZOexQTT$D"={.W^={HPfdd?. jxȗ ʠˡ*/xI>.СCQ\\ Z={`ҤIضmc)رc+LTP.VlY?} khhƍ/V\_x1PYYe˖ĉOƎ;Ze=<0dȐV`„ Xno>DGGΦtb54*(¨Qi&466BV:ȡCХK aȑXd Ԥٔ ʹ^{ ۷o˶.ZFAABBB0~xdff HKKɓ[  >>^ŋy^S"}+*(TJ]F\~?#.] . $$nnn6m^ OOOaҥX~^R*(^uG4npKK 0g_% PA&Nl| EʲVOiuRAx=R?fdd <<>>>\| >>>زecD655zٖ\xȗ Cڐ[7JCTPI&!++K1$Ae#_*(Cg-+RA|}}W_=Au/a/C6^V2cYyȗ 0eʔV!KYyȗ Cr㹬L1:C| <h,+RAx lܸQ1ĔuM䕷x2`gѲģ*i22"33S1}ʺl+,,`9ͲMyȗ C˚ |Ufol+ߩxȗ O?T1H٥0{A嫂W>`!_*({kրn݄rz [ETPiӦaÆ rADP +``22PAnQ#igx#.;_ ƣtUpgȗ oO>{ "liUJM)&2m۶ ™Jl)5/aȐ{ u"""O._m۶ȑ#2ORj!_*(J!??~~~n[n2K| o6C/W03h7557oļy"xHYJMƗ RAx#-[K. ݻw oCTP|Gr:7޶s)5/ XJ| fºuC6XJMiR,&2P)| swcxȗ 0w\|r!TJ/AR)u|*(SXX*(1߻QA RJɗ $YJ)=9(*(JibB4*(͛DIJ)C+*(TR) ʹ|zRyT |n.Nu^*QA9X5_|owG=R| pwgoi| 㰕WTPEEEa͚5n[++TTJiTTP;ݺY[#WBJ={ĉTJQA97|5ȩn56="zj`2, GƄ in<33ꅝ51A)~{L"s ,@||pf}=Q8qP2NIĺ;_%2 | .ĪUH| <H!_*(;Ｃדe!_*(xȗ +W=RAxCTPXB1Dxȗ CD<2,Zc/xF#Pu`۶m0`ɗp|ǼGӬ6 aaanm{E0ư|r_gX*g$ & 'Nt0 IΜ9{DM$̙3ѳgOc ˖-tEr V^r}NN!jAP9KKKc [lqC n;p`2ХKI  Ctt45kV+̙Պ QYY]n0LҥKSLdc ]v瑑$wލd2b %%%%%j(TL&N|61̝;ocHIIp(F)S?Ο?`20d5L9r[8|Viiirغu+v Ih"\|CF/CTT/^ HHjk(TBxx˛IݺuCvv5ݻw$I.`ŋc |{ffPgcLP?3OoOIIc7!BՑs!''$IrdMMM`!,, ))){`0ac8|eeen>:_K\Zί_hL ,YzW6ʈ'N`ذa`չBqRٝ}8CʒnzQC Azz:(T7P1\vmሊfܾk.=W\ٳߘ;vDd6]^ˡBv;T\(T7Pmذ1t۷oǙ3gPTT!C14C3f ;e˖7?hCLL ="DDDDdZ!I}]޽]tq Np'1cƀ18Pop̙3;wҷBm˖-&u^"##1c kg$s8{5.ӳgO8rAQFg7/},X_?~Iܹ|{DD,Y"O&PuGŶmPUUu_|׮]QYYP?+ wq'W^EEE%%%8w(//h_BXKcPFBܹsPSS{ F*!@b*!@b*!@b*!@b*!@b*!@b*!@b*!@bjUU;WxɵkPZZ{ P=HkhhhϝXdI#qY$&&O=CEuu5!I&L ŋ.'y\Zo 4 (//Guu5VX6o{4>Էz aaahhhp~ڵ6mKEEE.']l, f3|M8!** """`6xb@nbipL&&Mrݼy󐟟p`2yl޽{cƌX,Ŋ+Xb|6Bt& W_}Xt)&LW^?Ԅ$''ޮ UwӦM`aܹCXX&MZ֖-[0p@0PWW-[1\!Ag[|9N8!Ԅ( //O>zKsNxb1111ݺuäIs >;v@ll,v w[ jLL ^{5B[d Pߠ+WK_CFFScbbW_a߾}`ԩSnk2zj9T9zJ:,..FZZ8;sr<GżyTC|1ܡ1R~r \xQZ\$aȑnsvcΝ$I޶aaaҥK*;ώwØ2eɶAP322kvʄd+vGFmm-jkkQZZ}ɡ!=VAAf#$IHNNYYY.iӦyCnӽ{wF)oo2'N~ Po(;w_|ۜ:u PD|pGi񍝚>|Mߏ >|uuum&TBB%(TB B%(TB B%(TB B%(TB B%(TB B%(TB B%(TG >d/1O#2}5I1XѾ}MMM =&UPPBwu14ըB0:L6M>fdd$V^-߾fa͚5$Iw9 rCCz-X,_~.Gׯ2220al6cԨQn!(Tq #Cjj*iiiT~m̙3& & 555  b@$?~cZ,,XQQQ`aɒ%~z譣Pu }ݼФj,--O؈Hʕ+c ˗/GAAc.'u|n&/$aذayQ"TvΣˡɷՁ1q{IHH@JJ|$I>lF] IMMm>z0"s8h׮14iT{uyv9T9@äI0yd0ƐjJJ ϟfC qGTTǡz=KP+`Gb4{< v0ƐL0\ހqRSSf-ږgToPЀ{4[C~vϞ=@zz:cXp![vĆ IPYYjL&DDD`ݺuؿ?C^^ #DOFDD5zhW'P- m&Gaa!%IϠ<{СC]chBhgT(TfEk< =& OhBH[=CWMM C U7J *_}B?>DqUЄBURC g})Zߺr $I=& |(> U z U˗/=&[:P(ZQ{J6@E{g =&\~`P(ږQ!T%K.CDER9T@ŋر#14 @ U)PP*-*@UIhЩS'chBQ2PBޙQꫯjTAjch)TP{xy!(//okh5PC-g}{mkh5PO/ K)TOQ3ڊ ]r}yy9~a5UPZ99ME:\#Ԛݾ}[jTAβBhr(X_:"0p||uuuGTTږV l6 R֗exh-Po5kָUPve½rKG<5550LE$H .=Fq8{AP $!`A)=s455\ر8u[jTAScS#6!~fV շ* xƩt|oOjTAz^TPBzfCQ>Sxx F6\H(TPwf8(TP-3jJNwchBQzq*Q PESɓw{ M{5"C9N% U jĩt fwضmGjȡ8x:yd?ޣm]m$Z8%$\JB6mƎѶbF/!TeǏ?N>oG5QC8Wf¨Q<֘*ũMII }iii1bGg5C8=+ԹsbmȑC8/}w޼y:tGo5^B8W .īѶX:3TӷxxbmKwrAAExxtRKmKG'B]|9^|EPU*Tb?~?$&&z-›R+Ԭ,ףm)Tj81g8?CfO>mKh)ҕ+}{=m(Ncjnn.zѶC-[ :tP\XN4^[=zh[ U22 ;u1l 9s(N;v~}6l@llGR*Ç1GQ> uxg<ږBUɹsϤˆ`ܨ="ѣG~Gh[ UO0<7ILzCB>8$ CB` vPw<1x'g׊BUk/C43'GJOyJ4:rx wx=ږBUqhiV u#>^ڵ O=GR*ZdEklB-((@Ν=ږBUG)Z9|0~}{ETTGR*E(Z>: 3^ G!h}-ohuurs U^Kz?C]t)q_gϞţ> :u*$IBQQ[ըCz U?~}]rڵ? ٌ;"$$w{1GQ'E9 Cw x0,C߫#DjP.0?>H*Qwv?>Gvځ1,]T\~`P(ږC4ok#"DҖǷśo`dddhVE HJJмDU)ݷo|IchRDK $CU9Z U h14ըBmRP̨Ѷ cjTAjch)TP{/{ Mh5PCRPO/RP}g{~+h5PRPGm9Y/UP*Z U xLL߷~)~_bLըB/wn:kUrBj ESPtx@(T=YYMq@GjTA^zAJ2  PEBkq ʑ:/t¨ХK#jBQj\g*{7!C %I~!!CGo?{LMh5Pi?3Tdgawt ;c(Zud}t֭[jTAj,իyBzgFSB2Ʃ' ::jTA"BJ@=TTjlE *rJ@%@S)//yI`F쀋SBh*ܗpq*Q!Te}bbbxW5T(T)TS-[141j3JqzBC8?DyVN%T(T - U U3(͛7g=& JqA WRmڴ >,14PUx3TS_(TZnĜ9wܞԯ7=&B-]ڷٳ[܆4 U Zj6uMn|=i<@lܩash(ϙCq؆ { M(TPrrCaO(T0pr\l3!87jjxH<~z=&`xn6`}p06I6ڡycPaV`5 ֗?aQQأNG%vC U*Ya+׉(T$(TBx֭[=zC U'hBH[?Oڵk{ M(TV_(TQ)Z֬Y?OЄBU# ɡ`}:\+Я_?jCQjlz)I2;;TP"Z8%$\J .ī{ MZ^$Bg(T5T(T)TS `8*9 U z cȐ!DQ'*}@xJqּy0tPchBwrAAQG'@|*_FFC U7C8BZv;N̙s)NJOOǰax PKWĆq|8BZM:`Sh(.['_Oq*ee66w;csP6w\ >P*Ç1GQ>QaܹgReCp0nx'^{5chB1Z|{$I{PַkyI<@ 7ը޷(8=zTz:iBwy_y B/=CB*.Cx"cX| U\iii1b14Ѵòe|4~PPBkΜ9HII=&-lX,0ai"##$IDffYYYڵ+L&bccyf?JP"l0гgO,Yqqq`!77Y#Fc FBBcdff1cG||<cطoEгgO0Ɛ*(Tq͞=#G=&Vlb444 <<Çw 1_766"220PRR3quVB$t޽;wv*.ÇZSSƘe[lc vkF uV0C|| agent -> collector -> backend). End-to-end delivery guarantees in such systems is outside of the scope for this document. The acknowledgements described in this protocol happen between a single client/server pair and do not span multiple nodes in multi-hop delivery paths. ### Throughput The protocol must ensure high throughput in high latency networks when the client and the server are not in the same data center. This requirement may rule out half-duplex protocols. The throughput of half-duplex protocols is highly dependent on network roundtrip time and request size. To achieve good throughput request sizes may be too large to be practical. ### Compression The protocol must achieve high compression ratios for telemetry data. The protocol design must consider batching of telemetry data and grouping of similar data (both can help to achieve better compression using common compression algorithms). ### Encryption Industry standard encryption (e.g. TLS/HTTPS) must be supported. ### Backpressure Signalling and Throttling The protocol must allow backpressure signalling. If the server is unable to keep up with the pace of data it receives from the client then it must be able to signal that fact to the client. The client may then throttle itself to avoid overwhelming the server. If the underlying transport is a stream that has its own flow control mechanism then the backpressure could be applied by delaying the reading of data from the server’s endpoint which could then be signalled to the client via underlying flow-control. However this approach makes it difficult for the client to distinguish server overloading from network delays (due to e.g. network losses). Such distinction is important for [observability reasons](https://github.com/open-telemetry/opentelemetry-service/pull/188). Because of this it is required for the protocol to allow to explicitly and clearly signal backpressure from the server to the client without relying on implicit signalling using underlying flow-control mechanisms. The backpressure signal should include a hint to the client about desirable reduced rate of data. ### Serialization Performance The protocol must have fast data serialization and deserialization characteristics. Ideally it must also support very fast pass-through mode (when no modifications to the data are needed), fast “augmenting” or “tagging” of data and partial inspection of data (e.g. check for presence of specific tag). These requirements help to create fast Agents and Collectors. ### Memory Usage Profile The protocol must impose minimal pressure on memory manager, including pass-through scenarios, when deserialized data is short-lived and must be serialized as-is shortly after and when such short-lived data is created and discarded at high frequency (think telemetry data forwarders). The implementation of telemetry protocol must aim to minimize the number of memory allocations and deallocations performed during serialization and deserialization and aim to minimize the pressure on Garbage Collection (for GC languages). ### Level 7 Load Balancer Friendly The protocol must allow Level 7 load balancers such as Envoy to re-balance the traffic for each batch of telemetry data. The traffic should not get pinned by a load balancer to one server for the entire duration of telemetry data sending, thus potentially leading to imbalanced load of servers located behind the load balancer. ### Backwards Compatibility The protocol should be possible to evolve over time. It should be possible for nodes that implement different versions of OpenTelemetry protocol to interoperate (while possibly regressing to the lowest common denominator from functional perspective). ### General Requirements The protocol must use well-known, mature encoding and transport mechanisms with ubiquitous availability of implementations in wide selection of languages that are supported by OpenTelemetry. open-telemetry-opentelemetry-proto-790608c/docs/specification.md000066400000000000000000001121201522767421700251040ustar00rootroot00000000000000 # OpenTelemetry Protocol Specification **Status**: * [Stable](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md) for the trace, metric and log signals. * [Development](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md) for the profiles signal. The OpenTelemetry Protocol (OTLP) specification describes the encoding, transport, and delivery mechanism of telemetry data between telemetry sources, intermediate nodes such as collectors and telemetry backends.
Table of Contents - [Protocol Details](#protocol-details) * [OTLP/gRPC](#otlpgrpc) + [OTLP/gRPC Request](#otlpgrpc-request) + [OTLP/gRPC Concurrent Requests](#otlpgrpc-concurrent-requests) + [OTLP/gRPC Response](#otlpgrpc-response) - [Full Success](#full-success) - [Partial Success](#partial-success) - [Failures](#failures) + [OTLP/gRPC Throttling](#otlpgrpc-throttling) + [OTLP/gRPC Service and Protobuf Definitions](#otlpgrpc-service-and-protobuf-definitions) + [OTLP/gRPC Default Port](#otlpgrpc-default-port) * [OTLP/HTTP](#otlphttp) + [Binary Protobuf Encoding](#binary-protobuf-encoding) + [JSON Protobuf Encoding](#json-protobuf-encoding) + [OTLP/HTTP Request](#otlphttp-request) + [OTLP/HTTP Response](#otlphttp-response) - [Full Success](#full-success-1) - [Partial Success](#partial-success-1) - [Failures](#failures-1) - [Retryable Response Codes](#retryable-response-codes) - [Bad Data](#bad-data) - [OTLP/HTTP Throttling](#otlphttp-throttling) - [All Other Responses](#all-other-responses) + [OTLP/HTTP Connection](#otlphttp-connection) + [OTLP/HTTP Concurrent Requests](#otlphttp-concurrent-requests) + [OTLP/HTTP Default Port](#otlphttp-default-port) - [Implementation Recommendations](#implementation-recommendations) * [Multi-Destination Exporting](#multi-destination-exporting) * [Empty Telemetry Envelopes](#empty-telemetry-envelopes) - [Known Limitations](#known-limitations) * [Request Acknowledgements](#request-acknowledgements) + [Duplicate Data](#duplicate-data) - [Future Versions and Interoperability](#future-versions-and-interoperability) - [Glossary](#glossary) - [References](#references)
OTLP is a general-purpose telemetry data delivery protocol designed in the scope of the OpenTelemetry project. ## Protocol Details OTLP defines the encoding of telemetry data and the protocol used to exchange data between the client and the server. This specification defines how OTLP is implemented over [gRPC](https://grpc.io/) and HTTP transports and specifies [Protocol Buffers schema](https://developers.google.com/protocol-buffers/docs/overview) that is used for the payloads. OTLP is a request/response style protocol: the clients send requests, and the server replies with corresponding responses. This document defines one request and response type: `Export`. All server components MUST support the following transport compression options: * No compression, denoted by `none`. * Gzip compression, denoted by `gzip`. ### OTLP/gRPC After establishing the underlying gRPC transport, the client starts sending telemetry data using unary requests using [Export*ServiceRequest](https://github.com/open-telemetry/opentelemetry-proto) messages ([ExportLogsServiceRequest](../opentelemetry/proto/collector/logs/v1/logs_service.proto) for logs, [ExportMetricsServiceRequest](../opentelemetry/proto/collector/metrics/v1/metrics_service.proto) for metrics, [ExportTraceServiceRequest](../opentelemetry/proto/collector/trace/v1/trace_service.proto) for traces, [ExportProfilesServiceRequest](../opentelemetry/proto/collector/profiles/v1development/profiles_service.proto) for profiles). The client continuously sends a sequence of requests to the server and expects to receive a response to each request: ![Request-Response](img/otlp-request-response.png) _Note: this protocol is concerned with the reliability of delivery between one pair of client/server nodes and aims to ensure that no data is lost in transit between the client and the server. Many telemetry collection systems have intermediary nodes that the data must travel across until reaching the final destination (e.g. application -> agent -> collector -> backend). End-to-end delivery guarantees in such systems is outside of the scope of OTLP. The acknowledgements described in this protocol happen between a single client/server pair and do not span intermediary nodes in multi-hop delivery paths._ #### OTLP/gRPC Request The server MUST enforce a message size limit when receiving the request, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious client sending an oversized request. The server implementations typically enforce a default incoming message size limit of 4 MiB. However, it is RECOMMENDED to use 64 MiB as the default limit. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the gRPC server implementations MUST report a `RESOURCE_EXHAUSTED` code as a non-retryable error. The client SHOULD limit the size of the request message, including before compression, to avoid overwhelming the server. It is RECOMMENDED to use 64 MiB as the default limit. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the client MUST NOT make the request and SHOULD record the fact that the request was discarded. #### OTLP/gRPC Concurrent Requests After sending the request the client MAY wait until the response is received from the server. In that case there will be at most only one request in flight that is not yet acknowledged by the server. ![Unary](img/otlp-sequential.png) Sequential operation is recommended when simplicity of implementation is desirable, and when the client and the server are connected via very low-latency network, such as when the client is an instrumented application and the server is an OpenTelemetry Collector running as a local daemon (agent). The implementations that need to achieve high throughput SHOULD support concurrent Unary calls to achieve higher throughput. The client SHOULD send new requests without waiting for the response to the earlier sent requests, essentially creating a pipeline of requests that are currently in flight that are not acknowledged. ![Concurrent](img/otlp-concurrent.png) The number of concurrent requests SHOULD be configurable. The maximum achievable throughput is `max_concurrent_requests * max_request_size / (network_latency + server_response_time)`. For example, if the request can contain at most 100 spans, network roundtrip latency is 200ms, and server response time is 300 ms, then the maximum achievable throughput with one concurrent request is `100 spans / (200ms+300ms)` or 200 spans per second. It is easy to see that in high latency networks or when the server response time is high to achieve good throughput, the requests need to be very big or a lot concurrent requests must be done. If the client is shutting down (e.g. when the containing process wants to exit) the client will optionally wait until all pending acknowledgements are received or until an implementation-specific timeout expires. This ensures the reliable delivery of telemetry data. The client implementation SHOULD expose an option to turn on and off the waiting during a shutdown. If the client is unable to deliver a certain request (e.g. a timer expired while waiting for acknowledgements) the client SHOULD record the fact that the data was not delivered. #### OTLP/gRPC Response The response MUST be the appropriate message (see below for the specific message to use in the [Full Success](#full-success), [Partial Success](#partial-success) and [Failure](#failures) cases). The client MUST enforce a message size limit when receiving the response, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious server. gRPC client implementations typically enforce a default incoming message size limit of 4 MiB, which is acceptable to use. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the client MUST treat the response as a non-retryable error. Note that in such scenario, the gRPC client implementations are reporting a `RESOURCE_EXHAUSTED` code to the caller. The server MUST limit the size of the response message, including before compression, to avoid overwhelming the client. It is RECOMMENDED to use 4 MiB as the default limit. Implementations SHOULD allow this limit to be configured. For a [Partial Success](#partial-success) response that would otherwise exceed the limit, the server SHOULD reduce the response size without changing response semantics if it is possible and practical. To do so, the server MAY decrease the verbosity of optional diagnostic fields, such as `partial_success.error_message`, or omit optional diagnostic fields. If the response still cannot fit within the limit, the server MUST fail the request with the `RESOURCE_EXHAUSTED` code as a non-retryable error. After such a failure, whether any telemetry data from the request was accepted is unspecified. ##### Full Success The success response indicates telemetry data is successfully accepted by the server. If the server receives an empty request (a request that does not carry any telemetry data) the server SHOULD respond with success. On success, the server response MUST be a [Export\ServiceResponse](../opentelemetry/proto/collector) message (`ExportTraceServiceResponse` for traces, `ExportMetricsServiceResponse` for metrics, `ExportLogsServiceResponse` for logs and `ExportProfilesServiceResponse` for profiles). The server MUST leave the `partial_success` field unset in case of a successful response. ##### Partial Success If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server response MUST be the same [Export\ServiceResponse](../opentelemetry/proto/collector) message as in the [Full Success](#full-success) case. Additionally, the server MUST initialize the `partial_success` field (`ExportTracePartialSuccess` message for traces, `ExportMetricsPartialSuccess` message for metrics, `ExportLogsPartialSuccess` message for logs and `ExportProfilesPartialSuccess` for profiles), and it MUST set the respective `rejected_spans`, `rejected_data_points`, `rejected_log_records` or `rejected_profiles` field with the number of spans/data points/log records/profiles it rejected. The server SHOULD populate the `error_message` field with a human-readable error message in English. The message should explain why the server rejected parts of the data and might offer guidance on how users can address the issues. The protocol does not attempt to define the structure of the error message. Servers MAY also use the `partial_success` field to convey warnings/suggestions to clients even when the server fully accepts the request. In such cases, the `rejected_` field MUST have a value of `0`, and the `error_message` field MUST be non-empty. The client MUST NOT retry the request when it receives a partial success response where the `partial_success` is populated. ##### Failures When the server returns an error, it falls into 2 broad categories: retryable and non-retryable: - Retryable errors indicate that telemetry data processing failed, and the client SHOULD record the error and may retry exporting the same data. For example, this can happen when the server is temporarily unable to process the data. - Non-retryable errors indicate that telemetry data processing failed, and the client MUST NOT retry sending the same telemetry data. The client MUST drop the telemetry data. For example, this can happen, when the request contains bad data and cannot be deserialized or processed by the server. The client SHOULD maintain a counter of such dropped data. The server SHOULD indicate retryable errors using code [Unavailable](https://godoc.org/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://godoc.org/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a sample Go code to illustrate: ```go // Do this on server side. st, err := status.New(codes.Unavailable, "Server is unavailable"). WithDetails(&errdetails.RetryInfo{RetryDelay: &duration.Duration{Seconds: 5}}) if err != nil { log.Fatal(err) } return st.Err() ``` To indicate non-retryable errors, the server is recommended to use code [InvalidArgument](https://godoc.org/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://godoc.org/google.golang.org/grpc/status#Status.WithDetails) using [BadRequest](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L119). If more appropriate, another gRPC status code may be used. Here is a snippet of sample Go code to illustrate: ```go // Do this on the server side. st, err := status.New(codes.InvalidArgument, "Invalid Argument"). WithDetails(&errdetails.BadRequest{}) if err != nil { log.Fatal(err) } return st.Err() ``` The server MAY use other gRPC codes to indicate retryable and non-retryable errors if those other gRPC codes are more appropriate for a particular erroneous situation. The client SHOULD interpret gRPC status codes as retryable or non-retryable according to the following table: |gRPC Code|Retryable?| |---------|----------| |CANCELLED|Yes| |UNKNOWN|No| |INVALID_ARGUMENT|No| |DEADLINE_EXCEEDED|Yes| |NOT_FOUND|No| |ALREADY_EXISTS|No| |PERMISSION_DENIED|No| |UNAUTHENTICATED|No| |RESOURCE_EXHAUSTED|Only if the server can recover (see below)| |FAILED_PRECONDITION|No| |ABORTED|Yes| |OUT_OF_RANGE|Yes| |UNIMPLEMENTED|No| |INTERNAL|No| |UNAVAILABLE|Yes| |DATA_LOSS|Yes| When retrying, the client SHOULD implement an exponential backoff strategy. An exception to this is the Throttling case explained below, which provides explicit instructions about retrying interval. The client SHOULD interpret `RESOURCE_EXHAUSTED` code as retryable only if the server signals that the recovery from resource exhaustion is possible. This is signaled by the server by returning [a status](https://godoc.org/google.golang.org/grpc/status#Status.WithDetails) containing [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). In this case the behavior of the server and the client is exactly as described in [OTLP/gRPC Throttling](#otlpgrpc-throttling) section. If no such status is returned, then the `RESOURCE_EXHAUSTED` code SHOULD be treated as non-retryable. #### OTLP/gRPC Throttling OTLP allows backpressure signaling. If the server is unable to keep up with the pace of data it receives from the client then it SHOULD signal that fact to the client. The client MUST then throttle itself to avoid overwhelming the server. To signal backpressure when using gRPC transport, the server SHOULD return an error with code [Unavailable](https://godoc.org/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://godoc.org/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a snippet of sample Go code to illustrate: ```go // Do this on the server side. st, err := status.New(codes.Unavailable, "Server is unavailable"). WithDetails(&errdetails.RetryInfo{RetryDelay: &duration.Duration{Seconds: 30}}) if err != nil { log.Fatal(err) } return st.Err() ... // Do this on the client side. st := status.Convert(err) for _, detail := range st.Details() { switch t := detail.(type) { case *errdetails.RetryInfo: if t.RetryDelay.Seconds > 0 || t.RetryDelay.Nanos > 0 { // Wait before retrying. } } } ``` When the client receives this signal, it SHOULD follow the recommendations outlined in documentation for [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40): ``` // Describes when the clients can retry a failed request. Clients could ignore // the recommendation here or retry when this information is missing from the error // responses. // // It's always recommended that clients should use exponential backoff when // retrying. // // Clients should wait until `retry_delay` amount of time has passed since // receiving the error response before retrying. If retrying requests also // fail, clients should use an exponential backoff scheme to increase gradually // the delay between retries based on `retry_delay` until either a maximum // number of retries has been reached, or a maximum retry delay cap has been // reached. ``` The value of `retry_delay` is determined by the server and is implementation dependant. The server SHOULD choose a `retry_delay` value that is big enough to give the server time to recover yet is not too big to cause the client to drop data while being throttled. #### OTLP/gRPC Service and Protobuf Definitions gRPC service definitions [are here](../opentelemetry/proto/collector). Protobuf definitions for requests and responses [are here](../opentelemetry/proto). Please make sure to check the proto version and [maturity level](../README.md#maturity-level). Schemas for different signals may be at different maturity level - some stable, some in beta. #### OTLP/gRPC Default Port The default network port for OTLP/gRPC is 4317. ### OTLP/HTTP OTLP/HTTP uses Protobuf payloads encoded either in [binary format](#binary-protobuf-encoding) or in [JSON format](#json-protobuf-encoding). Regardless of the encoding the Protobuf schema of the messages is the same for OTLP/HTTP and OTLP/gRPC as [defined here](../opentelemetry/proto). OTLP/HTTP uses HTTP POST requests to send telemetry data from clients to servers. Implementations MAY use HTTP/1.1 or HTTP/2 transports. Implementations that use HTTP/2 transport SHOULD fallback to HTTP/1.1 transport if HTTP/2 connection cannot be established. #### Binary Protobuf Encoding Binary Protobuf encoded payloads use proto3 [encoding standard](https://developers.google.com/protocol-buffers/docs/encoding). The client and the server MUST set "Content-Type: application/x-protobuf" request and response headers when sending binary Protobuf encoded payload. #### JSON Protobuf Encoding JSON Protobuf encoded payloads use proto3 standard defined [JSON Mapping](https://developers.google.com/protocol-buffers/docs/proto3#json) for mapping between Protobuf and JSON, with the following deviations from that mapping: - The `traceId` and `spanId` byte arrays are represented as [case-insensitive hex-encoded strings](https://tools.ietf.org/html/rfc4648#section-8); they are not base64-encoded as is defined in the standard [Protobuf JSON Mapping](https://developers.google.com/protocol-buffers/docs/proto3#json). Hex encoding is used for `traceId` and `spanId` fields in all OTLP Protobuf messages, e.g., the `Span`, `Link`, `LogRecord`, etc. messages. For example, the `traceId` field in a Span can be represented like this: { "traceId": "5B8EFFF798038103D269B633813FC60C", ... } - Values of enum fields MUST be encoded as integer values. Unlike the standard [Protobuf JSON Mapping](https://developers.google.com/protocol-buffers/docs/proto3#json), which allows values of enum fields to be encoded as either integer values or as enum name strings, only integer enum values are allowed in OTLP JSON Protobuf Encoding; the enum name strings MUST NOT be used. For example, the `kind` field with a value of SPAN_KIND_SERVER in a Span can be represented like this: { "kind": 2, ... } - OTLP/JSON receivers MUST ignore message fields with unknown names and MUST unmarshal the message as if the unknown field was not present in the payload. This aligns with the behavior of the Binary Protobuf unmarshaler and ensures that adding new fields to OTLP messages does not break existing receivers. - The keys of JSON objects are field names converted to lowerCamelCase. Original field names are not valid to use as keys for JSON objects. For example, this is a valid JSON representation of a Resource: `{ "attributes": {...}, "droppedAttributesCount": 123 }`, and this is NOT a valid representation: `{ "attributes": {...}, "dropped_attributes_count": 123 }`. Note that according to [Protobuf specs]( https://developers.google.com/protocol-buffers/docs/proto3#json) 64-bit integer numbers in JSON-encoded payloads are encoded as decimal strings, and either numbers or strings are accepted when decoding. The client and the server MUST set "Content-Type: application/json" request and response headers when sending JSON Protobuf encoded payload. For JSON payload examples see: [OTLP JSON request examples](../examples/README.md) #### OTLP/HTTP Request Telemetry data is sent via HTTP POST request. The body of the POST request is a payload either in binary-encoded Protobuf format or in JSON-encoded Protobuf format. The default URL path for requests that carry trace data is `/v1/traces` (for example the full URL when connecting to "example.com" server will be `https://example.com/v1/traces`). The request body is a Protobuf-encoded `ExportTraceServiceRequest` message. The default URL path for requests that carry metric data is `/v1/metrics` and the request body is a Protobuf-encoded `ExportMetricsServiceRequest` message. The default URL path for requests that carry log data is `/v1/logs` and the request body is a Protobuf-encoded `ExportLogsServiceRequest` message. The default URL path for requests that carry profiling data is `/v1development/profiles` and the request body is a Protobuf-encoded `ExportProfilesServiceRequest` message. The client MAY gzip the content and in that case MUST include "Content-Encoding: gzip" request header. The client MAY include "Accept-Encoding: gzip" request header if it can receive gzip-encoded responses. Non-default URL paths for requests MAY be configured on the client and server sides. The server MUST limit the size of the request body when parsing it, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious client sending an oversized request. It is RECOMMENDED to use 64 MiB as the default limit. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the server MUST respond with `HTTP 413 Content Too Large`. The client SHOULD limit the size of the request body, including before compression, to avoid overwhelming the server. It is RECOMMENDED to use 64 MiB as the default limit. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the client MUST NOT make the request and SHOULD record the fact that the request was discarded. #### OTLP/HTTP Response The response body MUST be the appropriate serialized Protobuf message (see below for the specific message to use in the [Full Success](#full-success-1), [Partial Success](#partial-success-1) and [Failure](#failures-1) cases). The client MUST limit the size of the response body when parsing it, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious server. It is RECOMMENDED to use 4 MiB as the default limit. Implementations SHOULD allow this limit to be configured. If the limit is exceeded, the client MUST treat the response as a non-retryable error and SHOULD record the fact that the response was discarded. The server MUST limit the size of the response body, including before compression, to avoid overwhelming the client. It is RECOMMENDED to use 4 MiB as the default limit. Implementations SHOULD allow this limit to be configured. For a [Partial Success](#partial-success-1) response that would otherwise exceed the limit, the server SHOULD reduce the response size without changing response semantics if it is possible and practical. To do so, the server MAY decrease the verbosity of optional diagnostic fields, such as `partial_success.error_message`, or omit optional diagnostic fields. If the response still cannot fit within the limit, the server MUST fail the request with `HTTP 500 Internal Server Error`. After such a failure, whether any telemetry data from the request was accepted is unspecified. The server MUST set "Content-Type: application/x-protobuf" header if the response body is binary-encoded Protobuf payload. The server MUST set "Content-Type: application/json" if the response is JSON-encoded Protobuf payload. The server MUST use the same "Content-Type" in the response as it received in the request. If the request header "Accept-Encoding: gzip" is present in the request the server MAY gzip-encode the response and set "Content-Encoding: gzip" response header. ##### Full Success The success response indicates telemetry data is successfully accepted by the server. If the server receives an empty request (a request that does not carry any telemetry data) the server SHOULD respond with success. On success, the server MUST respond with `HTTP 200 OK`. The response body MUST be a Protobuf-encoded [Export\ServiceResponse](../opentelemetry/proto/collector) message (`ExportTraceServiceResponse` for traces, `ExportMetricsServiceResponse` for metrics, `ExportLogsServiceResponse` for logs and `ExportProfilesServiceResponse` for profiles). The server MUST leave the `partial_success` field unset in case of a successful response. ##### Partial Success If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server MUST respond with `HTTP 200 OK`. The response body MUST be the same [Export\ServiceResponse](../opentelemetry/proto/collector) message as in the [Full Success](#full-success-1) case. Additionally, the server MUST initialize the `partial_success` field (`ExportTracePartialSuccess` message for traces, `ExportMetricsPartialSuccess` message for metrics, `ExportLogsPartialSuccess` message for logs and `ExportProfilesPartialSuccess` for profiles), and it MUST set the respective `rejected_spans`, `rejected_data_points`, `rejected_log_records` or `rejected_profiles` field with the number of spans/data points/log records it rejected. The server SHOULD populate the `error_message` field with a human-readable error message in English. The message should explain why the server rejected parts of the data and might offer guidance on how users can address the issues. The protocol does not attempt to define the structure of the error message. Servers MAY also use the `partial_success` field to convey warnings/suggestions to clients even when it fully accepts the request. In such cases, the `rejected_` field MUST have a value of `0`, and the `error_message` field MUST be non-empty. The client MUST NOT retry the request when it receives a partial success response where the `partial_success` is populated. ##### Failures If the processing of the request fails, the server MUST respond with appropriate `HTTP 4xx` or `HTTP 5xx` status code. See the sections below for more details about specific failure cases and HTTP status codes that should be used. The response body for all `HTTP 4xx` and `HTTP 5xx` responses MUST be a Protobuf-encoded [Status](https://godoc.org/google.golang.org/genproto/googleapis/rpc/status#Status) message that describes the problem. This specification does not use `Status.code` field and the server MAY omit `Status.code` field. The clients are not expected to alter their behavior based on `Status.code` field but MAY record it for troubleshooting purposes. The `Status.message` field SHOULD contain a developer-facing error message as defined in `Status` message schema. The server MAY include `Status.details` field with additional details. Read below about what this field can contain in each specific failure case. The server SHOULD use HTTP response status codes to indicate retryable and non-retryable errors for a particular erroneous situation. The client SHOULD honour HTTP response status codes as retryable or non-retryable. ##### Retryable Response Codes The requests that receive a response status code listed in following table SHOULD be retried. All other `4xx` or `5xx` response status codes MUST NOT be retried. |HTTP response status code| |---------| |429 Too Many Requests| |502 Bad Gateway| |503 Service Unavailable| |504 Gateway Timeout| ##### Bad Data If the processing of the request fails because the request contains data that cannot be decoded or is otherwise invalid and such failure is permanent, then the server MUST respond with `HTTP 400 Bad Request`. The `Status.details` field in the response SHOULD contain a [BadRequest](https://github.com/googleapis/googleapis/blob/d14bf59a446c14ef16e9931ebfc8e63ab549bf07/google/rpc/error_details.proto#L166) that describes the bad data. The client MUST NOT retry the request when it receives `HTTP 400 Bad Request` response. ##### OTLP/HTTP Throttling If the server receives more requests than the client is allowed or the server is overloaded, the server SHOULD respond with `HTTP 429 Too Many Requests` or `HTTP 503 Service Unavailable` and MAY include ["Retry-After"](https://tools.ietf.org/html/rfc7231#section-7.1.3) header to indicate how long the client ought to wait before retrying. Note that the value can be either an HTTP-date or a number of seconds to delay after the response is received. The client SHOULD honour the value specified in the "Retry-After" header if it is present. If the client receives a retryable error code (see [table above](#retryable-response-codes)) and the "Retry-After" header is not present in the response, then the client SHOULD implement an exponential backoff strategy between retries. ##### All Other Responses All other HTTP responses that are not explicitly listed in this document should be treated according to HTTP specifications. If the server disconnects without returning a response, the client SHOULD retry and send the same request. The client SHOULD implement an exponential backoff strategy between retries to avoid overwhelming the server. #### OTLP/HTTP Connection If the client cannot connect to the server, the client SHOULD retry the connection using an exponential backoff strategy between retries. The interval between retries must have a random jitter. The client SHOULD keep the connection alive between requests. Server implementations SHOULD accept OTLP/HTTP with binary-encoded Protobuf payload and OTLP/HTTP with JSON-encoded Protobuf payload requests on the same port and multiplex the requests to the corresponding payload decoder based on the "Content-Type" request header. Server implementations MAY accept OTLP/gRPC and OTLP/HTTP requests on the same port and multiplex the connections to the corresponding transport handler based on the "Content-Type" request header. #### OTLP/HTTP Concurrent Requests To achieve higher total throughput, the client MAY send requests using several parallel HTTP connections. In that case, the maximum number of parallel connections SHOULD be configurable. #### OTLP/HTTP Default Port The default network port for OTLP/HTTP is 4318. ## Implementation Recommendations ### Multi-Destination Exporting An additional complication must be accounted for when one client must send telemetry data to more than one destination server. When one of the servers acknowledges the data and the other server does not (yet), the client needs to decide how to move forward. In such a situation, the client SHOULD implement queuing, acknowledgment handling, and retrying logic per destination. This ensures that servers do not block each other. The queues SHOULD reference shared, immutable data to be sent, thus minimizing the memory overhead caused by having multiple queues. ![Multi-Destination Exporting](img/otlp-multi-destination.png) This ensures that all destination servers receive the data regardless of their speed of reception (within the available limits imposed by the size of the client-side queue). ### Empty Telemetry Envelopes Under certain circumstances, it is possible to have a telemetry envelope with no contents. Some examples would be a ResourceMetrics with no ScopeMetrics inside it, a ResourceMetrics with no Metrics inside it, or the equivalents for Logs or Spans. One way this might happen would be for filtering rules to remove all the contained data points, though there are others. In practice, such empty envelopes are often discarded by existing implementations. Given that, senders SHOULD NOT create empty envelopes (OTLP payloads that contain zero spans, zero metric points or zero log records), receivers MAY ignore empty envelopes, and implementations that receive and send (forward) OTLP payloads MAY drop empty envelopes. ## Known Limitations ### Request Acknowledgements #### Duplicate Data In edge cases (e.g. on reconnections, network interruptions, etc) the client has no way of knowing if recently sent data was delivered if no acknowledgement was received yet. The client will typically choose to re-send such data to guarantee delivery, which may result in duplicate data on the server side. This is a deliberate choice and is considered to be the right tradeoff for telemetry data. ## Future Versions and Interoperability OTLP will evolve and change over time. Future versions of OTLP must be designed and implemented in a way that ensures that clients and servers that implement different versions of OTLP can interoperate and exchange telemetry data. Old clients must be able to talk to new servers and vice versa. Suppose new versions of OTLP introduce new functionality that cannot be understood and supported by nodes implementing the old versions of OTLP. In that case, the protocol must regress to the lowest common denominator from a functional perspective. When possible, the interoperability MUST be ensured between all versions of OTLP that are not declared obsolete. OTLP does not use explicit protocol version numbering. OTLP's interoperability of clients and servers of different versions is based on the following concepts: 1. OTLP (current and future versions) defines a set of capabilities, some of which are mandatory, while others are optional. Clients and servers must implement mandatory capabilities and can choose to implement only a subset of optional capabilities. 2. For minor changes to the protocol, future versions and extensions of OTLP are encouraged to use the Protobuf's ability to evolve the message schema in a backward-compatible manner. Newer versions of OTLP may add new fields to messages that will be ignored by clients and servers that do not understand these fields. In many cases, careful design of such schema changes and correct choice of default values for new fields is enough to ensure interoperability of different versions without nodes explicitly detecting that their peer node has different capabilities. 3. More significant changes must be explicitly defined as new optional capabilities in future OTEPs. Such capabilities SHOULD be discovered by client and server implementations after establishing the underlying transport. The exact discovery mechanism SHOULD be described in future OTEPs, which define the new capabilities and typically can be implemented by making a discovery request/response message exchange from the client to server. The mandatory capabilities defined by this specification are implied and do not require discovery. The implementation which supports a new, optional capability MUST adjust its behavior to match the expectation of a peer that does not support a particular capability. ## Glossary There are 2 parties involved in telemetry data exchange. In this document the party that is the source of telemetry data is called the `Client`, the party that is the destination of telemetry data is called the `Server`. ![Client-Server](img/otlp-client-server.png) Examples of a Client are instrumented applications or sending side of telemetry collectors, examples of Servers are telemetry backends or receiving side of telemetry collectors (so a Collector is typically both a Client and a Server depending on which side you look from). Both the Client and the Server are also a `Node`. This term is used in the document when referring to either one. ## References - [OTEP 0035](https://github.com/open-telemetry/oteps/blob/main/text/0035-opentelemetry-protocol.md) OpenTelemetry Protocol Specification - [OTEP 0099](https://github.com/open-telemetry/oteps/blob/main/text/0099-otlp-http.md) OTLP/HTTP: HTTP Transport Extension for OTLP - [OTEP 0122](https://github.com/open-telemetry/oteps/blob/main/text/0122-otlp-http-json.md) OTLP: JSON Encoding for OTLP/HTTP open-telemetry-opentelemetry-proto-790608c/examples/000077500000000000000000000000001522767421700226335ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/examples/README.md000066400000000000000000000016371522767421700241210ustar00rootroot00000000000000# OTLP JSON request examples This folder contains a collection of example OTLP JSON files for all signals that can be used as request payloads. - Trace [trace.json](trace.json) - Metrics [metrics.json](metrics.json) - Logs [logs.json](logs.json) - Events [events.json](events.json) ## Trying it out First run a OpenTelemetry collector with the following configuration: ```yaml receivers: otlp: protocols: http: exporters: debug: verbosity: detailed service: pipelines: traces: receivers: [otlp] exporters: [debug] metrics: receivers: [otlp] exporters: [debug] logs: receivers: [otlp] exporters: [debug] ``` Then send a curl request to the collector (e.g. for Logs): ```shell curl -X POST -H "Content-Type: application/json" -d @logs.json -i localhost:4318/v1/logs ``` > Remember to change the URL path when sending other signals (traces/metrics). open-telemetry-opentelemetry-proto-790608c/examples/events.json000066400000000000000000000041221522767421700250310ustar00rootroot00000000000000{ "resourceLogs": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "my.service" } } ] }, "scopeLogs": [ { "scope": { "name": "my.library", "version": "1.0.0", "attributes": [ { "key": "my.scope.attribute", "value": { "stringValue": "some scope attribute" } } ] }, "logRecords": [ { "eventName": "browser.page_view", "timeUnixNano": "1544712660300000000", "observedTimeUnixNano": "1544712660300000000", "severityNumber": 9, "severityText": "test severity text", "attributes": [ { "key": "event.attribute", "value": { "stringValue": "some event attribute" } } ], "body": { "kvlistValue": { "values": [ { "key": "type", "value": { "intValue": "0" } }, { "key": "url", "value": { "stringValue": "https://www.guidgenerator.com/online-guid-generator.aspx" } }, { "key": "referrer", "value": { "stringValue": "https://wwww.google.com" } }, { "key": "title", "value": { "stringValue": "Free Online GUID Generator" } } ] } } } ] } ] } ] } open-telemetry-opentelemetry-proto-790608c/examples/logs.json000066400000000000000000000052361522767421700245000ustar00rootroot00000000000000{ "resourceLogs": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "my.service" } } ] }, "scopeLogs": [ { "scope": { "name": "my.library", "version": "1.0.0", "attributes": [ { "key": "my.scope.attribute", "value": { "stringValue": "some scope attribute" } } ] }, "logRecords": [ { "timeUnixNano": "1544712660300000000", "observedTimeUnixNano": "1544712660300000000", "severityNumber": 10, "severityText": "Information", "traceId": "5B8EFFF798038103D269B633813FC60C", "spanId": "EEE19B7EC3C1B174", "body": { "stringValue": "Example log record" }, "attributes": [ { "key": "string.attribute", "value": { "stringValue": "some string" } }, { "key": "boolean.attribute", "value": { "boolValue": true } }, { "key": "int.attribute", "value": { "intValue": "10" } }, { "key": "double.attribute", "value": { "doubleValue": 637.704 } }, { "key": "array.attribute", "value": { "arrayValue": { "values": [ { "stringValue": "many" }, { "stringValue": "values" } ] } } }, { "key": "map.attribute", "value": { "kvlistValue": { "values": [ { "key": "some.map.key", "value": { "stringValue": "some value" } } ] } } } ] } ] } ] } ] }open-telemetry-opentelemetry-proto-790608c/examples/metrics.json000066400000000000000000000100461522767421700251750ustar00rootroot00000000000000{ "resourceMetrics": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "my.service" } } ] }, "scopeMetrics": [ { "scope": { "name": "my.library", "version": "1.0.0", "attributes": [ { "key": "my.scope.attribute", "value": { "stringValue": "some scope attribute" } } ] }, "metrics": [ { "name": "my.counter", "unit": "1", "description": "I am a Counter", "sum": { "aggregationTemporality": 1, "isMonotonic": true, "dataPoints": [ { "asDouble": 5, "startTimeUnixNano": "1544712660300000000", "timeUnixNano": "1544712660300000000", "attributes": [ { "key": "my.counter.attr", "value": { "stringValue": "some value" } } ] } ] } }, { "name": "my.gauge", "unit": "1", "description": "I am a Gauge", "gauge": { "dataPoints": [ { "asDouble": 10, "timeUnixNano": "1544712660300000000", "attributes": [ { "key": "my.gauge.attr", "value": { "stringValue": "some value" } } ] } ] } }, { "name": "my.histogram", "unit": "1", "description": "I am a Histogram", "histogram": { "aggregationTemporality": 1, "dataPoints": [ { "startTimeUnixNano": "1544712660300000000", "timeUnixNano": "1544712660300000000", "count": "2", "sum": 2, "bucketCounts": ["1","1"], "explicitBounds": [1], "min": 0, "max": 2, "attributes": [ { "key": "my.histogram.attr", "value": { "stringValue": "some value" } } ] } ] } }, { "name": "my.exponential.histogram", "unit": "1", "description": "I am an Exponential Histogram", "exponentialHistogram": { "aggregationTemporality": 1, "dataPoints": [ { "startTimeUnixNano": "1544712660300000000", "timeUnixNano": "1544712660300000000", "count": "3", "sum": 10, "scale": 0, "zeroCount": "1", "positive": { "offset": 1, "bucketCounts": ["0","2"] }, "min": 0, "max": 5, "zeroThreshold": 0, "attributes": [ { "key": "my.exponential.histogram.attr", "value": { "stringValue": "some value" } } ] } ] } } ] } ] } ] } open-telemetry-opentelemetry-proto-790608c/examples/trace.json000066400000000000000000000023151522767421700246250ustar00rootroot00000000000000{ "resourceSpans": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "my.service" } } ] }, "scopeSpans": [ { "scope": { "name": "my.library", "version": "1.0.0", "attributes": [ { "key": "my.scope.attribute", "value": { "stringValue": "some scope attribute" } } ] }, "spans": [ { "traceId": "5B8EFFF798038103D269B633813FC60C", "spanId": "EEE19B7EC3C1B174", "parentSpanId": "EEE19B7EC3C1B173", "name": "I'm a server span", "startTimeUnixNano": "1544712660000000000", "endTimeUnixNano": "1544712661000000000", "kind": 2, "attributes": [ { "key": "my.span.attr", "value": { "stringValue": "some value" } } ] } ] } ] } ] }open-telemetry-opentelemetry-proto-790608c/opentelemetry/000077500000000000000000000000001522767421700237115ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/000077500000000000000000000000001522767421700250545ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/000077500000000000000000000000001522767421700270425ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/README.md000066400000000000000000000005141522767421700303210ustar00rootroot00000000000000# OpenTelemetry Collector Proto This package describes the OpenTelemetry collector protocol. ## Packages 1. `trace` package contains the Trace Service protos. 2. `metrics` package contains the Metrics Service protos. 3. `logs` package contains the Logs Service protos. 4. `profiles` package contains the Profiles Service protos. open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/logs/000077500000000000000000000000001522767421700300065ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/logs/v1/000077500000000000000000000000001522767421700303345ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/logs/v1/logs_service.proto000066400000000000000000000065111522767421700341100ustar00rootroot00000000000000// Copyright 2020, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.collector.logs.v1; import "opentelemetry/proto/logs/v1/logs.proto"; option csharp_namespace = "OpenTelemetry.Proto.Collector.Logs.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.collector.logs.v1"; option java_outer_classname = "LogsServiceProto"; option go_package = "go.opentelemetry.io/proto/otlp/collector/logs/v1"; // Service that can be used to push logs between one Application instrumented with // OpenTelemetry and an collector, or between an collector and a central collector (in this // case logs are sent/received to/from multiple Applications). service LogsService { rpc Export(ExportLogsServiceRequest) returns (ExportLogsServiceResponse) {} } message ExportLogsServiceRequest { // An array of ResourceLogs. // For data coming from a single resource this array will typically contain one // element. Intermediary nodes (such as OpenTelemetry Collector) that receive // data from multiple origins typically batch the data before forwarding further and // in that case this array will contain multiple elements. repeated opentelemetry.proto.logs.v1.ResourceLogs resource_logs = 1; } message ExportLogsServiceResponse { // The details of a partially successful export request. // // If the request is only partially accepted // (i.e. when the server accepts only parts of the data and rejects the rest) // the server MUST initialize the `partial_success` field and MUST // set the `rejected_` with the number of items it rejected. // // Servers MAY also make use of the `partial_success` field to convey // warnings/suggestions to senders even when the request was fully accepted. // In such cases, the `rejected_` MUST have a value of `0` and // the `error_message` MUST be non-empty. // // A `partial_success` message with an empty value (rejected_ = 0 and // `error_message` = "") is equivalent to it not being set/present. Senders // SHOULD interpret it the same way as in the full success case. ExportLogsPartialSuccess partial_success = 1; } message ExportLogsPartialSuccess { // The number of rejected log records. // // A `rejected_` field holding a `0` value indicates that the // request was fully accepted. int64 rejected_log_records = 1; // A developer-facing human-readable message in English. It should be used // either to explain why the server rejected parts of the data during a partial // success or to convey warnings/suggestions during a full success. The message // should offer guidance on how users can address such issues. // // error_message is an optional field. An error_message with an empty value // is equivalent to it not being set. string error_message = 2; } logs_service_http.yaml000066400000000000000000000004631522767421700346670ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/logs/v1# This is an API configuration to generate an HTTP/JSON -> gRPC gateway for the # OpenTelemetry service using github.com/grpc-ecosystem/grpc-gateway. type: google.api.Service config_version: 3 http: rules: - selector: opentelemetry.proto.collector.logs.v1.LogsService.Export post: /v1/logs body: "*"open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/metrics/000077500000000000000000000000001522767421700305105ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/metrics/v1/000077500000000000000000000000001522767421700310365ustar00rootroot00000000000000metrics_service.proto000066400000000000000000000064741522767421700352450ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/metrics/v1// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.collector.metrics.v1; import "opentelemetry/proto/metrics/v1/metrics.proto"; option csharp_namespace = "OpenTelemetry.Proto.Collector.Metrics.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.collector.metrics.v1"; option java_outer_classname = "MetricsServiceProto"; option go_package = "go.opentelemetry.io/proto/otlp/collector/metrics/v1"; // Service that can be used to push metrics between one Application // instrumented with OpenTelemetry and a collector, or between a collector and a // central collector. service MetricsService { rpc Export(ExportMetricsServiceRequest) returns (ExportMetricsServiceResponse) {} } message ExportMetricsServiceRequest { // An array of ResourceMetrics. // For data coming from a single resource this array will typically contain one // element. Intermediary nodes (such as OpenTelemetry Collector) that receive // data from multiple origins typically batch the data before forwarding further and // in that case this array will contain multiple elements. repeated opentelemetry.proto.metrics.v1.ResourceMetrics resource_metrics = 1; } message ExportMetricsServiceResponse { // The details of a partially successful export request. // // If the request is only partially accepted // (i.e. when the server accepts only parts of the data and rejects the rest) // the server MUST initialize the `partial_success` field and MUST // set the `rejected_` with the number of items it rejected. // // Servers MAY also make use of the `partial_success` field to convey // warnings/suggestions to senders even when the request was fully accepted. // In such cases, the `rejected_` MUST have a value of `0` and // the `error_message` MUST be non-empty. // // A `partial_success` message with an empty value (rejected_ = 0 and // `error_message` = "") is equivalent to it not being set/present. Senders // SHOULD interpret it the same way as in the full success case. ExportMetricsPartialSuccess partial_success = 1; } message ExportMetricsPartialSuccess { // The number of rejected data points. // // A `rejected_` field holding a `0` value indicates that the // request was fully accepted. int64 rejected_data_points = 1; // A developer-facing human-readable message in English. It should be used // either to explain why the server rejected parts of the data during a partial // success or to convey warnings/suggestions during a full success. The message // should offer guidance on how users can address such issues. // // error_message is an optional field. An error_message with an empty value // is equivalent to it not being set. string error_message = 2; } metrics_service_http.yaml000066400000000000000000000004741522767421700360750ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/metrics/v1# This is an API configuration to generate an HTTP/JSON -> gRPC gateway for the # OpenTelemetry service using github.com/grpc-ecosystem/grpc-gateway. type: google.api.Service config_version: 3 http: rules: - selector: opentelemetry.proto.collector.metrics.v1.MetricsService.Export post: /v1/metrics body: "*"open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/profiles/000077500000000000000000000000001522767421700306655ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/profiles/v1development/000077500000000000000000000000001522767421700334565ustar00rootroot00000000000000profiles_service.proto000066400000000000000000000071611522767421700400340ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/profiles/v1development// Copyright 2023, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.collector.profiles.v1development; import "opentelemetry/proto/profiles/v1development/profiles.proto"; option csharp_namespace = "OpenTelemetry.Proto.Collector.Profiles.V1Development"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.collector.profiles.v1development"; option java_outer_classname = "ProfilesServiceProto"; option go_package = "go.opentelemetry.io/proto/otlp/collector/profiles/v1development"; // Service that can be used to push profiles between one Application instrumented with // OpenTelemetry and a collector, or between a collector and a central collector. service ProfilesService { rpc Export(ExportProfilesServiceRequest) returns (ExportProfilesServiceResponse) {} } // Status: [Alpha] message ExportProfilesServiceRequest { // An array of ResourceProfiles. // For data coming from a single resource this array will typically contain one // element. Intermediary nodes (such as OpenTelemetry Collector) that receive // data from multiple origins typically batch the data before forwarding further and // in that case this array will contain multiple elements. repeated opentelemetry.proto.profiles.v1development.ResourceProfiles resource_profiles = 1; // The reference table containing all data shared by profiles across the message being sent. opentelemetry.proto.profiles.v1development.ProfilesDictionary dictionary = 2; } // Status: [Alpha] message ExportProfilesServiceResponse { // The details of a partially successful export request. // // If the request is only partially accepted // (i.e. when the server accepts only parts of the data and rejects the rest) // the server MUST initialize the `partial_success` field and MUST // set the `rejected_` with the number of items it rejected. // // Servers MAY also make use of the `partial_success` field to convey // warnings/suggestions to senders even when the request was fully accepted. // In such cases, the `rejected_` MUST have a value of `0` and // the `error_message` MUST be non-empty. // // A `partial_success` message with an empty value (rejected_ = 0 and // `error_message` = "") is equivalent to it not being set/present. Senders // SHOULD interpret it the same way as in the full success case. ExportProfilesPartialSuccess partial_success = 1; } // Status: [Alpha] message ExportProfilesPartialSuccess { // The number of rejected profiles. // // A `rejected_` field holding a `0` value indicates that the // request was fully accepted. int64 rejected_profiles = 1; // A developer-facing human-readable message in English. It should be used // either to explain why the server rejected parts of the data during a partial // success or to convey warnings/suggestions during a full success. The message // should offer guidance on how users can address such issues. // // error_message is an optional field. An error_message with an empty value // is equivalent to it not being set. string error_message = 2; } profiles_service_http.yaml000066400000000000000000000005261522767421700406700ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/profiles/v1development# This is an API configuration to generate an HTTP/JSON -> gRPC gateway for the # OpenTelemetry service using github.com/grpc-ecosystem/grpc-gateway. type: google.api.Service config_version: 3 http: rules: - selector: opentelemetry.proto.collector.profiles.v1development.ProfilesService.Export post: /v1development/profiles body: "*" open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/trace/000077500000000000000000000000001522767421700301405ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/trace/v1/000077500000000000000000000000001522767421700304665ustar00rootroot00000000000000trace_service.proto000066400000000000000000000065171522767421700343230ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/trace/v1// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.collector.trace.v1; import "opentelemetry/proto/trace/v1/trace.proto"; option csharp_namespace = "OpenTelemetry.Proto.Collector.Trace.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.collector.trace.v1"; option java_outer_classname = "TraceServiceProto"; option go_package = "go.opentelemetry.io/proto/otlp/collector/trace/v1"; // Service that can be used to push spans between one Application instrumented with // OpenTelemetry and a collector, or between a collector and a central collector (in this // case spans are sent/received to/from multiple Applications). service TraceService { rpc Export(ExportTraceServiceRequest) returns (ExportTraceServiceResponse) {} } message ExportTraceServiceRequest { // An array of ResourceSpans. // For data coming from a single resource this array will typically contain one // element. Intermediary nodes (such as OpenTelemetry Collector) that receive // data from multiple origins typically batch the data before forwarding further and // in that case this array will contain multiple elements. repeated opentelemetry.proto.trace.v1.ResourceSpans resource_spans = 1; } message ExportTraceServiceResponse { // The details of a partially successful export request. // // If the request is only partially accepted // (i.e. when the server accepts only parts of the data and rejects the rest) // the server MUST initialize the `partial_success` field and MUST // set the `rejected_` with the number of items it rejected. // // Servers MAY also make use of the `partial_success` field to convey // warnings/suggestions to senders even when the request was fully accepted. // In such cases, the `rejected_` MUST have a value of `0` and // the `error_message` MUST be non-empty. // // A `partial_success` message with an empty value (rejected_ = 0 and // `error_message` = "") is equivalent to it not being set/present. Senders // SHOULD interpret it the same way as in the full success case. ExportTracePartialSuccess partial_success = 1; } message ExportTracePartialSuccess { // The number of rejected spans. // // A `rejected_` field holding a `0` value indicates that the // request was fully accepted. int64 rejected_spans = 1; // A developer-facing human-readable message in English. It should be used // either to explain why the server rejected parts of the data during a partial // success or to convey warnings/suggestions during a full success. The message // should offer guidance on how users can address such issues. // // error_message is an optional field. An error_message with an empty value // is equivalent to it not being set. string error_message = 2; } trace_service_http.yaml000066400000000000000000000004701522767421700351510ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/collector/trace/v1# This is an API configuration to generate an HTTP/JSON -> gRPC gateway for the # OpenTelemetry service using github.com/grpc-ecosystem/grpc-gateway. type: google.api.Service config_version: 3 http: rules: - selector: opentelemetry.proto.collector.trace.v1.TraceService.Export post: /v1/traces body: "*" open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/common/000077500000000000000000000000001522767421700263445ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/common/v1/000077500000000000000000000000001522767421700266725ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/common/v1/common.proto000066400000000000000000000146161522767421700312570ustar00rootroot00000000000000// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.common.v1; option csharp_namespace = "OpenTelemetry.Proto.Common.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.common.v1"; option java_outer_classname = "CommonProto"; option go_package = "go.opentelemetry.io/proto/otlp/common/v1"; // Represents any type of attribute value. AnyValue may contain a // primitive value such as a string or integer or it may contain an arbitrary nested // object containing arrays, key-value lists and primitives. message AnyValue { // The value is one of the listed fields. It is valid for all values to be unspecified // in which case this AnyValue is considered to be "empty". oneof value { string string_value = 1; bool bool_value = 2; int64 int_value = 3; double double_value = 4; ArrayValue array_value = 5; KeyValueList kvlist_value = 6; bytes bytes_value = 7; // Reference to the string value in ProfilesDictionary.string_table. // // Note: This is currently used exclusively in the Profiling signal. // Implementers of OTLP receivers for signals other than Profiling should // treat the presence of this value as a non-fatal issue. // Log an error or warning indicating an unexpected field intended for the // Profiling signal and process the data as if this value were absent or // empty, ignoring its semantic content for the non-Profiling signal. // // Status: [Alpha] int32 string_value_strindex = 8; } } // ArrayValue is a list of AnyValue messages. We need ArrayValue as a message // since oneof in AnyValue does not allow repeated fields. message ArrayValue { // Array of values. The array may be empty (contain 0 elements). repeated AnyValue values = 1; } // KeyValueList is a list of KeyValue messages. We need KeyValueList as a message // since `oneof` in AnyValue does not allow repeated fields. Everywhere else where we need // a list of KeyValue messages (e.g. in Span) we use `repeated KeyValue` directly to // avoid unnecessary extra wrapping (which slows down the protocol). The 2 approaches // are semantically equivalent. message KeyValueList { // A collection of key/value pairs of key-value pairs. The list may be empty (may // contain 0 elements). // // The keys MUST be unique (it is not allowed to have more than one // value with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated KeyValue values = 1; } // Represents a key-value pair that is used to store Span attributes, Link // attributes, etc. message KeyValue { // The key name of the pair. // key_strindex MUST NOT be set if key is used. string key = 1; // The value of the pair. AnyValue value = 2; // Reference to the string key in ProfilesDictionary.string_table. // key MUST NOT be set if key_strindex is used. // // Note: This is currently used exclusively in the Profiling signal. // Implementers of OTLP receivers for signals other than Profiling should // treat the presence of this key as a non-fatal issue. // Log an error or warning indicating an unexpected field intended for the // Profiling signal and process the data as if this value were absent or // empty, ignoring its semantic content for the non-Profiling signal. // // Status: [Alpha] int32 key_strindex = 3; } // InstrumentationScope is a message representing the instrumentation scope information // such as the fully qualified name and version. message InstrumentationScope { // A name denoting the Instrumentation scope. // An empty instrumentation scope name means the name is unknown. string name = 1; // Defines the version of the instrumentation scope. // An empty instrumentation scope version means the version is unknown. string version = 2; // Additional attributes that describe the scope. [Optional]. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated KeyValue attributes = 3; // The number of attributes that were discarded. Attributes // can be discarded because their keys are too long or because there are too many // attributes. If this value is 0, then no attributes were dropped. uint32 dropped_attributes_count = 4; } // A reference to an Entity. // Entity represents an object of interest associated with produced telemetry: e.g spans, metrics, profiles, or logs. // // Status: [Development] message EntityRef { // The Schema URL, if known. This is the identifier of the Schema that the entity data // is recorded in. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // // This schema_url applies to the data in this message and to the Resource attributes // referenced by id_keys and description_keys. // TODO: discuss if we are happy with this somewhat complicated definition of what // the schema_url applies to. // // This field obsoletes the schema_url field in ResourceMetrics/ResourceSpans/ResourceLogs. string schema_url = 1; // Defines the type of the entity. MUST not change during the lifetime of the entity. // For example: "service" or "host". This field is required and MUST not be empty // for valid entities. string type = 2; // Attribute Keys that identify the entity. // MUST not change during the lifetime of the entity. The Id must contain at least one attribute. // These keys MUST exist in the containing {message}.attributes. repeated string id_keys = 3; // Descriptive (non-identifying) attribute keys of the entity. // MAY change over the lifetime of the entity. MAY be empty. // These attribute keys are not part of entity's identity. // These keys MUST exist in the containing {message}.attributes. repeated string description_keys = 4; }open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/logs/000077500000000000000000000000001522767421700260205ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/logs/v1/000077500000000000000000000000001522767421700263465ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/logs/v1/logs.proto000066400000000000000000000225311522767421700304020ustar00rootroot00000000000000// Copyright 2020, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.logs.v1; import "opentelemetry/proto/common/v1/common.proto"; import "opentelemetry/proto/resource/v1/resource.proto"; option csharp_namespace = "OpenTelemetry.Proto.Logs.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.logs.v1"; option java_outer_classname = "LogsProto"; option go_package = "go.opentelemetry.io/proto/otlp/logs/v1"; // LogsData represents the logs data that can be stored in a persistent storage, // OR can be embedded by other protocols that transfer OTLP logs data but do not // implement the OTLP protocol. // // The main difference between this message and collector protocol is that // in this message there will not be any "control" or "metadata" specific to // OTLP protocol. // // When new fields are added into this message, the OTLP request MUST be updated // as well. message LogsData { // An array of ResourceLogs. // For data coming from a single resource this array will typically contain // one element. Intermediary nodes that receive data from multiple origins // typically batch the data before forwarding further and in that case this // array will contain multiple elements. repeated ResourceLogs resource_logs = 1; } // A collection of ScopeLogs from a Resource. message ResourceLogs { reserved 1000; // The resource for the logs in this message. // If this field is not set then resource info is unknown. opentelemetry.proto.resource.v1.Resource resource = 1; // A list of ScopeLogs that originate from a resource. repeated ScopeLogs scope_logs = 2; // The Schema URL, if known. This is the identifier of the Schema that the resource data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "resource" field. It does not apply // to the data in the "scope_logs" field which have their own schema_url field. string schema_url = 3; } // A collection of Logs produced by a Scope. message ScopeLogs { // The instrumentation scope information for the logs in this message. // Semantically when InstrumentationScope isn't set, it is equivalent with // an empty instrumentation scope name (unknown). opentelemetry.proto.common.v1.InstrumentationScope scope = 1; // A list of log records. repeated LogRecord log_records = 2; // The Schema URL, if known. This is the identifier of the Schema that the log data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "scope" field and all logs in the // "log_records" field. string schema_url = 3; } // Possible values for LogRecord.SeverityNumber. enum SeverityNumber { SEVERITY_NUMBER_UNSPECIFIED = 0; SEVERITY_NUMBER_TRACE = 1; SEVERITY_NUMBER_TRACE2 = 2; SEVERITY_NUMBER_TRACE3 = 3; SEVERITY_NUMBER_TRACE4 = 4; SEVERITY_NUMBER_DEBUG = 5; SEVERITY_NUMBER_DEBUG2 = 6; SEVERITY_NUMBER_DEBUG3 = 7; SEVERITY_NUMBER_DEBUG4 = 8; SEVERITY_NUMBER_INFO = 9; SEVERITY_NUMBER_INFO2 = 10; SEVERITY_NUMBER_INFO3 = 11; SEVERITY_NUMBER_INFO4 = 12; SEVERITY_NUMBER_WARN = 13; SEVERITY_NUMBER_WARN2 = 14; SEVERITY_NUMBER_WARN3 = 15; SEVERITY_NUMBER_WARN4 = 16; SEVERITY_NUMBER_ERROR = 17; SEVERITY_NUMBER_ERROR2 = 18; SEVERITY_NUMBER_ERROR3 = 19; SEVERITY_NUMBER_ERROR4 = 20; SEVERITY_NUMBER_FATAL = 21; SEVERITY_NUMBER_FATAL2 = 22; SEVERITY_NUMBER_FATAL3 = 23; SEVERITY_NUMBER_FATAL4 = 24; } // LogRecordFlags represents constants used to interpret the // LogRecord.flags field, which is protobuf 'fixed32' type and is to // be used as bit-fields. Each non-zero value defined in this enum is // a bit-mask. To extract the bit-field, for example, use an // expression like: // // (logRecord.flags & LOG_RECORD_FLAGS_TRACE_FLAGS_MASK) // enum LogRecordFlags { // The zero value for the enum. Should not be used for comparisons. // Instead use bitwise "and" with the appropriate mask as shown above. LOG_RECORD_FLAGS_DO_NOT_USE = 0; // Bits 0-7 are used for trace flags. LOG_RECORD_FLAGS_TRACE_FLAGS_MASK = 0x000000FF; // Bits 8-31 are reserved for future use. } // A log record according to OpenTelemetry Log Data Model: // https://github.com/open-telemetry/oteps/blob/main/text/logs/0097-log-data-model.md message LogRecord { reserved 4; // time_unix_nano is the time when the event occurred. // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. // Value of 0 indicates unknown or missing timestamp. fixed64 time_unix_nano = 1; // Time when the event was observed by the collection system. // For events that originate in OpenTelemetry (e.g. using OpenTelemetry Logging SDK) // this timestamp is typically set at the generation time and is equal to Timestamp. // For events originating externally and collected by OpenTelemetry (e.g. using // Collector) this is the time when OpenTelemetry's code observed the event measured // by the clock of the OpenTelemetry code. This field MUST be set once the event is // observed by OpenTelemetry. // // For converting OpenTelemetry log data to formats that support only one timestamp or // when receiving OpenTelemetry log data by recipients that support only one timestamp // internally the following logic is recommended: // - Use time_unix_nano if it is present, otherwise use observed_time_unix_nano. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. // Value of 0 indicates unknown or missing timestamp. fixed64 observed_time_unix_nano = 11; // Numerical value of the severity, normalized to values described in Log Data Model. // [Optional]. SeverityNumber severity_number = 2; // The severity text (also known as log level). The original string representation as // it is known at the source. [Optional]. string severity_text = 3; // A value containing the body of the log record. Can be for example a human-readable // string message (including multi-line) describing the event in a free form or it can // be a structured data composed of arrays and maps of other values. [Optional]. opentelemetry.proto.common.v1.AnyValue body = 5; // Additional attributes that describe the specific event occurrence. [Optional]. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 6; uint32 dropped_attributes_count = 7; // Flags, a bit field. 8 least significant bits are the trace flags as // defined in W3C Trace Context specification. 24 most significant bits are reserved // and must be set to 0. Readers must not assume that 24 most significant bits // will be zero and must correctly mask the bits when reading 8-bit trace flag (use // flags & LOG_RECORD_FLAGS_TRACE_FLAGS_MASK). [Optional]. fixed32 flags = 8; // A unique identifier for a trace. All logs from the same trace share // the same `trace_id`. The ID is a 16-byte array. An ID with all zeroes OR // of length other than 16 bytes is considered invalid (empty string in OTLP/JSON // is zero-length and thus is also invalid). // // This field is optional. // // The receivers SHOULD assume that the log record is not associated with a // trace if any of the following is true: // - the field is not present, // - the field contains an invalid value. bytes trace_id = 9; // A unique identifier for a span within a trace, assigned when the span // is created. The ID is an 8-byte array. An ID with all zeroes OR of length // other than 8 bytes is considered invalid (empty string in OTLP/JSON // is zero-length and thus is also invalid). // // This field is optional. If the sender specifies a valid span_id then it SHOULD also // specify a valid trace_id. // // The receivers SHOULD assume that the log record is not associated with a // span if any of the following is true: // - the field is not present, // - the field contains an invalid value. bytes span_id = 10; // A unique identifier of event category/type. // All events with the same event_name are expected to conform to the same // schema for both their attributes and their body. // // Recommended to be fully qualified and short (no longer than 256 characters). // // Presence of event_name on the log record identifies this record // as an event. // // [Optional]. string event_name = 12; } open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/metrics/000077500000000000000000000000001522767421700265225ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/metrics/v1/000077500000000000000000000000001522767421700270505ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/metrics/v1/metrics.proto000066400000000000000000000762501522767421700316150ustar00rootroot00000000000000// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.metrics.v1; import "opentelemetry/proto/common/v1/common.proto"; import "opentelemetry/proto/resource/v1/resource.proto"; option csharp_namespace = "OpenTelemetry.Proto.Metrics.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.metrics.v1"; option java_outer_classname = "MetricsProto"; option go_package = "go.opentelemetry.io/proto/otlp/metrics/v1"; // MetricsData represents the metrics data that can be stored in a persistent // storage, OR can be embedded by other protocols that transfer OTLP metrics // data but do not implement the OTLP protocol. // // MetricsData // └─── ResourceMetrics // ├── Resource // ├── SchemaURL // └── ScopeMetrics // ├── Scope // ├── SchemaURL // └── Metric // ├── Name // ├── Description // ├── Unit // └── data // ├── Gauge // ├── Sum // ├── Histogram // ├── ExponentialHistogram // └── Summary // // The main difference between this message and collector protocol is that // in this message there will not be any "control" or "metadata" specific to // OTLP protocol. // // When new fields are added into this message, the OTLP request MUST be updated // as well. message MetricsData { // An array of ResourceMetrics. // For data coming from a single resource this array will typically contain // one element. Intermediary nodes that receive data from multiple origins // typically batch the data before forwarding further and in that case this // array will contain multiple elements. repeated ResourceMetrics resource_metrics = 1; } // A collection of ScopeMetrics from a Resource. message ResourceMetrics { reserved 1000; // The resource for the metrics in this message. // If this field is not set then no resource info is known. opentelemetry.proto.resource.v1.Resource resource = 1; // A list of metrics that originate from a resource. repeated ScopeMetrics scope_metrics = 2; // The Schema URL, if known. This is the identifier of the Schema that the resource data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "resource" field. It does not apply // to the data in the "scope_metrics" field which have their own schema_url field. string schema_url = 3; } // A collection of Metrics produced by an Scope. message ScopeMetrics { // The instrumentation scope information for the metrics in this message. // Semantically when InstrumentationScope isn't set, it is equivalent with // an empty instrumentation scope name (unknown). opentelemetry.proto.common.v1.InstrumentationScope scope = 1; // A list of metrics that originate from an instrumentation library. repeated Metric metrics = 2; // The Schema URL, if known. This is the identifier of the Schema that the metric data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "scope" field and all metrics in the // "metrics" field. string schema_url = 3; } // Defines a Metric which has one or more timeseries. The following is a // brief summary of the Metric data model. For more details, see: // // https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/data-model.md // // The data model and relation between entities is shown in the // diagram below. Here, "DataPoint" is the term used to refer to any // one of the specific data point value types, and "points" is the term used // to refer to any one of the lists of points contained in the Metric. // // - Metric is composed of a metadata and data. // - Metadata part contains a name, description, unit. // - Data is one of the possible types (Sum, Gauge, Histogram, Summary). // - DataPoint contains timestamps, attributes, and one of the possible value type // fields. // // Metric // +------------+ // |name | // |description | // |unit | +------------------------------------+ // |data |---> |Gauge, Sum, Histogram, Summary, ... | // +------------+ +------------------------------------+ // // Data [One of Gauge, Sum, Histogram, Summary, ...] // +-----------+ // |... | // Metadata about the Data. // |points |--+ // +-----------+ | // | +---------------------------+ // | |DataPoint 1 | // v |+------+------+ +------+ | // +-----+ ||label |label |...|label | | // | 1 |-->||value1|value2|...|valueN| | // +-----+ |+------+------+ +------+ | // | . | |+-----+ | // | . | ||value| | // | . | |+-----+ | // | . | +---------------------------+ // | . | . // | . | . // | . | . // | . | +---------------------------+ // | . | |DataPoint M | // +-----+ |+------+------+ +------+ | // | M |-->||label |label |...|label | | // +-----+ ||value1|value2|...|valueN| | // |+------+------+ +------+ | // |+-----+ | // ||value| | // |+-----+ | // +---------------------------+ // // Each distinct type of DataPoint represents the output of a specific // aggregation function, the result of applying the DataPoint's // associated function of to one or more measurements. // // All DataPoint types have three common fields: // - Attributes includes key-value pairs associated with the data point // - TimeUnixNano is required, set to the end time of the aggregation // - StartTimeUnixNano is optional, but strongly encouraged for DataPoints // having an AggregationTemporality field, as discussed below. // // Both TimeUnixNano and StartTimeUnixNano values are expressed as // UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. // // # TimeUnixNano // // This field is required, having consistent interpretation across // DataPoint types. TimeUnixNano is the moment corresponding to when // the data point's aggregate value was captured. // // Data points with the 0 value for TimeUnixNano SHOULD be rejected // by consumers. // // # StartTimeUnixNano // // StartTimeUnixNano in general allows detecting when a sequence of // observations is unbroken. This field indicates to consumers the // start time for points with cumulative and delta // AggregationTemporality, and it should be included whenever possible // to support correct rate calculation. Although it may be omitted // when the start time is truly unknown, setting StartTimeUnixNano is // strongly encouraged. message Metric { reserved 4, 6, 8; // The name of the metric. string name = 1; // A description of the metric, which can be used in documentation. string description = 2; // The unit in which the metric value is reported. Follows the format // described by https://ucum.org/ucum and https://units-of-measurement.org/ string unit = 3; // Data determines the aggregation type (if any) of the metric, what is the // reported value type for the data points, as well as the relatationship to // the time interval over which they are reported. oneof data { Gauge gauge = 5; Sum sum = 7; Histogram histogram = 9; ExponentialHistogram exponential_histogram = 10; Summary summary = 11; } // Additional metadata attributes that describe the metric. [Optional]. // Attributes are non-identifying. // Consumers SHOULD NOT need to be aware of these attributes. // These attributes MAY be used to encode information allowing // for lossless roundtrip translation to / from another data model. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue metadata = 12; } // Gauge represents the type of a scalar metric that always exports the // "current value" for every data point. It should be used for an "unknown" // aggregation. // // A Gauge does not support different aggregation temporalities. Given the // aggregation is unknown, points cannot be combined using the same // aggregation, regardless of aggregation temporalities. Therefore, // AggregationTemporality is not included. Consequently, this also means // "StartTimeUnixNano" is ignored for all data points. message Gauge { // The time series data points. // Note: Multiple time series may be included (same timestamp, different attributes). repeated NumberDataPoint data_points = 1; } // Sum represents the type of a scalar metric that is calculated as a sum of all // reported measurements over a time interval. message Sum { // The time series data points. // Note: Multiple time series may be included (same timestamp, different attributes). repeated NumberDataPoint data_points = 1; // aggregation_temporality describes if the aggregator reports delta changes // since last report time, or cumulative changes since a fixed start time. AggregationTemporality aggregation_temporality = 2; // Represents whether the sum is monotonic. bool is_monotonic = 3; } // Histogram represents the type of a metric that is calculated by aggregating // as a Histogram of all reported measurements over a time interval. message Histogram { // The time series data points. // Note: Multiple time series may be included (same timestamp, different attributes). repeated HistogramDataPoint data_points = 1; // aggregation_temporality describes if the aggregator reports delta changes // since last report time, or cumulative changes since a fixed start time. AggregationTemporality aggregation_temporality = 2; } // ExponentialHistogram represents the type of a metric that is calculated by aggregating // as a ExponentialHistogram of all reported double measurements over a time interval. message ExponentialHistogram { // The time series data points. // Note: Multiple time series may be included (same timestamp, different attributes). repeated ExponentialHistogramDataPoint data_points = 1; // aggregation_temporality describes if the aggregator reports delta changes // since last report time, or cumulative changes since a fixed start time. AggregationTemporality aggregation_temporality = 2; } // Summary metric data are used to convey quantile summaries, // a Prometheus (see: https://prometheus.io/docs/concepts/metric_types/#summary) // and OpenMetrics (see: https://github.com/prometheus/OpenMetrics/blob/4dbf6075567ab43296eed941037c12951faafb92/protos/prometheus.proto#L45) // data type. These data points cannot always be merged in a meaningful way. // While they can be useful in some applications, histogram data points are // recommended for new applications. // Summary metrics do not have an aggregation temporality field. This is // because the count and sum fields of a SummaryDataPoint are assumed to be // cumulative values. message Summary { // The time series data points. // Note: Multiple time series may be included (same timestamp, different attributes). repeated SummaryDataPoint data_points = 1; } // AggregationTemporality defines how a metric aggregator reports aggregated // values. It describes how those values relate to the time interval over // which they are aggregated. enum AggregationTemporality { // UNSPECIFIED is the default AggregationTemporality, it MUST not be used. AGGREGATION_TEMPORALITY_UNSPECIFIED = 0; // DELTA is an AggregationTemporality for a metric aggregator which reports // changes since last report time. Successive metrics contain aggregation of // values from continuous and non-overlapping intervals. // // The values for a DELTA metric are based only on the time interval // associated with one measurement cycle. There is no dependency on // previous measurements like is the case for CUMULATIVE metrics. // // For example, consider a system measuring the number of requests that // it receives and reports the sum of these requests every second as a // DELTA metric: // // 1. The system starts receiving at time=t_0. // 2. A request is received, the system measures 1 request. // 3. A request is received, the system measures 1 request. // 4. A request is received, the system measures 1 request. // 5. The 1 second collection cycle ends. A metric is exported for the // number of requests received over the interval of time t_0 to // t_0+1 with a value of 3. // 6. A request is received, the system measures 1 request. // 7. A request is received, the system measures 1 request. // 8. The 1 second collection cycle ends. A metric is exported for the // number of requests received over the interval of time t_0+1 to // t_0+2 with a value of 2. AGGREGATION_TEMPORALITY_DELTA = 1; // CUMULATIVE is an AggregationTemporality for a metric aggregator which // reports changes since a fixed start time. This means that current values // of a CUMULATIVE metric depend on all previous measurements since the // start time. Because of this, the sender is required to retain this state // in some form. If this state is lost or invalidated, the CUMULATIVE metric // values MUST be reset and a new fixed start time following the last // reported measurement time sent MUST be used. // // For example, consider a system measuring the number of requests that // it receives and reports the sum of these requests every second as a // CUMULATIVE metric: // // 1. The system starts receiving at time=t_0. // 2. A request is received, the system measures 1 request. // 3. A request is received, the system measures 1 request. // 4. A request is received, the system measures 1 request. // 5. The 1 second collection cycle ends. A metric is exported for the // number of requests received over the interval of time t_0 to // t_0+1 with a value of 3. // 6. A request is received, the system measures 1 request. // 7. A request is received, the system measures 1 request. // 8. The 1 second collection cycle ends. A metric is exported for the // number of requests received over the interval of time t_0 to // t_0+2 with a value of 5. // 9. The system experiences a fault and loses state. // 10. The system recovers and resumes receiving at time=t_1. // 11. A request is received, the system measures 1 request. // 12. The 1 second collection cycle ends. A metric is exported for the // number of requests received over the interval of time t_1 to // t_0+1 with a value of 1. // // Note: Even though, when reporting changes since last report time, using // CUMULATIVE is valid, it is not recommended. This may cause problems for // systems that do not use start_time to determine when the aggregation // value was reset (e.g. Prometheus). AGGREGATION_TEMPORALITY_CUMULATIVE = 2; } // DataPointFlags is defined as a protobuf 'uint32' type and is to be used as a // bit-field representing 32 distinct boolean flags. Each flag defined in this // enum is a bit-mask. To test the presence of a single flag in the flags of // a data point, for example, use an expression like: // // (point.flags & DATA_POINT_FLAGS_NO_RECORDED_VALUE_MASK) == DATA_POINT_FLAGS_NO_RECORDED_VALUE_MASK // enum DataPointFlags { // The zero value for the enum. Should not be used for comparisons. // Instead use bitwise "and" with the appropriate mask as shown above. DATA_POINT_FLAGS_DO_NOT_USE = 0; // This DataPoint is valid but has no recorded value. This value // SHOULD be used to reflect explicitly missing data in a series, as // for an equivalent to the Prometheus "staleness marker". DATA_POINT_FLAGS_NO_RECORDED_VALUE_MASK = 1; // Bits 2-31 are reserved for future use. } // NumberDataPoint is a single data point in a timeseries that describes the // time-varying scalar value of a metric. message NumberDataPoint { reserved 1; // The set of key/value pairs that uniquely identify the timeseries from // where this point belongs. The list may be empty (may contain 0 elements). // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 7; // StartTimeUnixNano is optional but strongly encouraged, see the // the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 start_time_unix_nano = 2; // TimeUnixNano is required, see the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 time_unix_nano = 3; // The value itself. A point is considered invalid when one of the recognized // value fields is not present inside this oneof. oneof value { double as_double = 4; sfixed64 as_int = 6; } // (Optional) List of exemplars collected from // measurements that were used to form the data point repeated Exemplar exemplars = 5; // Flags that apply to this specific data point. See DataPointFlags // for the available flags and their meaning. uint32 flags = 8; } // HistogramDataPoint is a single data point in a timeseries that describes the // time-varying values of a Histogram. A Histogram contains summary statistics // for a population of values, it may optionally contain the distribution of // those values across a set of buckets. // // If the histogram contains the distribution of values, then both // "explicit_bounds" and "bucket counts" fields must be defined. // If the histogram does not contain the distribution of values, then both // "explicit_bounds" and "bucket_counts" must be omitted and only "count" and // "sum" are known. message HistogramDataPoint { reserved 1; // The set of key/value pairs that uniquely identify the timeseries from // where this point belongs. The list may be empty (may contain 0 elements). // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 9; // StartTimeUnixNano is optional but strongly encouraged, see the // the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 start_time_unix_nano = 2; // TimeUnixNano is required, see the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 time_unix_nano = 3; // count is the number of values in the population. Must be non-negative. This // value must be equal to the sum of the "count" fields in buckets if a // histogram is provided. fixed64 count = 4; // sum of the values in the population. If count is zero then this field // must be zero. // // Note: Sum should only be filled out when measuring non-negative discrete // events, and is assumed to be monotonic over the values of these events. // Negative events *can* be recorded, but sum should not be filled out when // doing so. This is specifically to enforce compatibility w/ OpenMetrics, // see: https://github.com/prometheus/OpenMetrics/blob/v1.0.0/specification/OpenMetrics.md#histogram optional double sum = 5; // bucket_counts is an optional field contains the count values of histogram // for each bucket. // // The sum of the bucket_counts must equal the value in the count field. // // The number of elements in bucket_counts array must be by one greater than // the number of elements in explicit_bounds array. The exception to this rule // is when the length of bucket_counts is 0, then the length of explicit_bounds // must also be 0. repeated fixed64 bucket_counts = 6; // explicit_bounds specifies buckets with explicitly defined bounds for values. // // The boundaries for bucket at index i are: // // (-infinity, explicit_bounds[i]] for i == 0 // (explicit_bounds[i-1], explicit_bounds[i]] for 0 < i < size(explicit_bounds) // (explicit_bounds[i-1], +infinity) for i == size(explicit_bounds) // // The values in the explicit_bounds array must be strictly increasing. // // Histogram buckets are inclusive of their upper boundary, except the last // bucket where the boundary is at infinity. This format is intentionally // compatible with the OpenMetrics histogram definition. // // If bucket_counts length is 0 then explicit_bounds length must also be 0, // otherwise the data point is invalid. repeated double explicit_bounds = 7; // (Optional) List of exemplars collected from // measurements that were used to form the data point repeated Exemplar exemplars = 8; // Flags that apply to this specific data point. See DataPointFlags // for the available flags and their meaning. uint32 flags = 10; // min is the minimum value over (start_time, end_time]. optional double min = 11; // max is the maximum value over (start_time, end_time]. optional double max = 12; } // ExponentialHistogramDataPoint is a single data point in a timeseries that describes the // time-varying values of a ExponentialHistogram of double values. A ExponentialHistogram contains // summary statistics for a population of values, it may optionally contain the // distribution of those values across a set of buckets. // message ExponentialHistogramDataPoint { // The set of key/value pairs that uniquely identify the timeseries from // where this point belongs. The list may be empty (may contain 0 elements). // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 1; // StartTimeUnixNano is optional but strongly encouraged, see the // the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 start_time_unix_nano = 2; // TimeUnixNano is required, see the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 time_unix_nano = 3; // The number of values in the population. Must be // non-negative. This value must be equal to the sum of the "bucket_counts" // values in the positive and negative Buckets plus the "zero_count" field. fixed64 count = 4; // The sum of the values in the population. If count is zero then this field // must be zero. // // Note: Sum should only be filled out when measuring non-negative discrete // events, and is assumed to be monotonic over the values of these events. // Negative events *can* be recorded, but sum should not be filled out when // doing so. This is specifically to enforce compatibility w/ OpenMetrics, // see: https://github.com/prometheus/OpenMetrics/blob/v1.0.0/specification/OpenMetrics.md#histogram optional double sum = 5; // scale describes the resolution of the histogram. Boundaries are // located at powers of the base, where: // // base = (2^(2^-scale)) // // The histogram bucket identified by `index`, a signed integer, // contains values that are greater than (base^index) and // less than or equal to (base^(index+1)). // // The positive and negative ranges of the histogram are expressed // separately. Negative values are mapped by their absolute value // into the negative range using the same scale as the positive range. // // scale is not restricted by the protocol, as the permissible // values depend on the range of the data. sint32 scale = 6; // The count of values that are either exactly zero or // within the region considered zero by the instrumentation at the // tolerated degree of precision. This bucket stores values that // cannot be expressed using the standard exponential formula as // well as values that have been rounded to zero. // // Implementations MAY consider the zero bucket to have probability // mass equal to (zero_count / count). fixed64 zero_count = 7; // positive carries the positive range of exponential bucket counts. Buckets positive = 8; // negative carries the negative range of exponential bucket counts. Buckets negative = 9; // Buckets are a set of bucket counts, encoded in a contiguous array // of counts. message Buckets { // The bucket index of the first entry in the bucket_counts array. // // Note: This uses a varint encoding as a simple form of compression. sint32 offset = 1; // An array of count values, where bucket_counts[i] carries // the count of the bucket at index (offset+i). bucket_counts[i] is the count // of values greater than base^(offset+i) and less than or equal to // base^(offset+i+1). // // Note: By contrast, the explicit HistogramDataPoint uses // fixed64. This field is expected to have many buckets, // especially zeros, so uint64 has been selected to ensure // varint encoding. repeated uint64 bucket_counts = 2; } // Flags that apply to this specific data point. See DataPointFlags // for the available flags and their meaning. uint32 flags = 10; // (Optional) List of exemplars collected from // measurements that were used to form the data point repeated Exemplar exemplars = 11; // The minimum value over (start_time, end_time]. optional double min = 12; // The maximum value over (start_time, end_time]. optional double max = 13; // ZeroThreshold may be optionally set to convey the width of the zero // region. Where the zero region is defined as the closed interval // [-ZeroThreshold, ZeroThreshold]. // When ZeroThreshold is 0, zero count bucket stores values that cannot be // expressed using the standard exponential formula as well as values that // have been rounded to zero. double zero_threshold = 14; } // SummaryDataPoint is a single data point in a timeseries that describes the // time-varying values of a Summary metric. The count and sum fields represent // cumulative values. message SummaryDataPoint { reserved 1; // The set of key/value pairs that uniquely identify the timeseries from // where this point belongs. The list may be empty (may contain 0 elements). // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 7; // StartTimeUnixNano is optional but strongly encouraged, see the // the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 start_time_unix_nano = 2; // TimeUnixNano is required, see the detailed comments above Metric. // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 time_unix_nano = 3; // count is the number of values in the population. Must be non-negative. fixed64 count = 4; // sum of the values in the population. If count is zero then this field // must be zero. // // Note: Sum should only be filled out when measuring non-negative discrete // events, and is assumed to be monotonic over the values of these events. // Negative events *can* be recorded, but sum should not be filled out when // doing so. This is specifically to enforce compatibility w/ OpenMetrics, // see: https://github.com/prometheus/OpenMetrics/blob/v1.0.0/specification/OpenMetrics.md#summary double sum = 5; // Represents the value at a given quantile of a distribution. // // To record Min and Max values following conventions are used: // - The 1.0 quantile is equivalent to the maximum value observed. // - The 0.0 quantile is equivalent to the minimum value observed. // // See the following issue for more context: // https://github.com/open-telemetry/opentelemetry-proto/issues/125 message ValueAtQuantile { // The quantile of a distribution. Must be in the interval // [0.0, 1.0]. double quantile = 1; // The value at the given quantile of a distribution. // // Quantile values must NOT be negative. double value = 2; } // (Optional) list of values at different quantiles of the distribution calculated // from the current snapshot. The quantiles must be strictly increasing. repeated ValueAtQuantile quantile_values = 6; // Flags that apply to this specific data point. See DataPointFlags // for the available flags and their meaning. uint32 flags = 8; } // A representation of an exemplar, which is a sample input measurement. // Exemplars also hold information about the environment when the measurement // was recorded, for example the span and trace ID of the active span when the // exemplar was recorded. message Exemplar { reserved 1; // The set of key/value pairs that were filtered out by the aggregator, but // recorded alongside the original measurement. Only key/value pairs that were // filtered out by the aggregator should be included repeated opentelemetry.proto.common.v1.KeyValue filtered_attributes = 7; // time_unix_nano is the exact time when this exemplar was recorded // // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January // 1970. fixed64 time_unix_nano = 2; // The value of the measurement that was recorded. An exemplar is // considered invalid when one of the recognized value fields is not present // inside this oneof. oneof value { double as_double = 3; sfixed64 as_int = 6; } // (Optional) Span ID of the exemplar trace. // span_id may be missing if the measurement is not recorded inside a trace // or if the trace is not sampled. bytes span_id = 4; // (Optional) Trace ID of the exemplar trace. // trace_id may be missing if the measurement is not recorded inside a trace // or if the trace is not sampled. bytes trace_id = 5; } open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/processcontext/000077500000000000000000000000001522767421700301375ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/processcontext/v1development/000077500000000000000000000000001522767421700327305ustar00rootroot00000000000000process_context.proto000066400000000000000000000046421522767421700371660ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/processcontext/v1development// Copyright The OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.processcontext.v1development; import "opentelemetry/proto/common/v1/common.proto"; import "opentelemetry/proto/resource/v1/resource.proto"; option csharp_namespace = "OpenTelemetry.Proto.ProcessContext.V1Development"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.processcontext.v1development"; option java_outer_classname = "ProcessContextProto"; option go_package = "go.opentelemetry.io/proto/otlp/processcontext/v1development"; // ProcessContext represents the payload for the process context sharing mechanism. // // This message is designed to be published by OpenTelemetry SDKs via a memory-mapped // region, allowing external readers (such as the OpenTelemetry eBPF Profiler) to // discover and read resource attributes from instrumented processes without requiring // direct integration or process activity. It is not part of OTLP and is not // exchanged via the OpenTelemetry Collector. // // See OTEP 4719 (https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/4719-process-ctx.md) // for details of this mechanism. // // Status: [Development] message ProcessContext { // The resource for this process. // If this field is not set then no resource info is known. opentelemetry.proto.resource.v1.Resource resource = 1; // Additional attributes to share with external readers that are not part of // the standard Resource. [Optional] // // This field allows publishers to include supplementary key-value pairs that // may be useful for external readers but are not part of the SDK's configured // Resource. // // Consider adding any keys here to the profiles semantic conventions in // https://opentelemetry.io/docs/specs/semconv/general/profiles/ repeated opentelemetry.proto.common.v1.KeyValue attributes = 2; } open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/profiles/000077500000000000000000000000001522767421700266775ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/profiles/v1development/000077500000000000000000000000001522767421700314705ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/profiles/v1development/profiles.proto000066400000000000000000000577251522767421700344200ustar00rootroot00000000000000// Copyright 2023, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. // // This file includes work covered by the following copyright and permission notices: // // Copyright 2016 Google Inc. All Rights Reserved. // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.profiles.v1development; import "opentelemetry/proto/common/v1/common.proto"; import "opentelemetry/proto/resource/v1/resource.proto"; option csharp_namespace = "OpenTelemetry.Proto.Profiles.V1Development"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.profiles.v1development"; option java_outer_classname = "ProfilesProto"; option go_package = "go.opentelemetry.io/proto/otlp/profiles/v1development"; // Relationships Diagram // // ┌──────────────────┐ LEGEND // │ ProfilesData │ ─────┐ // └──────────────────┘ │ ─────▶ embedded // │ │ // │ 1-n │ ─────▷ referenced by index // ▼ ▼ // ┌──────────────────┐ ┌────────────────────┐ // │ ResourceProfiles │ │ ProfilesDictionary │ // └──────────────────┘ └────────────────────┘ // │ // │ 1-n // ▼ // ┌──────────────────┐ // │ ScopeProfiles │ // └──────────────────┘ // │ // │ 1-n // ▼ // ┌──────────────────┐ // │ Profile │ // └──────────────────┘ // │ n-1 // │ 1-n ┌───────────────────────────────────────┐ // ▼ │ ▽ // ┌──────────────────┐ n-n ┌─────────────────┐ ┌──────────┐ // │ Sample │ ──────▷ │ KeyValueAndUnit │ │ Link │ // └──────────────────┘ └─────────────────┘ └──────────┘ // │ △ △ // │ n-1 │ │ n-n // ▽ │ │ // ┌──────────────────┐ │ │ // │ Stack │ │ │ // └──────────────────┘ │ │ // │ n-n │ │ // │ n-n ┌────────────────┘ │ // ▽ │ │ // ┌──────────────────┐ n-1 ┌─────────────┐ // │ Location │ ──────▷ │ Mapping │ // └──────────────────┘ └─────────────┘ // │ // │ 1-n // ▼ // ┌──────────────────┐ // │ Line │ // └──────────────────┘ // │ // │ n-1 // ▽ // ┌──────────────────┐ // │ Function │ // └──────────────────┘ // // ProfilesDictionary contains all the dictionary tables that are shared // across the entire ProfilesData message. // // The following applies to all fields in this message: // // - A dictionary is an array of dictionary items. Users of the dictionary // compactly reference the items using the index within the array. // // - The element at index 0 MUST be the zero value for the dictionary's element // type (e.g. `""` for `string_table`, `Location{}` for `location_table`). This // allows for _index fields pointing into the dictionary to use a 0 pointer // value to indicate 'null' / 'not set'. Unless otherwise defined, a 'zero // value' message value is one with all default field values, so as to // minimize wire encoded size. // // - There SHOULD NOT be duplicate items in a dictionary. The identity of a // dictionary item is based on its value, recursively as needed. If a particular // implementation does emit duplicate items, it MUST NOT attempt to give them // meaning based on the index or order. A profile processor MAY remove // duplicates and this MUST NOT have any observable effects for consumers. // // - There SHOULD NOT be orphaned (unreferenced) items in a dictionary. A // profile processor MAY remove ("garbage-collect") orphaned items and this // MUST NOT have any observable effects for consumers. // // Status: [Alpha] message ProfilesDictionary { // Mappings from address ranges to the image/binary/library mapped // into that address range referenced by locations via Location.mapping_index. // // mapping_table[0] MUST be the zero value (Mapping{}) and present. repeated Mapping mapping_table = 1; // Locations referenced by samples via Stack.location_indices. // // location_table[0] MUST be the zero value (Location{}) and present. repeated Location location_table = 2; // Functions referenced by locations via Line.function_index. // // function_table[0] MUST be the zero value (Function{}) and present. repeated Function function_table = 3; // Links referenced by samples via Sample.link_index. // // link_table[0] MUST be the zero value (Link{}) and present. // Note that whilst Link{trace_id=array[0], span_id=array[0]} and // Link{trace_id=array[16], span_id=array[8]} filled with zero-value bytes // are both appropriate zero/invalid values per the trace.proto:Span definition, // the latter SHOULD be used for link_table[0] for better compatibility with codecs // strictly expecting 16/8 byte array lengths. repeated Link link_table = 4; // A common table for strings referenced by various messages. // // string_table[0] MUST be "" and present. repeated string string_table = 5; // A common table for attributes referenced by the Profile, Sample, Mapping // and Location messages, through their attribute_indices field. Each entry is // a key/value pair with an optional unit in UCUM format. Since this is a // dictionary table, multiple entries with the same key MAY be present, // unlike direct attribute tables like Resource.attributes. // However, the referencing attribute_indices fields MUST maintain the key // uniqueness requirement. // // It's recommended to use attributes for variables with bounded cardinality, // such as categorical variables // (https://en.wikipedia.org/wiki/Categorical_variable). Using an attribute of // a floating point type (e.g., CPU time) in a sample can quickly make every // attribute value unique, defeating the purpose of the dictionary and // impractically increasing the profile size. // // Examples of attributes: // "/http/user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" // "abc.com/myattribute": true // "allocation_size": 128 bytes // // attribute_table[0] MUST be the zero value (KeyValueAndUnit{}) and present. repeated KeyValueAndUnit attribute_table = 6; // Stacks referenced by samples via Sample.stack_index. // // stack_table[0] MUST be the zero value (Stack{}) and present. repeated Stack stack_table = 7; } // ProfilesData represents the profiles data that can be stored in persistent storage, // OR can be embedded by other protocols that transfer OTLP profiles data but do not // implement the OTLP protocol. // // The main difference between this message and collector protocol is that // in this message there will not be any "control" or "metadata" specific to // OTLP protocol. // // When new fields are added into this message, the OTLP request MUST be updated // as well. // // Status: [Alpha] message ProfilesData { // An array of ResourceProfiles. // For data coming from an SDK profiler, this array will typically contain one // element. Host-level profilers will usually create one ResourceProfile per // container, as well as one additional ResourceProfile grouping all samples // from non-containerized processes. // Other resource groupings are possible as well and clarified via // Resource.attributes and semantic conventions. // Tools that visualize profiles SHOULD prefer displaying // resources_profiles[0].scope_profiles[0].profiles[0] by default. repeated ResourceProfiles resource_profiles = 1; // A single instance of ProfilesDictionary shared across the entire message. ProfilesDictionary dictionary = 2; } // A collection of ScopeProfiles from a Resource. // // Status: [Alpha] message ResourceProfiles { reserved 1000; // The resource for the profiles in this message. // If this field is not set then no resource info is known. opentelemetry.proto.resource.v1.Resource resource = 1; // A list of ScopeProfiles that originate from this resource. repeated ScopeProfiles scope_profiles = 2; // The Schema URL, if known. This is the identifier of the Schema that the resource data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "resource" field. It does not apply // to the data in the "scope_profiles" field, which has its own schema_url field. string schema_url = 3; } // A collection of Profiles produced by an InstrumentationScope. // // Status: [Alpha] message ScopeProfiles { // The instrumentation scope information for the profiles in this message. // Semantically when InstrumentationScope isn't set, it is equivalent with // an empty instrumentation scope name (unknown). opentelemetry.proto.common.v1.InstrumentationScope scope = 1; // A list of Profiles that originate from this instrumentation scope. repeated Profile profiles = 2; // The Schema URL, if known. This is the identifier of the Schema that the profile data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "scope" field and all profiles in the // "profiles" field. string schema_url = 3; } // Profile is a common stacktrace profile format. // // Measurements represented with this format should follow the // following conventions: // // - Consumers SHOULD treat unset optional fields as if they had been // set with their default value. We discourage using the protobuf // presence semantics, even if available in the protobuf generated API. // // - When possible, measurements SHOULD be stored in "unsampled" form // that is most useful to humans. There should be enough // information present to determine the original sampled values. // // - The profile is represented as a set of samples, where each sample // references a stack trace which is a list of locations, each belonging // to a mapping. // // - There is a N->1 relationship from Stack.location_indices entries to // locations. For every Stack.location_indices entry there MUST be a // unique Location with that index. // // - There is an optional N->1 relationship from locations to // mappings. For every nonzero Location.mapping_id there MUST be a // unique Mapping with that index. // Represents a complete profile, including sample types, samples, mappings to // binaries, stacks, locations, functions, string table, and additional // metadata. It modifies and annotates pprof Profile with OpenTelemetry // specific fields. // // Status: [Alpha] message Profile { // The type and unit of all Sample.values in this profile. // For a cpu or off-cpu profile this might be: // ["cpu","nanoseconds"] or ["off_cpu","nanoseconds"] // For a heap profile, this might be: // ["allocated_objects","count"] or ["allocated_space","bytes"], ValueType sample_type = 1; // The set of samples recorded in this profile. repeated Sample samples = 2; // The following fields 3-12 are informational, do not affect // interpretation of results. // Time of collection (UTC) as nanoseconds since the UNIX epoch. fixed64 time_unix_nano = 3; // Duration of the profile in nanoseconds. For instant profiles like // live heap snapshot, the duration can be zero but it may be preferable // to set time_unix_nano to the process start time and duration_nano to // the relative time when the profile was gathered so that Sample.timestamps_unix_nano // values fall within the profile time range. uint64 duration_nano = 4; // The type and the unit of the events between sampled occurrences for // periodic sampling profiles. It can be the same as sample_type or it can be // different depending on the case, for example: // - sample_type=(cpu, milliseconds), period_type=(cpu, milliseconds), // period=10 signals that we sample the program every 10 milliseconds and // capture samples that each represent that sampling distance. // - sample_type=(off_cpu, nanoseconds), period_type=(context_switch, count), // period=1000 describes a profile where sampling is done every so often in // terms of context switches, but the recorded metric is the time spent by // the thread off CPU. // - sample_type=(inuse_space, bytes), period_type=(allocated_bytes, bytes), // period=262144 might represent a heap profile where the recorded sample // metric is the size of the live heap while the periodic sampling is done // using the number of cumulatively allocated bytes. ValueType period_type = 5; // The distance between sampled occurrences for periodic sampling profiles. // The value is of the period_type type and unit. int64 period = 6; // A globally unique identifier for a profile. The ID is a 16-byte array. An ID with // all zeroes is considered invalid. It MAY be used for deduplication and signal // correlation purposes. It is acceptable to treat two profiles with different values // in this field as not equal, even if they represented the same object at an earlier // time. // This field is optional; an ID may be assigned to an ID-less profile in a later step. bytes profile_id = 7; // The number of attributes that were discarded. Attributes // can be discarded because their keys are too long or because there are too many // attributes. If this value is 0, then no attributes were dropped. uint32 dropped_attributes_count = 8; // The original payload format. See also original_payload. It MUST be set // together with original_payload or both left unset [optional]. // // The allowed values for the format string are defined by the OpenTelemetry // specification. Some examples are "jfr", "pprof", "linux_perf". // // The original_payload MAY be used when converting from a source format (e.g. JFR) // that carries information which cannot be losslessly represented in the // Profiles format. Including the original data allows receivers to store or // reexport the data without loss. Because the original payload can be large, // its inclusion is optional. string original_payload_format = 9; // The original payload bytes. See also original_payload_format. It MUST be set // together with original_payload_format or both left unset [optional]. bytes original_payload = 10; // References to attributes in attribute_table. [optional] repeated int32 attribute_indices = 11; } // A pointer from a profile Sample to a trace Span. // Connects a profile sample to a trace span, identified by unique trace and span IDs. // // Status: [Alpha] message Link { // A unique identifier of the trace that this linked span is part of. The ID is a // 16-byte array. bytes trace_id = 1; // A unique identifier for the linked span. The ID is an 8-byte array. bytes span_id = 2; } // ValueType describes the type and units of a value. // // Status: [Alpha] message ValueType { // Index into ProfilesDictionary.string_table. int32 type_strindex = 1; // Index into ProfilesDictionary.string_table. int32 unit_strindex = 2; } // Each Sample records values encountered in some program context. The program // context is typically a stack trace, perhaps augmented with auxiliary // information like the thread-id, some indicator of a higher level request // being handled etc. // // A Sample MUST have have at least one entry in values or timestamps_unix_nano. // If both fields are populated, they MUST contain the same number of elements, // and the elements at the same index MUST refer to the same event. // // For the purposes of efficiently representing aggregated data observations, a Sample is regarded // as having a shared identity and an associated collection of per-observation data points. // A Sample's identity (i.e. primary key) is the tuple of {stack_index, set_of(attribute_indices), link_index}. // Samples having the same identity SHOULD be combined by appending timestamps and values to the data arrays. // // Examples of different ways ('shapes') of representing a sample with the total value of 10: // // Timestamps only (consumers must assume the value is 1 for each timestamp): // values: [] // timestamps_unix_nano: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] // // Single aggregated value without timestamps (one element representing the total): // values: [10] // timestamps_unix_nano: [] // // Per-timestamp value (each point in time records a specific value): // values: [2, 2, 3, 3] // timestamps_unix_nano: [1, 2, 3, 4] // // All Samples for a Profile SHOULD have the same shape, i.e. all data observation series should consistently // adopt the same data recording style. // // Status: [Alpha] message Sample { // Reference to stack in ProfilesDictionary.stack_table. int32 stack_index = 1; // References to attributes in ProfilesDictionary.attribute_table. [optional] repeated int32 attribute_indices = 2; // Reference to link in ProfilesDictionary.link_table. [optional] // 0 means no link exists. int32 link_index = 3; // The following fields may contain per-observation data and do not form part of the Sample's identity. // Measured values. The type and unit of each value is defined by Profile.sample_type. repeated int64 values = 4; // Timestamps (UTC) as nanoseconds since the UNIX epoch. The timestamps SHOULD fall within the // [Profile.time_unix_nano, Profile.time_unix_nano + Profile.duration_nano) interval. repeated fixed64 timestamps_unix_nano = 5; } // Describes the mapping of a binary in memory, including its address range, // file offset, and metadata like build ID // // Status: [Alpha] message Mapping { // Address at which the binary (or DLL) is loaded into memory. uint64 memory_start = 1; // The limit of the address range occupied by this mapping. uint64 memory_limit = 2; // Offset in the binary that corresponds to the first mapped address. uint64 file_offset = 3; // The object this entry is loaded from. This can be a filename on // disk for the main binary and shared libraries, or a virtual // abstraction like "[vdso]". int32 filename_strindex = 4; // Index into ProfilesDictionary.string_table. // References to attributes in ProfilesDictionary.attribute_table. [optional] repeated int32 attribute_indices = 5; } // A Stack represents a stack trace as a list of locations (leaf first). // For example, the stack trace resulting from the call stack // main -> foo -> bar would be encoded into the location_indices list // [2, 1, 0] which references the locations in location_table as: // [Location{"main"}, Location{"foo"}, Location{"bar"}]. // // Status: [Alpha] message Stack { // References to locations in ProfilesDictionary.location_table. // The first location is the leaf frame. repeated int32 location_indices = 1; } // Contains function and line table debug information for a single frame. // // Status: [Alpha] message Location { // Reference to mapping in ProfilesDictionary.mapping_table. // 0 means unknown or not applicable. int32 mapping_index = 1; // The instruction address for this location, if available. It // SHOULD be within [Mapping.memory_start, Mapping.memory_limit] // for the corresponding mapping. A non-leaf address may be in the // middle of a call instruction. It is up to display tools to find // the beginning of the instruction if necessary. uint64 address = 2; // Multiple lines indicate this location has inlined functions, // where the last entry represents the caller into which the // preceding entries were inlined. // // E.g., if memcpy() is inlined into printf: // lines[0].function_name == "memcpy" // lines[1].function_name == "printf" repeated Line lines = 3; // References to attributes in ProfilesDictionary.attribute_table. [optional] repeated int32 attribute_indices = 4; } // Details a specific line in a source code, linked to a function. // // Status: [Alpha] message Line { // Reference to function in ProfilesDictionary.function_table. int32 function_index = 1; // Line number in source code. 1-based, 0 means unset. int64 line = 2; // Column number in source code. 1-based, 0 means unset. int64 column = 3; } // Describes a function, including its human-readable name, system name, // source file, and starting line number in the source. At least one of // {name_strindex, system_name_strindex, filename_strindex} MUST be present. // // Status: [Alpha] message Function { // The function name. Empty string if not available. int32 name_strindex = 1; // Function name, as identified by the system. For instance, // it can be a C++ mangled name. Empty string if not available. int32 system_name_strindex = 2; // Source file containing the function. Empty string if not available. int32 filename_strindex = 3; // Line number in source file. 1-based, 0 means unset. int64 start_line = 4; } // A custom 'dictionary native' style of encoding attributes which is more convenient // for profiles than opentelemetry.proto.common.v1.KeyValue // Specifically, uses the ProfilesDictionary.string_table for keys // and allows optional unit information. // // Status: [Alpha] message KeyValueAndUnit { // The index into the string table for the attribute's key. int32 key_strindex = 1; // The value of the attribute. opentelemetry.proto.common.v1.AnyValue value = 2; // The index into the string table for the attribute's unit. // zero indicates implicit (by semconv) or non-defined unit. // If present, the unit string SHOULD be in UCUM format. int32 unit_strindex = 3; } open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/resource/000077500000000000000000000000001522767421700267035ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/resource/v1/000077500000000000000000000000001522767421700272315ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/resource/v1/resource.proto000066400000000000000000000032641522767421700321520ustar00rootroot00000000000000// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.resource.v1; import "opentelemetry/proto/common/v1/common.proto"; option csharp_namespace = "OpenTelemetry.Proto.Resource.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.resource.v1"; option java_outer_classname = "ResourceProto"; option go_package = "go.opentelemetry.io/proto/otlp/resource/v1"; // Resource information. message Resource { // Set of attributes that describe the resource. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 1; // The number of dropped attributes. If the value is 0, then // no attributes were dropped. uint32 dropped_attributes_count = 2; // Set of entities that participate in this Resource. // // Note: keys in the references MUST exist in attributes of this message. // // Status: [Development] repeated opentelemetry.proto.common.v1.EntityRef entity_refs = 3; } open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/trace/000077500000000000000000000000001522767421700261525ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/trace/v1/000077500000000000000000000000001522767421700265005ustar00rootroot00000000000000open-telemetry-opentelemetry-proto-790608c/opentelemetry/proto/trace/v1/trace.proto000066400000000000000000000366661522767421700307040ustar00rootroot00000000000000// Copyright 2019, OpenTelemetry Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. syntax = "proto3"; package opentelemetry.proto.trace.v1; import "opentelemetry/proto/common/v1/common.proto"; import "opentelemetry/proto/resource/v1/resource.proto"; option csharp_namespace = "OpenTelemetry.Proto.Trace.V1"; option java_multiple_files = true; option java_package = "io.opentelemetry.proto.trace.v1"; option java_outer_classname = "TraceProto"; option go_package = "go.opentelemetry.io/proto/otlp/trace/v1"; // TracesData represents the traces data that can be stored in a persistent storage, // OR can be embedded by other protocols that transfer OTLP traces data but do // not implement the OTLP protocol. // // The main difference between this message and collector protocol is that // in this message there will not be any "control" or "metadata" specific to // OTLP protocol. // // When new fields are added into this message, the OTLP request MUST be updated // as well. message TracesData { // An array of ResourceSpans. // For data coming from a single resource this array will typically contain // one element. Intermediary nodes that receive data from multiple origins // typically batch the data before forwarding further and in that case this // array will contain multiple elements. repeated ResourceSpans resource_spans = 1; } // A collection of ScopeSpans from a Resource. message ResourceSpans { reserved 1000; // The resource for the spans in this message. // If this field is not set then no resource info is known. opentelemetry.proto.resource.v1.Resource resource = 1; // A list of ScopeSpans that originate from a resource. repeated ScopeSpans scope_spans = 2; // The Schema URL, if known. This is the identifier of the Schema that the resource data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "resource" field. It does not apply // to the data in the "scope_spans" field which have their own schema_url field. string schema_url = 3; } // A collection of Spans produced by an InstrumentationScope. message ScopeSpans { // The instrumentation scope information for the spans in this message. // Semantically when InstrumentationScope isn't set, it is equivalent with // an empty instrumentation scope name (unknown). opentelemetry.proto.common.v1.InstrumentationScope scope = 1; // A list of Spans that originate from an instrumentation scope. repeated Span spans = 2; // The Schema URL, if known. This is the identifier of the Schema that the span data // is recorded in. Notably, the last part of the URL path is the version number of the // schema: http[s]://server[:port]/path/. To learn more about Schema URL see // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url // This schema_url applies to the data in the "scope" field and all spans and span // events in the "spans" field. string schema_url = 3; } // A Span represents a single operation performed by a single component of the system. // // The next available field id is 17. message Span { // A unique identifier for a trace. All spans from the same trace share // the same `trace_id`. The ID is a 16-byte array. An ID with all zeroes OR // of length other than 16 bytes is considered invalid (empty string in OTLP/JSON // is zero-length and thus is also invalid). // // This field is required. bytes trace_id = 1; // A unique identifier for a span within a trace, assigned when the span // is created. The ID is an 8-byte array. An ID with all zeroes OR of length // other than 8 bytes is considered invalid (empty string in OTLP/JSON // is zero-length and thus is also invalid). // // This field is required. bytes span_id = 2; // trace_state conveys information about request position in multiple distributed tracing graphs. // It is a trace_state in w3c-trace-context format: https://www.w3.org/TR/trace-context/#tracestate-header // See also https://github.com/w3c/distributed-tracing for more details about this field. string trace_state = 3; // The `span_id` of this span's parent span. If this is a root span, then this // field must be empty. The ID is an 8-byte array. bytes parent_span_id = 4; // Flags, a bit field. // // Bits 0-7 (8 least significant bits) are the trace flags as defined in W3C Trace // Context specification. To read the 8-bit W3C trace flag, use // `flags & SPAN_FLAGS_TRACE_FLAGS_MASK`. // // See https://www.w3.org/TR/trace-context-2/#trace-flags for the flag definitions. // // Bits 8 and 9 represent the 3 states of whether a span's parent // is remote. The states are (unknown, is not remote, is remote). // To read whether the value is known, use `(flags & SPAN_FLAGS_CONTEXT_HAS_IS_REMOTE_MASK) != 0`. // To read whether the span is remote, use `(flags & SPAN_FLAGS_CONTEXT_IS_REMOTE_MASK) != 0`. // // When creating span messages, if the message is logically forwarded from another source // with an equivalent flags fields (i.e., usually another OTLP span message), the field SHOULD // be copied as-is. If creating from a source that does not have an equivalent flags field // (such as a runtime representation of an OpenTelemetry span), the high 22 bits MUST // be set to zero. // Readers MUST NOT assume that bits 10-31 (22 most significant bits) will be zero. // // [Optional]. fixed32 flags = 16; // A description of the span's operation. // // For example, the name can be a qualified method name or a file name // and a line number where the operation is called. A best practice is to use // the same display name at the same call point in an application. // This makes it easier to correlate spans in different traces. // // This field is semantically required to be set to non-empty string. // Empty value is equivalent to an unknown span name. // // This field is required. string name = 5; // SpanKind is the type of span. Can be used to specify additional relationships between spans // in addition to a parent/child relationship. enum SpanKind { // Unspecified. Do NOT use as default. // Implementations MAY assume SpanKind to be INTERNAL when receiving UNSPECIFIED. SPAN_KIND_UNSPECIFIED = 0; // Indicates that the span represents an internal operation within an application, // as opposed to an operation happening at the boundaries. Default value. SPAN_KIND_INTERNAL = 1; // Indicates that the span covers server-side handling of an RPC or other // remote network request. SPAN_KIND_SERVER = 2; // Indicates that the span describes a request to some remote service. SPAN_KIND_CLIENT = 3; // Indicates that the span describes a producer sending a message to a broker. // Unlike CLIENT and SERVER, there is often no direct critical path latency relationship // between producer and consumer spans. A PRODUCER span ends when the message was accepted // by the broker while the logical processing of the message might span a much longer time. SPAN_KIND_PRODUCER = 4; // Indicates that the span describes consumer receiving a message from a broker. // Like the PRODUCER kind, there is often no direct critical path latency relationship // between producer and consumer spans. SPAN_KIND_CONSUMER = 5; } // Distinguishes between spans generated in a particular context. For example, // two spans with the same name may be distinguished using `CLIENT` (caller) // and `SERVER` (callee) to identify queueing latency associated with the span. SpanKind kind = 6; // The start time of the span. On the client side, this is the time // kept by the local machine where the span execution starts. On the server side, this // is the time when the server's application handler starts running. // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. // // This field is semantically required and it is expected that end_time >= start_time. fixed64 start_time_unix_nano = 7; // The end time of the span. On the client side, this is the time // kept by the local machine where the span execution ends. On the server side, this // is the time when the server application handler stops running. // Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. // // This field is semantically required and it is expected that end_time >= start_time. fixed64 end_time_unix_nano = 8; // A collection of key/value pairs. Note, global attributes // like server name can be set using the resource API. Examples of attributes: // // "/http/user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" // "/http/server_latency": 300 // "example.com/myattribute": true // "example.com/score": 10.239 // // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 9; // The number of attributes that were discarded. Attributes // can be discarded because their keys are too long or because there are too many // attributes. If this value is 0, then no attributes were dropped. uint32 dropped_attributes_count = 10; // Event is a time-stamped annotation of the span, consisting of user-supplied // text description and key-value pairs. message Event { // The time the event occurred. fixed64 time_unix_nano = 1; // The name of the event. // This field is semantically required to be set to non-empty string. string name = 2; // A collection of attribute key/value pairs on the event. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 3; // The number of dropped attributes. If the value is 0, // then no attributes were dropped. uint32 dropped_attributes_count = 4; } // A collection of Event items. repeated Event events = 11; // The number of dropped events. If the value is 0, then no // events were dropped. uint32 dropped_events_count = 12; // A pointer from the current span to another span in the same trace or in a // different trace. For example, this can be used in batching operations, // where a single batch handler processes multiple requests from different // traces or when the handler receives a request from a different project. message Link { // A unique identifier of a trace that this linked span is part of. The ID is a // 16-byte array. bytes trace_id = 1; // A unique identifier for the linked span. The ID is an 8-byte array. bytes span_id = 2; // The trace_state associated with the link. string trace_state = 3; // A collection of attribute key/value pairs on the link. // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). // The behavior of software that receives duplicated keys can be unpredictable. repeated opentelemetry.proto.common.v1.KeyValue attributes = 4; // The number of dropped attributes. If the value is 0, // then no attributes were dropped. uint32 dropped_attributes_count = 5; // Flags, a bit field. // // Bits 0-7 (8 least significant bits) are the trace flags as defined in W3C Trace // Context specification. To read the 8-bit W3C trace flag, use // `flags & SPAN_FLAGS_TRACE_FLAGS_MASK`. // // See https://www.w3.org/TR/trace-context-2/#trace-flags for the flag definitions. // // Bits 8 and 9 represent the 3 states of whether the link is remote. // The states are (unknown, is not remote, is remote). // To read whether the value is known, use `(flags & SPAN_FLAGS_CONTEXT_HAS_IS_REMOTE_MASK) != 0`. // To read whether the link is remote, use `(flags & SPAN_FLAGS_CONTEXT_IS_REMOTE_MASK) != 0`. // // Readers MUST NOT assume that bits 10-31 (22 most significant bits) will be zero. // When creating new spans, bits 10-31 (most-significant 22-bits) MUST be zero. // // [Optional]. fixed32 flags = 6; } // A collection of Links, which are references from this span to a span // in the same or different trace. repeated Link links = 13; // The number of dropped links after the maximum size was // enforced. If this value is 0, then no links were dropped. uint32 dropped_links_count = 14; // An optional final status for this span. Semantically when Status isn't set, it means // span's status code is unset, i.e. assume STATUS_CODE_UNSET (code = 0). Status status = 15; } // The Status type defines a logical error model that is suitable for different // programming environments, including REST APIs and RPC APIs. message Status { reserved 1; // A developer-facing human readable error message. string message = 2; // For the semantics of status codes see // https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status enum StatusCode { // The default status. STATUS_CODE_UNSET = 0; // The Span has been validated by an Application developer or Operator to // have completed successfully. STATUS_CODE_OK = 1; // The Span contains an error. STATUS_CODE_ERROR = 2; }; // The status code. StatusCode code = 3; } // SpanFlags represents constants used to interpret the // Span.flags field, which is protobuf 'fixed32' type and is to // be used as bit-fields. Each non-zero value defined in this enum is // a bit-mask. To extract the bit-field, for example, use an // expression like: // // (span.flags & SPAN_FLAGS_TRACE_FLAGS_MASK) // // See https://www.w3.org/TR/trace-context-2/#trace-flags for the flag definitions. // // Note that Span flags were introduced in version 1.1 of the // OpenTelemetry protocol. Older Span producers do not set this // field, consequently consumers should not rely on the absence of a // particular flag bit to indicate the presence of a particular feature. enum SpanFlags { // The zero value for the enum. Should not be used for comparisons. // Instead use bitwise "and" with the appropriate mask as shown above. SPAN_FLAGS_DO_NOT_USE = 0; // Bits 0-7 are used for trace flags. SPAN_FLAGS_TRACE_FLAGS_MASK = 0x000000FF; // Bits 8 and 9 are used to indicate that the parent span or link span is remote. // Bit 8 (`HAS_IS_REMOTE`) indicates whether the value is known. // Bit 9 (`IS_REMOTE`) indicates whether the span or link is remote. SPAN_FLAGS_CONTEXT_HAS_IS_REMOTE_MASK = 0x00000100; SPAN_FLAGS_CONTEXT_IS_REMOTE_MASK = 0x00000200; // Bits 10-31 are reserved for future use. }