Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

export and shutdown timeouts for all OTLP exporters#3764

New issue

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

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

Already on GitHub?Sign in to your account

Conversation

@Arnatious
Copy link
Contributor

@ArnatiousArnatious commentedMar 7, 2024
edited
Loading

Description

This is a solution to several issues related to the current synchronous OTLP exporters.

Currently, OTLP exporters have a couple of pain points

This PR implements a new utility class,opentelemetry.exporter.otlp.proto.common.RetryingExporter, that fixes the above issues. It also significantly refactors the existing OTLP exporters to use this, and extracts retry related logic from their test suites.

Attempts were made to maintain the call signature of public APIs, though in several cases **kwargs were added to ensure future proofing, and positional arguments were renamed to create a consistent interface.

OTLP exporters will create a RetryingExporter, passing in a function performing a single export attempt as well as the OTLPExporter's timeout and export result type.

Example

fromopentelemetry.exporter.otlp.proto.commonimportRetryingExporter,RetryableExportErrorclassOTLPSpanExporter(SpanExporter):def__init__(self, ...):self._exporter=RetryingExporter(self._export,SpanExportResult,self._timeout)def_export(self,timeout_s:float,serialized_data:bytes)->SpanExportResult:result= ...ifis_retryable(result):raiseRetryableExportError(result.delay)returnresultdefexport(self,data,timeout_millis=10_000,**kwargs)->SpanExportResult:returnself._exporter.export_with_retry(timeout_millis*1e-3,data)defshutdown(self,timeout_millis=10_000,**kwargs):    ...self._exporter.shutdown(timeout_millis)self._shutdown=True

Fixes#3309

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Tests were added for the RetryableExporter inexporter/opentelemetry-exporter-otlp-proto-common/tests/test_retryable_exporter.py, as well as for the backoff generator inexporter/opentelemetry-exporter-otlp-proto-common/tests/test_backoff.py. Tests were updated throughout the http and grpc otlp exporters, and retry related logic was removed in all cases but for GRPC metrics, which can be split and therefore needed another layer of deadline checking.

Does This PR Require a Contrib Repo Change?

Answer the following question based on these examples of changes that would require a Contrib Repo Change:

  • The OTel specification has changed which prompted this PR to update the method interfaces ofopentelemetry-api/ oropentelemetry-sdk/

  • The method interfaces oftest/util have changed

  • Scripts inscripts/ that were copied over to the Contrib repo have changed

  • Configuration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in

    • pyproject.toml
    • isort.cfg
    • .flake8
  • When a new.github/CODEOWNER is added

  • Major changes to project information, such as in:

    • README.md
    • CONTRIBUTING.md
  • Yes. - Link to PR:

  • No.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added
  • Documentation has been updated

@ArnatiousArnatiousforce-pushed theexporter_timeouts_comp branch frombd19a3d to3cd93c9CompareMarch 7, 2024 23:46
@Arnatious
Copy link
ContributorAuthor

I based behavior decisions off the described behavior in#2663 (comment) - namely, the shortest timeout always wins.

Processor timeout logic is unaffected - if the processor has a shorter timeout or is tracking a deadline for a batch, it passes that toexport() and it is respected, if the timeout is longer, the exporter's timeout attribute (set at creation/from env variables) can be hit and cause the export to fail.

I chose to create a helper object rather than splice this into the inheritance hierarchy to avoid having a mixin with__init__, since the exporter needs to have an object-scoped event and lock, and the GRPC exporters already have several mixins with__init__ it'd have to play along with. A unified rewrite of the inheritence hierarchy shared between http and gprc exporters would probably be better.

@ArnatiousArnatiousforce-pushed theexporter_timeouts_comp branch froma28c110 toba50c4cCompareMarch 9, 2024 03:40
@ocelotlocelotl marked this pull request as ready for reviewMarch 14, 2024 16:42
@ocelotlocelotl requested a review froma teamMarch 14, 2024 16:42
@pmcollins
Copy link
Member

