Propagate deadline through OTel-Arrow components #227
Comments
This was referenced Jun 20, 2024
Merged
jmacd
added a commit
that referenced
this issue
Jun 21, 2024
Same as open-telemetry/opentelemetry-collector-contrib#33688 but merging this code here will let me create and test a PR in that repository, whereas it will be messy to build off this work in the same repository. I expect this package to be deleted after open-telemetry/opentelemetry-collector-contrib#33688 and open-telemetry/opentelemetry-collector-contrib#33579 merged, as discussed in #225. Part of #227.
|
We are blocked on open-telemetry/opentelemetry-collector-contrib#33579 |
This was referenced Jul 16, 2024
codeboten
pushed a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this issue
Jul 22, 2024
…34175) **Description:** We have been using the OTel-Arrow components in production and begun to monitor the component's health using span data. There are spans coming from otelgrpc instrumentation and there are explicit spans in both components. This adds a new test that exercises multiple streams between the exporter and receiver components. At the end of the test, it checks for no span errors, with one exception discussed in open-telemetry/opentelemetry-go-contrib#2644. We will not modify the logic of these components to avoid stream cancelation, we will lobby for stream cancelation not to register as span errors. The receiver is modified to avoid setting Span errors for EOF and Cancelation following its existing logic for setting log severity for the same condition. As a result, the `otel_arrow_stream_inflight` span will not show errors for the final `Recv()` as a stream shuts down. **Link to tracking Issue:** Part of open-telemetry/otel-arrow#227. **Testing:** A new test is added.
evan-bradley
pushed a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this issue
Aug 6, 2024
…33688) **Description:** With utilities to encode and decode timeout in the syntax specified by gRPC. This will be used by the otelarrow components to encode and decode timeout values. In that sense, the new code could also be added into the pending internal/otelarrow package, see #33579 As this code is derived from gRPC-Go, some text is added in `NOTICE` according to the license. The code that this was derived from contained a TODO, which was largely addressed by eliminating very short timeouts from being encoded. This code will encode timeouts in milliseconds, seconds, hours, and days but it will not encode microsecond/nanosecond durations, these are rounded to `0m`. The decoder will handle all durations that gRPC specifies, so that this logic can change in the future. **Link to tracking Issue:** open-telemetry/otel-arrow#227 **Testing:** Adds basic tests.
This was referenced Aug 19, 2024
codeboten
pushed a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this issue
Sep 5, 2024
**Description:** Exporter side of open-telemetry/otel-arrow#227. The receiver side is #34742. **Link to tracking Issue:** open-telemetry/otel-arrow#227 **Testing:** Adds a test for the expected metadata propagation. **Documentation:** Since this is expected of gRPC receivers, no docs are changed.
f7o
pushed a commit
to f7o/opentelemetry-collector-contrib
that referenced
this issue
Sep 12, 2024
**Description:** Exporter side of open-telemetry/otel-arrow#227. The receiver side is open-telemetry#34742. **Link to tracking Issue:** open-telemetry/otel-arrow#227 **Testing:** Adds a test for the expected metadata propagation. **Documentation:** Since this is expected of gRPC receivers, no docs are changed.
codeboten
added a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this issue
Sep 23, 2024
**Description:** Receiver side of open-telemetry/otel-arrow#227. The exporter side is #34733. **Link to tracking Issue:** open-telemetry/otel-arrow#227 **Testing:** A new end-to-end integration test. ✅ **Documentation:** Since this is expected of gRPC receivers, no docs are changed. --------- Signed-off-by: Alex Boten <[email protected]> Co-authored-by: Bogdan Drutu <[email protected]> Co-authored-by: Alex Boten <[email protected]>
jriguera
pushed a commit
to springernature/opentelemetry-collector-contrib
that referenced
this issue
Oct 4, 2024
**Description:** Receiver side of open-telemetry/otel-arrow#227. The exporter side is open-telemetry#34733. **Link to tracking Issue:** open-telemetry/otel-arrow#227 **Testing:** A new end-to-end integration test. ✅ **Documentation:** Since this is expected of gRPC receivers, no docs are changed. --------- Signed-off-by: Alex Boten <[email protected]> Co-authored-by: Bogdan Drutu <[email protected]> Co-authored-by: Alex Boten <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The exporter should propagate the deadline of the caller into the received context. The receiver should optionally apply the callers context or possibly ignore it but set a preconfigured deadline for the consumer call. Otherwise, we are calling the OTel pipeline without any deadline, which is dangerous.
This can be done using the existing header propagation mechanism.
The text was updated successfully, but these errors were encountered: