Improve Agent container cmd and fleet-server logs

[jlind23]

Describe the enhancement:
Following development of #28260 we should ensure that logs are explicitly telling what is going on under the hood.
Logs in the agent container cmd and fleet-server should detail where we are at during the bootstraping process.
Per example: that apm-server is started but fleet-server not yet etc.

[elasticmachine]

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

[blakerouse]

@jlind23 Can you provide some more detail on what your looking for here? The reporting from Fleet Server back to the Elastic Agent logs and reports what it's waiting on.

https://github.com/elastic/fleet-server/blob/master/internal/pkg/policy/self.go#L200

If you see that function it both reports those messages to Elastic Agent and logs to disk. Elastic Agent then also reports those messages as being received from Fleet Server.

[ruflin]

Trying to remember what exactly we were missing here. The goal here is that when we have some issues in Cloud, that we can look at the logs and exactly tell if there is an issue with fleet-server during the setup, if it is hold back by Kibana, missing integrations and how apm-server is doing. Is this possible with the above?

[jlind23]

@blakerouse any reason why extendedMessage variable is not used here: https://github.com/elastic/fleet-server/blob/master/internal/pkg/policy/self.go#:~:text=can%20perform%20enrollment.-,tokens%2C%20err%20%3A%3D%20m.enrollmentTokenF(ctx%2C%20m.bulker%2C%20m.policy.PolicyId,%7D,-%7D ?

[blakerouse]

@jlind23 Yes because it would not be possible for the Elastic Agent to enroll at all without enrollment keys. Add the extendedMessage there would be redundant, and conflate the issue. The issue at that point of time is that it must have an enrollment key before it can continue.