[Fleet][APM] Discuss: Setup of APM integration

[ruflin]

With the move to Fleet an APM integration will have to be setup for APM to be working. In some environments like Cloud, K8s APM should work "out of the box" and be part of the same policy as fleet-server #90408 This issue is to discuss on how to facilitate this best.

To simplify the setup for APM, the idea around an API endpoint from #90408 could be used here to. Having an API endpoint like /api/apm/apm-policy-setup could allow to have a single endpoint that can be called for setup. This endpoint could have different parameters to allow additional functionalities. Some ideas:

• No params: Adds APM to the Fleet policy with defaults appropriate for the environment
• APM Server config as param: Create a policy out of the apm-server configs and pushes it to the Fleet policy
• Policy id passed in: Adds APM to the given policy id with default appropriate for the environment

In all cases, the apm package is installed / upgraded if not already the case. Having just one API endpoint means even if we find ways to improve the setup for some environments or be able to do additional magic, someone having implemented code for the API call will not have to make any changes.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[simitt]

This sound like it would make the setup for APM for Cloud easier at the moment. I am worried though that the solution is too specific. How do we deal with other integrations in the future that should be set up by default? In the longer term, ideally APM would not need a special treatment compared to other ingest integrations. Could we make that a bit more generic? Some endpoint like api/setup/policy/:policy-id/package/:package-name?environment=<type>-<size>, so api/setup/policy/fleet-policy-id/package/apm?environment=ess-4gb.

• package-name would be validated Kibana side, and only a defined enum of package-names is supported (to start with: apm).

These changes should not have an impact on the param examples you mentioned above.

with defaults appropriate for the environment

How exactly would that work? I'm not sure if the defaults for the environment should be required to be passed as request body, instead of making Kibana aware of them.

#90408 and this feature request are rather similar. I wonder if we could take it one step further and combine both under one endpoint. For the fleet server the above mentioned endpoint would then be api/setup/policy/fleet-default/package/fleet-sever. If the fleet-default policy doesn't exist, it gets created.

[ruflin]

I like the idea of combining it under one or a similar endpoint to use the same concept. The defaults per environment is where specific "solution" related code would have to be called and is why I landed initially on having the code in APM. Maybe APM can register a hook? Passing in the environment as variable will make it easier instead of trying to detect it. But I would separate the environment (ess, k8s) from size of Agents or similar. This could also be passed in as additional param if it is needed to make more decisions but there should be a default.

@nchaulet Can you chime in here as you were thinking about the fleet-server setup?

[ruflin]

I think the part we agree is that we should make it at the moment for Cloud as easy as possible to setup. Basically it should be a single API Call that is made for the setup. What is setup by default and the exact configs depends on the environment. Ideally what the setup should exactly look like could be defined as a config option for Kibana: #88956 Like this each environment could specify how things should look and /fleet/setup would take this and bring Kibana to the requested state.

Alternative I see two main options.

• Parameterise the /fleet/setup API call: A parameter environment=cloud, environment=k8s be passed in an in Kibana we have hardcoded what this means for setup.
• Specific environment API calls: /fleet/cloud/setup: Instead of passing in params, each envrionment has its own API call.

I'm currently leaning in the direction of the parameters or the setup through config.

[ruflin]

Currently an internal discussion is ongoing to cover the setup through an API call which takes the format described here as an input: #88956 Having this would allow each environment to pass in the config needed for the setup. More to come soon.

[ph]

@Zacqary you may want to follow this issue, its related to the bootstrap of integration and agent policy of Kibana.

[ruflin]

My current assumption is that this will solved by the setup work from @Zacqary

[jen-huang]

Now that the work for preconfigured policies has been merged (#94509, #97328), which allows for setup via API or kibana.yml, I think this can be closed. Feel free to reopen or create new issues if more work is needed.