[apm] Update APM decision tree diagram

[colleenmcginnis]

Description

Updates the APM decision tree to address feedback from @eedugon including:

• Clarifies that when we ask about using other integrations, we mean other integrations with APM Server.
• Clarifies what we mean by running APM Server on the edge vs centrally.
  • Adds a brief description to the diagram itself.
  • Adds to the list of pros of using a Fleet-managed APM Server that you can centrally manage multiple APM Servers running on edge machines.

Note: In #4669 @eedugon mentioned that where the user is running APM Server (edge machine vs centrally) doesn't technically determine whether they must use Fleet-managed or APM Server binary. However, the goal of this section is to help a new user make a decision based on several factors not to be a complete reference of all implementations that are or aren't possible with Elastic APM. Is there anything we can change about the intro to the "Help me decide" section to make that clearer? @bmorelli25 any thoughts here?

Documentation sets edited in this PR

Check all that apply.

• Stateful (docs/en/observability/*)
• Serverless (docs/en/serverless/*)
• Integrations Developer Guide (docs/en/integrations/*)
• None of the above

Related issue

Closes #4669

Checklist

• Product/Engineering Review
• Writer Review

Follow-up tasks

Select one.

• This PR does not need to be ported to another doc set because:
  • The concepts in this PR only apply to one doc set (serverless or stateful)
  • The PR contains edits to both doc sets (serverless and stateful)
• This PR needs to be ported to another doc set:
  • Port to stateful docs: <link to PR or tracking issue>
  • Port to serverless docs: <link to PR or tracking issue>

[github-actions]

A documentation preview will be available soon.

• 🔨 Buildkite builds
• 📚 HTML diff
• 📙 Preview page

Request a new doc build by commenting

• Rebuild this PR: run docs-build
• Rebuild this PR and all Elastic docs: run docs-build rebuild

_{run docs-build is much faster than run docs-build rebuild. A rebuild should only be needed in rare situations.}

_{If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here.}

[eedugon]

The explanations look awesome in my opinion! I like it a lot.

Quick comment about one of them, not very important:

An APM agent and APM Server live on each edge machine

Considering an edge machine might (or typically) host multiple applications that could be instrumented, I would state it with something like:

• APM agents and APM server live on each edge machine (just using the plural for APM agents).

Anyway your proposal looks good also.

The only pending issue I see in the diagram is this one:

I would suggest to find the way to state that the Fleet Server of the drawing colocated with the APM Server is not mandatory, just a suggestion in case the user doesn't have a Fleet Server already in place.

What I'd like to avoid is users thinking that they must deploy Fleet Server together with APM Server always.

(UPDATE: ops... I think this is covered in #4714 ) -> sorry for the noise!

[bmorelli25]

Note: In #4669 @eedugon mentioned that where the user is running APM Server (edge machine vs centrally) doesn't technically determine whether they must use Fleet-managed or APM Server binary. However, the goal of this section is to help a new user make a decision based on several factors not to be a complete reference of all implementations that are or aren't possible with Elastic APM. Is there anything we can change about the intro to the "Help me decide" section to make that clearer? @bmorelli25 any thoughts here?

When the initial flowchart was created, one goal was to encourage folks who wanted to run APM Server on the edge to use Fleet-managed APM. That's not a goal anymore. I like the clarifications that Edu suggested. I also agree that this isn't meant to be a complete reference of all possibilities. Can we just directly say that? Something like:

Help me decide
This decision tree highlights key factors to help you make an informed decision about implementing Elastic APM. It provides practical guidance and is not intended to serve as a comprehensive reference of all possible implementations and capabilities.