Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add span_min_duration spec #314

Closed
wants to merge 6 commits into from

Conversation

felixbarny
Copy link
Member

@felixbarny felixbarny commented Aug 12, 2020

Discussion issue: #259

Agent Milestone Link to agent implementation issue
.NET
Go
Java 7.7 elastic/apm-agent-java#1150
Node.js
PHP
Python elastic/apm-agent-python#847
Ruby
RUM N/A

Note that the implementation of this spec also includes adding the option to Kibana.

Open questions:

  • Do we want/need all agents to implement that?
    • As this depends a lot on the effort it would take, a comment on the feasibility would be appreciated.
  • Priority/target release version

Copy link
Contributor

@beniwohli beniwohli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally 👍 , just a couple small questions

docs/agents/span-min-duration.md Outdated Show resolved Hide resolved
docs/agents/span-min-duration.md Outdated Show resolved Hide resolved
docs/agents/span-min-duration.md Outdated Show resolved Hide resolved
docs/agents/span-min-duration.md Outdated Show resolved Hide resolved
such as a manually created span or a SQL call,
the subtree can be discarded.

### Spans that lead up to async spans can't be discarded
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This limitation might make the proposal not very useful for Node.js or Go/goroutines.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See also @axw's comment from #259 (comment)

I don't have a specific idea of how it would work yet, I just know that detecting transfer of context between threads is not a viable approach in Go. This bit is pretty language specific I think. For Go I would probably make it so that spans are assumed to be synchronous by default, and callers of the API could explicitly mark them as async.

@felixbarny felixbarny requested a review from gregkalapos August 17, 2020 11:28
@apmmachine
Copy link

apmmachine commented Aug 19, 2020

💔 Build Failed

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: [Started by timer]

  • Start Time: 2020-11-16T05:49:00.730+0000

  • Duration: 3 min 37 sec

Steps errors 1

Expand to view the steps failures

Shell Script

  • Took 0 min 0 sec . View more details on here
  • Description: [2020-11-16T05:51:37.193Z] + git diff --name-only c16cd8a19dcf3087afd47792031f99265a231d76...d5091c7

Log output

Expand to view the last 100 lines of log output