@Arnatious apologies for the delay and thanks for this PR -- improvements to the area you've addressed are super important.

However, perhaps this is too much of a good thing all at once. Do you have availability to break these changes down into smaller PRs? This would make things much easier on reviewers.

xrmx reacted with heart emoji

LarsMichelsen added a commit to LarsMichelsen/opentelemetry-python that referenced this pull requestAug 19, 2024
This is the first change in a chain of commits to rework the retrymechanic. It is based on the work ofopen-telemetry#3764 and basically trying to landthe changes proposed by this monolithic commit step by step.The plan is roughly to proceed in these steps:* Extract retry mechanic from GRPC exporters* Consolidate HTTP with GRPC exporter retry implementation* Pipe timeout through RetryingExporter* Make exporter lock protect the whole export instead of just a single iteration* Make timeout float instead of int* Add back-off with jitterIt's pretty likely that the plan will change along the way.
LarsMichelsen added a commit to LarsMichelsen/opentelemetry-python that referenced this pull requestAug 26, 2024
This is the first change in a chain of commits to rework the retrymechanic. It is based on the work ofopen-telemetry#3764 and basically trying to landthe changes proposed by this monolithic commit step by step.The plan is roughly to proceed in these steps:* Extract retry mechanic from GRPC exporters* Consolidate HTTP with GRPC exporter retry implementation* Pipe timeout through RetryingExporter* Make exporter lock protect the whole export instead of just a single iteration* Make timeout float instead of int* Add back-off with jitterIt's pretty likely that the plan will change along the way.
LarsMichelsen added a commit to LarsMichelsen/opentelemetry-python that referenced this pull requestAug 29, 2024
This is the first change in a chain of commits to rework the retrymechanic. It is based on the work ofopen-telemetry#3764 and basically trying to landthe changes proposed by this monolithic commit step by step.The plan is roughly to proceed in these steps:* Extract retry mechanic from GRPC exporters* Consolidate HTTP with GRPC exporter retry implementation* Pipe timeout through RetryingExporter* Make exporter lock protect the whole export instead of just a single iteration* Make timeout float instead of int* Add back-off with jitterIt's pretty likely that the plan will change along the way.
LarsMichelsen added a commit to LarsMichelsen/opentelemetry-python that referenced this pull requestSep 7, 2024
This is the first change in a chain of commits to rework the retrymechanic. It is based on the work ofopen-telemetry#3764 and basically trying to landthe changes proposed by this monolithic commit step by step.The plan is roughly to proceed in these steps:* Extract retry mechanic from GRPC exporters* Consolidate HTTP with GRPC exporter retry implementation* Pipe timeout through RetryingExporter* Make exporter lock protect the whole export instead of just a single iteration* Make timeout float instead of int* Add back-off with jitterIt's pretty likely that the plan will change along the way.
LarsMichelsen added a commit to LarsMichelsen/opentelemetry-python that referenced this pull requestSep 14, 2024
This is the first change in a chain of commits to rework the retrymechanic. It is based on the work ofopen-telemetry#3764 and basically trying to landthe changes proposed by this monolithic commit step by step.The plan is roughly to proceed in these steps:* Extract retry mechanic from GRPC exporters* Consolidate HTTP with GRPC exporter retry implementation* Pipe timeout through RetryingExporter* Make exporter lock protect the whole export instead of just a single iteration* Make timeout float instead of int* Add back-off with jitterIt's pretty likely that the plan will change along the way.
@Arnatious
Copy link
ContributorAuthor

Arnatious commentedNov 6, 2025
edited
Loading

Superceded by#4564 (thanks!)

@github-project-automationgithub-project-automationbot moved this fromReviewed PRs that need fixes toDone in@xrmx's Python PR digestNov 6, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

Status: Done

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Exporters shutdown takes longer then a minute when failing to send metrics/traces

2 participants

@Arnatious@pmcollins

[8]ページ先頭

©2009-2025 Movatter.jp