Update install-layout.asciidoc to reflect logging changes introduced in 8.6.0

[rseldner]

Updated widget to reflect the logging changes introduced in 8.6.0 (v2 architecture) to close this issue: #175

1. switched agent log file from elastic-agent-json.log to elastic-agent.ndjson
2. with the exception of Endpoint, beats/component logs are written to elastic-agent.ndjson rather than their own log file.

I believe the logging changes were introduces in the v2 architecture:
elastic/elastic-agent#1701

[mergify]

This pull request does not have a backport label. Could you fix it @rseldner? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-/d./d is the label to automatically backport to the /d./d branch. /d is the digit
  NOTE: backport-skip has been added to this pull request.

[rseldner]

I think this should be backported as far as 8.6 but not seeing a label for that version.

[kilfoyle]

LGTM! Just a few minor suggestions to use the "Beats" attribute/variable.

As for backporting, our general policy is to backport only into active releases (the ones shown in the docs release dropdown).

[mergify]

This pull request is now in conflict. Could you fix it @rseldner? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch <remote-repo>
git checkout -b rseldner-patch-1 <remote-repo>/rseldner-patch-1
git merge <remote-repo>/main
git push <remote-repo> rseldner-patch-1

[rseldner]

Hi @kilfoyle this resulted in conflicts because it was not merged in time. I believe I resolved the conflicts. Can you take a look?

[kilfoyle]

Hi @rseldner. Looks good! I just applied my suggestions so that we use the {beats} variable rather than the literal "beats". Assuming the CI checks pass, I'll merge this today. Thanks for adding this docs fix!

[kilfoyle]

By the way, I should explain this a bit better:

As for backporting, our general policy is to backport only into active releases (the ones shown in the docs release dropdown).

We avoid pushing docs changes into releases that are no longer active because it can create an expectation that all changes are handled this way (and often we're unable to push changes into certain releases). Rather than create inconsistency, we try to stick to a policy of updating only the "active" branches. Just wanted to add some clarity about that. :-)