[Elastic Agent] Debug fleet-server connectivity

[ruflin]

The Elastic Agent must connect to the fleet-server for enrollement. There are several issues that can happen around the connectivity to fleet-server. If the enrollment doesn't work, it would be nice to have a command line tool to investigate on what the actual issue is. Things like: certificate issue, port not open, host not reachable, wrong token etc.

This idea was triggered by issues like this one: elastic/fleet-server#235 (comment)

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[jlind23]

Can we close this one in favour of elastic/beats#27764?

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[ruflin]

This is not necessarily the same thing. One is around having better errors, the other one is around having a command to test the connection. I think we need both. We have done something similar for LS in Beats and it worked out really well.

[michel-laterman]

If this is provided as a command we can also include it in diagnostics output/bundles

[ph]

I was looking at the user issue and precisely investigating a connection problem, As a normal user I was able to start Elastic-Agent run and the agent was able to successfully connect to fleet-server. When the Elastic Agent was run under systemd the agent was unable to connect to the remote server. When discussing with the user, we was unaware that he had a http(s)_proxy configured on this system. By default systemd start the process with a clean environment and doesn't inherit the globally set proxy variables.

When we ask a user for a diagnostic the elastic-agent diagnostic command is run in the current user environment and connect to the other elastic agent. We could add bootstraps checks and return the result to the user.

The first I see is:

Is there an HTTP(S)_PROXY set in the user env?
Is there an HTTP(S)_PROXY set in the elastic-agent environment?