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

Auto-inference of destination.service.resource #1898

Merged
merged 8 commits into from
Jul 7, 2021

Conversation

eyalkoren
Copy link
Contributor

@eyalkoren eyalkoren commented Jul 5, 2021

What does this PR do?

Closing #1848

Checklist

  • This is an enhancement of existing features, or a new feature in existing plugins
    • I have updated CHANGELOG.asciidoc
    • I have added tests that prove my fix is effective or that my feature works
    • Added an API method or config option? Document in which version this will be introduced
    • I have made corresponding changes to the documentation
    • I added the test JSON spec to the APM repo

@eyalkoren eyalkoren requested a review from SylvainJuge July 5, 2021 09:14
@AlexanderWert AlexanderWert added this to the 7.15 milestone Jul 5, 2021
@eyalkoren
Copy link
Contributor Author

I started also implementing the addition of the creation of exit spans, as described in the spec, but I think it doesn't make a lot of sense in the Java agent, as we don't expose any API to add custom data. A new API for exit span creation will look something like startExitSpan(String type, String subtype, String action), which means that the type or subtype will be used for auto-inference of the service.resource, however this is essentially a capability we already offer through the API to set the service resource explicitly. @felixbarny WDYT?

@apmmachine
Copy link
Contributor

apmmachine commented Jul 5, 2021

💚 Build Succeeded

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

Expand to view the summary

Build stats

  • Start Time: 2021-07-06T19:39:18.053+0000

  • Duration: 59 min 54 sec

  • Commit: 7106971

Test stats 🧪

Test Results
Failed 0
Passed 2327
Skipped 19
Total 2346

Trends 🧪

Image of Build Times

Image of Tests

💚 Flaky test report

Tests succeeded.

Expand to view the summary

Test stats 🧪

Test Results
Failed 0
Passed 2327
Skipped 19
Total 2346

@felixbarny
Copy link
Member

however this is essentially a capability we already offer through the API to set the service resource explicitly

The difference is that users don't need to remember setting resource fields or worry about which value to set in order for the span to show up in the service map.

@eyalkoren
Copy link
Contributor Author

The difference is that users don't need to remember setting resource fields or worry about which value to set in order for the span to show up in the service map.

Users will have to remember this new dedicated API and not the "default" one, and I think it's actually better to force them to think what the resource would be, instead of implicitly use type or subtype.

@eyalkoren
Copy link
Contributor Author

As decided offline with @felixbarny - the exit span creation API is added.

Comment on lines 69 to 88
{
"span": {
"exit": "true",
"type": "db",
"subtype": "elasticsearch",
"context": {
"db": {
"type": "elasticsearch"
},
"http": {
"url": {
"host": "my-cluster.com",
"port": 9200
}
}
}
},
"inferred_resource": "elasticsearch",
"failure_message": "If `context.db` exists without `context.db.instance`, the subtype should be used, even if `context.http` exists"
},
Copy link
Member

Choose a reason for hiding this comment

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

We have the following priorities when inferring resource:

  • use context.db first if available (1)
  • then try to use context.messaging if available (2)
  • then try to use context.http if available (3)

While the relative ordering or (1) vs (3) is tested with the Elasticsearch case, we don't have test that ensures that (2) comes before (3), even if having a mix of messaging and http is unlikely we'd better cover this corner case. Also, maybe having a case with all of them should default to using the db part.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I'll add a test for messaging combined with http, but I don't think combining db and messaging makes sense

@eyalkoren eyalkoren merged commit d0e00ba into elastic:master Jul 7, 2021
@eyalkoren eyalkoren deleted the service-resource-auto-inference branch July 7, 2021 02:56
@AlexanderWert AlexanderWert linked an issue Jul 12, 2021 that may be closed by this pull request
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[META 448] Auto-infer destination.service.resource and adapt public API
5 participants