Include TLS information in diagnostics bundle

[ycombinator]

Describe the enhancement:

Following up on the work @michel-laterman did in elastic/fleet-server#3587 to include information about TLS connections made by Fleet Server, we should similarly include information about TLS connections made by Agent in the diagnostics bundle.

Describe a specific use case for the enhancement or feature:

To be able to debug TLS-related connectivity issues.

What is the definition of done?

• A new file is included in the diagnostics bundle. This file should contain information related to TLS connections made by Elastic Agent. See Add tlscommon and httpcommon diagnostics hooks fleet-server#3587 (comment) for the information being included by Fleet Server.

[elasticmachine]

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

[cmacknz]

My comment in #4881 (comment) applies here too. There are three network locations agent can be configured to reach and we need to test all of them.

I think it may be better if we implement a test command that can hit each of the three network locations agent needs to function.

I think it may be better if we implement a test command that can hit each of the three network locations agent needs to function. These are:

• elastic-agent test output that connects to the output in the policy and prints detailed information about what happened.
• elastic-agent test fleet [options] that contacts Fleet Server with the options provided, or if already enrolled makes a test request using the options persisted in the agent encrypted store.
• elastic-agent test download that contacts the binary download source and prints detailed information about what happened.

We could have diagnostics attempt each of these by default, with a configurable timeout, and an option to skip these checks.

[michel-laterman]

I think if we want to include connectivity tests by default we should adjust the elastic-agent diagnostics command, as well as the actions the fleet-ui generates to include a new parameter so the hook can be registered with client.RegisterOptionalDiagnosticHook, and using a skip flag/option would not send the param.

Or we can skip executing the connectivity checks by default, and explicitly add the new parameter if we want to gather this data (similar to how CPU metrics are requested).

I don't know if we have any way currently to configure a timeout for diagnostics actions, and the current elastic-agent-client spec/implementation does not have a way to specify an action timeout

[cmacknz]

I think we probably want connectivity checks by default, with an option to skip them. Connectivity problems are a frequent source of support cases so may as well include them by default.

We 100% will need timeouts, diagnostics can't block forever waiting for a reply from an unresponsive server.