feat(exporter-collector): implement concurrencyLimit option #1708
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dobesv
requested review from
dyladan,
legendecas,
markwolff,
mayurkale22,
mwear,
naseemkullah,
obecny,
OlivierAlbertini and
vmarchaud
as code owners
Codecov Report
@@ Coverage Diff @@
## master #1708 +/- ##
=======================================
Coverage 91.91% 91.92%
=======================================
Files 167 167
Lines 5567 5573 +6
Branches 1183 1186 +3
=======================================
+ Hits 5117 5123 +6
Misses 450 450
|
dobesv
force-pushed
the
concurrent-export-limit
branch
from
b8a1e08 to
04b05b0
Compare
|
Note: I considered setting some non-infinite default value for concurrentLimit but left it as it is now to avoid changing the behavior of the library. |
|
I don't know why it thinks the changes are not covered by the unit tests, they seem to be covered to my eye. |
obecny
reviewed
Dec 3, 2020
packages/opentelemetry-exporter-collector/src/CollectorExporterBase.ts
Outdated
Show resolved
Hide resolved
packages/opentelemetry-exporter-collector/test/node/CollectorTraceExporter.test.ts
Outdated
Show resolved
Hide resolved
dobesv
force-pushed
the
concurrent-export-limit
branch
3 times, most recently
from
5c8719f to
742a228
Compare
This adds an option to the collector exporters `concurrencyLimit`. If this is set and the number of export operations is equal to the limit, additional export operations will fail immediately. This should be set in combination with the batch span processor be set such that the concurrency limit would not be reached under "normal" circumstances - only if there is an issue would spans start to be dropped. This helps us cap the amount of memory & sockets used by the exporter if it is not able to keep up with the data it is being provided. This could happen if the local network (e.g. in a browser) or the remote collector are too slow to handle all the activity. If we do not have this cap, and the exporter cannot keep up, resources such as memory and network sockets can be consumed without limit, causing crashes and other undesirable outcomes far worse than losing some telemetry data. This also updates the examples to use `BatchSpanProcessor` as I couldn't really think of any reason why you would want to use SimpleSpanProcessor in combination with the collector exporter.
|
@dobesv pls do not force push after 1st review is done, it is impossible to see changes then |
dobesv
force-pushed
the
concurrent-export-limit
branch
from
742a228 to
279c2d9
Compare
|
@obecny Thanks for the review. I have pushed changes that I hope addressed your comments. Let me know if there's anything more I can do to help. |
|
@obecny Ah sorry about the force push, it's a habit from other places that want a single commit. |
|
We squash it when we merge anyways. No need to worry about it during the PR process. |
vmarchaud
approved these changes
Dec 5, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds an option to the collector exporters
concurrencyLimit. If this is set andthe number of export operations is equal to the limit, additional export operations
will fail immediately.
This should be set in combination with the batch span processor be set such that the
concurrency limit would not be reached under "normal" circumstances - only if there
is an issue would spans start to be dropped.
This helps us cap the amount of memory & sockets used by the exporter if it is not
able to keep up with the data it is being provided.
This could happen if the local network (e.g. in a browser) or the remote collector
are too slow to handle all the activity.
If we do not have this cap, and the exporter cannot keep up, resources such as
memory and network sockets can be consumed without limit, causing crashes and
other undesirable outcomes far worse than losing some telemetry data.
This also updates the examples to use
BatchSpanProcessoras I couldn't reallythink of any reason why you would want to use SimpleSpanProcessor in combination
with the collector exporter.
Fixes #1707