[2020-11-16T05:51:01.374Z] Sleeping for 10 sec
[2020-11-16T05:51:13.654Z] using credential f6c7695a-671e-4f4f-a331-acdce44ff9ba
[2020-11-16T05:51:13.712Z] Wiping out workspace first.
[2020-11-16T05:51:13.733Z] Cloning the remote Git repository
[2020-11-16T05:51:13.733Z] Using shallow clone with depth 4
[2020-11-16T05:51:13.733Z] Avoid fetching tags
[2020-11-16T05:51:13.753Z] Cloning repository [email protected]:elastic/apm.git
[2020-11-16T05:51:13.795Z]  > git init /var/lib/jenkins/workspace/ared_apm-update-specs-mbp_PR-314 # timeout=10
[2020-11-16T05:51:14.702Z] Cleaning workspace
[2020-11-16T05:51:14.721Z] Using shallow fetch with depth 4
[2020-11-16T05:51:14.722Z] Pruning obsolete local branches
[2020-11-16T05:51:13.851Z] Fetching upstream changes from [email protected]:elastic/apm.git
[2020-11-16T05:51:13.852Z]  > git --version # timeout=10
[2020-11-16T05:51:13.866Z]  > git --version # 'git version 2.17.1'
[2020-11-16T05:51:13.867Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2020-11-16T05:51:13.898Z]  > git fetch --no-tags --progress -- [email protected]:elastic/apm.git +refs/heads/*:refs/remotes/origin/* # timeout=15
[2020-11-16T05:51:14.655Z]  > git config remote.origin.url [email protected]:elastic/apm.git # timeout=10
[2020-11-16T05:51:14.674Z]  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
[2020-11-16T05:51:14.687Z]  > git config remote.origin.url [email protected]:elastic/apm.git # timeout=10
[2020-11-16T05:51:14.705Z]  > git rev-parse --verify HEAD # timeout=10
[2020-11-16T05:51:14.711Z] No valid HEAD. Skipping the resetting
[2020-11-16T05:51:14.711Z]  > git clean -fdx # timeout=10
[2020-11-16T05:51:14.726Z] Fetching upstream changes from [email protected]:elastic/apm.git
[2020-11-16T05:51:14.727Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2020-11-16T05:51:14.740Z]  > git fetch --no-tags --progress --prune -- [email protected]:elastic/apm.git +refs/pull/314/head:refs/remotes/origin/PR-314 +refs/heads/master:refs/remotes/origin/master # timeout=15
[2020-11-16T05:51:15.357Z] Merging remotes/origin/master commit a9c76c2d14a5cf9bcfd6e7dacecf0c6be1b47021 into PR head commit d5091c7771887a23a8a1343aae72bfa84f017d77
[2020-11-16T05:51:15.475Z] Merge succeeded, producing 68f03cd44d351ac04fe425a1c35619ab38e02a96
[2020-11-16T05:51:15.475Z] Checking out Revision 68f03cd44d351ac04fe425a1c35619ab38e02a96 (PR-314)
[2020-11-16T05:51:15.365Z]  > git config core.sparsecheckout # timeout=10
[2020-11-16T05:51:15.370Z]  > git checkout -f d5091c7771887a23a8a1343aae72bfa84f017d77 # timeout=15
[2020-11-16T05:51:15.400Z]  > git remote # timeout=10
[2020-11-16T05:51:15.417Z]  > git config --get remote.origin.url # timeout=10
[2020-11-16T05:51:15.429Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2020-11-16T05:51:15.433Z]  > git merge a9c76c2d14a5cf9bcfd6e7dacecf0c6be1b47021 # timeout=10
[2020-11-16T05:51:15.462Z]  > git rev-parse HEAD^{commit} # timeout=10
[2020-11-16T05:51:15.478Z]  > git config core.sparsecheckout # timeout=10
[2020-11-16T05:51:15.483Z]  > git checkout -f 68f03cd44d351ac04fe425a1c35619ab38e02a96 # timeout=15
[2020-11-16T05:51:18.961Z] Commit message: "Merge commit 'a9c76c2d14a5cf9bcfd6e7dacecf0c6be1b47021' into HEAD"
[2020-11-16T05:51:18.978Z] First time build. Skipping changelog.
[2020-11-16T05:51:18.978Z] Cleaning workspace
[2020-11-16T05:51:19.635Z] Masking supported pattern matches of $JOB_GCS_BUCKET or $NOTIFY_TO
[2020-11-16T05:51:19.660Z] Timeout set to expire in 3 hr 0 min
[2020-11-16T05:51:19.666Z] The timestamps step is unnecessary when timestamps are enabled for all Pipeline builds.
[2020-11-16T05:51:19.816Z] [INFO] 'shallow' is forced to be disabled when running on PullRequests
[2020-11-16T05:51:19.823Z] Running in /var/lib/jenkins/workspace/ared_apm-update-specs-mbp_PR-314/src/github.com/elastic/apm
[2020-11-16T05:51:19.832Z] [INFO] gitCheckout: Checkout master from [email protected]:elastic/apm.git with credentials f6c7695a-671e-4f4f-a331-acdce44ff9ba
[2020-11-16T05:51:19.842Z] [INFO] Override default checkout
[2020-11-16T05:51:19.858Z] Sleeping for 10 sec
[2020-11-16T05:51:18.965Z]  > git rev-list --no-walk 1ebdf61b2c951da407bb3beb353b99bf71960259 # timeout=10
[2020-11-16T05:51:18.980Z]  > git rev-parse --verify HEAD # timeout=10
[2020-11-16T05:51:18.990Z] Resetting working tree
[2020-11-16T05:51:18.990Z]  > git reset --hard # timeout=10
[2020-11-16T05:51:19.003Z]  > git clean -fdx # timeout=10
[2020-11-16T05:51:29.971Z] using credential f6c7695a-671e-4f4f-a331-acdce44ff9ba
[2020-11-16T05:51:30.030Z] Cloning the remote Git repository
[2020-11-16T05:51:30.043Z] Cloning repository [email protected]:elastic/apm.git
[2020-11-16T05:51:30.064Z]  > git init /var/lib/jenkins/workspace/ared_apm-update-specs-mbp_PR-314/src/github.com/elastic/apm # timeout=10
[2020-11-16T05:51:30.075Z] Fetching upstream changes from [email protected]:elastic/apm.git
[2020-11-16T05:51:30.075Z]  > git --version # timeout=10
[2020-11-16T05:51:30.088Z]  > git --version # 'git version 2.17.1'
[2020-11-16T05:51:30.089Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2020-11-16T05:51:30.093Z]  > git fetch --tags --progress -- [email protected]:elastic/apm.git +refs/heads/*:refs/remotes/origin/* # timeout=10
[2020-11-16T05:51:30.762Z]  > git config remote.origin.url [email protected]:elastic/apm.git # timeout=10
[2020-11-16T05:51:30.769Z]  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
[2020-11-16T05:51:30.776Z]  > git config remote.origin.url [email protected]:elastic/apm.git # timeout=10
[2020-11-16T05:51:30.782Z] Fetching upstream changes from [email protected]:elastic/apm.git
[2020-11-16T05:51:30.782Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2020-11-16T05:51:30.785Z]  > git fetch --tags --progress -- [email protected]:elastic/apm.git +refs/heads/*:refs/remotes/origin/* +refs/pull/*/head:refs/remotes/origin/PR/* # timeout=10
[2020-11-16T05:51:31.618Z] Checking out Revision a9c76c2d14a5cf9bcfd6e7dacecf0c6be1b47021 (origin/master)
[2020-11-16T05:51:31.649Z] Commit message: "ci: add JSON_SPECS_PATH paths for nodejs to .ci/.jenkins-agents.yml (#366)"
[2020-11-16T05:51:31.649Z] First time build. Skipping changelog.
[2020-11-16T05:51:31.613Z]  > git rev-parse origin/master^{commit} # timeout=10
[2020-11-16T05:51:31.620Z]  > git config core.sparsecheckout # timeout=10
[2020-11-16T05:51:31.630Z]  > git checkout -f a9c76c2d14a5cf9bcfd6e7dacecf0c6be1b47021 # timeout=10
[2020-11-16T05:51:32.365Z] Masking supported pattern matches of $GIT_USERNAME or $GIT_PASSWORD
[2020-11-16T05:51:32.925Z] + git fetch https://****:****@github.com/elastic/apm.git +refs/pull/*/head:refs/remotes/origin/pr/*
[2020-11-16T05:51:33.220Z] Archiving artifacts
[2020-11-16T05:51:33.746Z] + git rev-parse HEAD
[2020-11-16T05:51:34.074Z] + git rev-parse HEAD
[2020-11-16T05:51:34.365Z] + git rev-parse origin/pr/314
[2020-11-16T05:51:34.390Z] [INFO] githubEnv: Found Git Build Cause: pr
[2020-11-16T05:51:34.648Z] Masking supported pattern matches of $GITHUB_TOKEN
[2020-11-16T05:51:35.865Z] [INFO] githubPrCheckApproved: Title: Add span_min_duration spec - User: felixbarny - Author Association: MEMBER
[2020-11-16T05:51:36.487Z] Stashed 429 file(s)
[2020-11-16T05:51:36.844Z] Running in /var/lib/jenkins/workspace/ared_apm-update-specs-mbp_PR-314/src/github.com/elastic/apm
[2020-11-16T05:51:37.193Z] + git diff --name-only c16cd8a19dcf3087afd47792031f99265a231d76...d5091c7771887a23a8a1343aae72bfa84f017d77
[2020-11-16T05:51:37.193Z] fatal: Invalid symmetric difference expression c16cd8a19dcf3087afd47792031f99265a231d76...d5091c7771887a23a8a1343aae72bfa84f017d77
[2020-11-16T05:51:37.241Z] Stage "Send Pull Request for BDD specs" skipped due to earlier failure(s)
[2020-11-16T05:51:37.259Z] Stage "Send Pull Request for JSON specs" skipped due to earlier failure(s)
[2020-11-16T05:51:37.439Z] Running on worker-854309 in /var/lib/jenkins/workspace/ared_apm-update-specs-mbp_PR-314
[2020-11-16T05:51:37.507Z] [INFO] getVaultSecret: Getting secrets
[2020-11-16T05:51:37.633Z] Masking supported pattern matches of $VAULT_ADDR or $VAULT_ROLE_ID or $VAULT_SECRET_ID
[2020-11-16T05:51:39.519Z] + chmod 755 generate-build-data.sh
[2020-11-16T05:51:39.519Z] + ./generate-build-data.sh https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-shared/apm-update-specs-mbp/PR-314/ https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-shared/apm-update-specs-mbp/PR-314/runs/29 FAILURE 157408
[2020-11-16T05:51:39.519Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-shared/apm-update-specs-mbp/PR-314/runs/29/steps/?limit=10000 -o steps-info.json
[2020-11-16T05:51:40.963Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-shared/apm-update-specs-mbp/PR-314/runs/29/tests/?status=FAILED -o tests-errors.json
[2020-11-16T05:51:41.660Z] Retry 1/3 exited 22, retrying in 1 seconds...
[2020-11-16T05:51:43.908Z] Retry 2/3 exited 22, retrying in 2 seconds...
[2020-11-16T05:51:46.160Z] Retry 3/3 exited 22, no more retries left.
[2020-11-16T05:51:46.160Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-shared/apm-update-specs-mbp/PR-314/runs/29/log/ -o pipeline-log.txt

@felixbarny
Copy link
Member Author

@beniwohli no rush but could you either resolve the conversations or let me know if anything is still missing?

@felixbarny felixbarny marked this pull request as ready for review September 2, 2020 10:28
@felixbarny felixbarny requested review from a team as code owners September 2, 2020 10:28
Copy link
Contributor

@hmdhk hmdhk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the discussion issue the RUM agent handles the original problem (handling many small spans) in a different way that results in merging small spans into one and show the count. I don't think it's necessary to introduce this behavior in the RUM agent.

Copy link
Contributor

@mikker mikker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

specs/agents/tracing-spans-discarding.md Outdated Show resolved Hide resolved
### Determining whether to report a span

If the span is requested to be discarded and discardable,
the `span_count.dropped` count is incremeted and the span will not be reported.
Copy link
Contributor

@SergeyKleyman SergeyKleyman Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that spans that are eventually dropped because of span_min_duration should not be counted in span_count.started. What implementation approach do you suggest?

  1. Increment span_count.started at the start of each span and then decrement it for the spans that are dropped because of span_min_duration
  2. Increment span_count.started at the end of each span when it's already known if the span is going to be dropped.

It seems that approach (1) has a disadvantage of potentially under-utilizing transaction_max_spans quota.
But approach (2) is somewhat counteractive and can also lead to over-utilizing transaction_max_spans quota.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All started spans count into that, no matter whether they are discarded.
We don’t have to decrement when discarding as we also count discarded spans in another variable. See the section „ Impact on transaction_max_spans“ for more details.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIR spans dropped because of transaction_max_spans are not counted in span_count.started. Only spans actually sent to APM Server are counted in span_count.started. So there is no overlap between span_count.started and span_count.dropped.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only spans actually sent to APM Server are counted in span_count.started.

That's news to me. Do you have any sources for that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was a bit confused it seems. You're right, the started count does not include dropped spans. The invariant total = started + dropped should always hold true.

IMHO, started is a bit of a misnomer. Internally in the Java agent, the variable is named reported. It is incremented on span end if and only if the span is not discarded.
So it's the approach (2).
Note that the started count has no influence on transaction_max_spans. Only total and dropped is considered.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean by

Note that the started count has no influence on transaction_max_spans. Only total and dropped is considered.

Isn't it the case that started should not be larger than transaction_max_spans?
If you increment started at the end of the span, you can get into situation where started is already equal to transaction_max_spans by the time the span ends so if you have to report the span (for example because its ID is referenced by an event that is already reported) you will have to increment started beyond transaction_max_spans - this is what I meant by

over-utilizing transaction_max_spans quota

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the limit is reached if this condition is true:

span_count.total - span_count.dropped >= transaction_max_spans

The total count is incremented for every span, even for those that are dropped (due to transaction_max_spans or span_min_duration).

This condition does not use the started count, hence it has no (direct) influence on transaction_max_spans.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If

The invariant total = started + dropped should always hold true.

and

the limit is reached if this condition is true:

span_count.total - span_count.dropped >= transaction_max_spans

doesn't it follow that the limit is reached if this condition is true?

span_count.started >= transaction_max_spans

Copy link
Member

@axw axw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but we probably won't be able to implement this in the Go agent without breaking changes - so likely not for a while.

@felixbarny
Copy link
Member Author

@axw which part would require a breaking change in the Go agent? Is it even feasible to Go do fulfill the Spans that lead up to async spans can't be discarded requirement?

@axw
Copy link
Member

axw commented Sep 4, 2020

which part would require a breaking change in the Go agent? Is it even feasible to Go do fulfill the Spans that lead up to async spans can't be discarded requirement?

Not automatically AFAICS. We would need to encode that into the API. You would need to explicitly mark the span as asynchronous (or synchronous), making them non-discardable. This is the bit that makes it a breaking change, as otherwise we potentially start discarding things that shouldn't be.

The other option is we assume all spans are non-discardable by default, and one always has to mark spans as discardable explicitly; we would then implement this for select auto-instrumented spans like database queries. Not ideal, but better than nothing. We could do this sooner rather than later.

@nehaduggal
Copy link

I'd like to suggest an edit to maintain all SQL and external spans in addition to context propagating spans no matter how quick those are. They are use in determining the connectivity/dependencies of a service and taking them away will lead to partial information(would service maps even show there was an external/db call if we drop the span?). The only spans that we should filter out are spans that represent some internal processing and are below a certain threshold.

Additionally, spans that lead to an error or that may be a parent of an async operation can't be discarded.

However, external calls that don't propagate context,
such as calls to a database, can be discarded using this threshold.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion we should keep database calls even if they are below the threshold for the fast spans.

Copy link
Contributor

@gregkalapos gregkalapos Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I heard some feedback from users where they wanted a similar feature and in those cases it was all database spans. ORM frameworks sometimes create multiple db calls and in general I had the impression that db will be the one causing "span explosion" a lot. I feel not including db spans here would limit the usefulness of this config.

But good point about the service map - is it unacceptable to just say that this influences servicemap?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was an explicit design goal and a request from you know who to reduce the vast amount of short DB calls from the waterfall.

I see that this can be problematic when trying to determine metrics for the service map. But then we might have to tackle the issue in a completely different way.
For example similar to how the RUM agent does it and fold multiple repetitive spans that have the same context into one and display as 10 x SELECT FROM users, for example.
Or we have to track the metrics in the agent.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felixbarny :) I now remember that request.

We should factor in a way to get the Database connections right. The Service Maps should show accurate connectivity data regardless of how fast it is being executed. In the future, we'd also want to add a dependencies/Database page to track all the database queries for a particular service - if we drop these spans now we will have to add back some logic in to add these back. Also, omitting fast SQL queries may hinder a user from detecting a n+1 query problem all together(especially if those queries are quick).

I like the example you provided to fold multiple repetitive spans with the same context to display them. That would solve both the too many spans issue while keeping the maps accurate and allowing for any future development.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good points, Neha. span_min_duration seems to be more of a band-aid fix. Re-implementing that for other agents probably doesn't make sense as it's not a good solution long-term.
Maybe we need a solution that tackles the problem of excessive data collection more holistically. Some thoughts on this:
Spans that exceed transaction_max_spans are currently discarded the same way as spans faster than span_min_duration. Maybe we need a way of attaching information to the transaction about how many spans were discarded by span type and destination. We could use this information both in the waterfall view (we've omitted 42 DB spans to a MySQL DB that took 1.234s in total) and to calculate edge metrics to DBs accurately in case we dropped data. We already collect breakdown metrics that contain similar data but we don't group them by destination and don't attach them to transactions.
Another thing to reconsider is trying to deduplicate spans that just contain repetitive information, such as n+1 queries or 100s of Redis cache GET calls in a row.

Do you have a sense of the priority of this? Should we remove span_min_duration from 7.11? Should we try to get to a holistic solution within the 7.11 timeframe?

@felixbarny felixbarny added this to the 7.11 milestone Oct 20, 2020
such as outgoing HTTP requests,
can't be discarded.
Additionally, spans that lead to an error or that may be a parent of an async operation can't be discarded.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that may be a parent of an async operation can't be discarded.

Repeating what was mentioned elsewhere -- this requirement means that for the Node.js Agent "in the real world" that no spans will be eligible for discarding.

The culture around Node.js heavily encourages the use of asynchronous programming patterns -- specifically asynchronous callback APIs and Promise based APIs. For example -- the typical handling of a HTTP(s) request in Node.js will look like

  1. Register a callback function to handle a specific route/url
  2. This callback makes a request to the application's data layer (db query, orm, etc) for some data, which occurs asynchronously, and registers a second callback function
  3. This route handling callback finishes execution.
  4. When the asynchronous request for data finishes, node calls the second callback. This callback typically handles sending the HTTP response

While it's possible to construct a route handling callback that works synchronously in Node.js -- it's not very common in the real world.

@nehaduggal (since @alex-fedotyev is currently on leave) -- the above means that the span_min_duration feature, as speced, wouldn't help any Node.js users with their too many spans problems.

@felixbarny
Copy link
Member Author

Closing this as the proposal has several shortcomings (see #314 (comment)). Instead, we'll discuss alternatives and a more holistic solution in a working group.

@felixbarny felixbarny closed this Nov 18, 2020
@felixbarny felixbarny removed this from the 7.11 milestone Nov 18, 2020
@Alsheh
Copy link

Alsheh commented Jun 20, 2022

@felixbarny has the holistic solution been discussed? If so, where can we track the progress of this feature? Thanks.

@felixbarny
Copy link
Member Author

We did not end up implementing the ability to drop arbitrary spans across agents as async context propagation makes it hard to determine whether a span can be safely dropped. Instead, we focussed on dropping fast exit spans: #496.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet