Clarify activation method when version unknown

[SylvainJuge]

Assume that the server version is not 8.7.0 and send the activation_method by default.

• Create PR as draft
• Approval by at least one other agent
• Mark as Ready for Review (automatically requests reviews from all agents and PM via CODEOWNERS)
  • Remove PM from reviewers if impact on product is negligible
  • Remove agents from reviewers if the change is not relevant for them
• Approved by at least 2 agents + PM (if relevant)
• Merge after 7 days passed without objections
  To auto-merge the PR, add /schedule YYYY-MM-DD to the PR description.
• Create implementation issues through the meta issue template (this will automate issue creation for individual agents)
• If this spec adds a new dynamic config option, add it to central config.

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-03-31T08:15:59.810+0000

• Duration: 3 min 7 sec

[Mpdreamz]

LGTM, I much prefer this optimistic default to send it UNLESS we explicitly know its the version with the bug not the other way around.

[trentm]

Actually, wait. This wording of the spec suggests that we only want to send activation_method for >=8.7.1.
Do we want activation_method data for earlier APM server versions, like 8.5, 8.6? Or is it not useful for those earlier versions?

[basepi]

Yeah, worth noting that we're doing this for >=8.7.1, no lower versions. And this spec change matches our behavior already. elastic/apm-agent-python#1787

[Mpdreamz]

I just found that in .NET we basically only do the get server information API call once.

If a user upgrades, we'll continue to not send activation method untill the users app restarts.

To me this is an acceptable tradeoff vs having no metrics. Wonder how everyone else feels about this though.

[SylvainJuge]

I just found that in .NET we basically only do the get server information API call once.

In Java too, we only do it once on agent startup, and we also have to make that call asynchronous to prevent blocking when trying to get the agent remote configuration. Also, we only serialize metadata once which further complicates the logic here.

If a user upgrades, we'll continue to not send activation method untill the users app restarts.

You mean upgrade the apm-server, not the apm agent here ? For Java (and likely others), this effectively means that if the agent is started with a 8.7.0 server, then it won't send it until the application is restarted.

To me this is an acceptable tradeoff vs having no metrics. Wonder how everyone else feels about this though.

💯 here, however I'm pretty sure it's a topic that will come back with serverless and managed apm server instance.
One possible approach would be to make apm-server provide the effective version through HTTP response headers, so the agent can adapt to the apm-server features dynamically when sending data (or fetching remote configuration).

[beniwohli]

Same in Python, we only get the server version at agent initialization. Maybe it would make sense to add the server version to e.g. the config endpoint response at some point, but I agree that the current behaviour is fine for now.

[trentm]

I just found that in .NET we basically only do the get server information API call once.

Same for the Node.js agent.

[SylvainJuge]

I will merge as we all agree on this one, also it seems that the implementation in agents also fit this already, so I won't create a meta+agent implementation issues here.

Feel free to create issues and PRs linked to this one if needed though.