Create new Container Log Collection Troubleshooting Doc

[kohyoungheon]

What does this PR do? What is the motivation?

https://datadoghq.atlassian.net/browse/TEEP-3046

• Create new Container Log Collection Troubleshooting Doc
• Create menu item for new doc
• Update existing Docker/Kubernetes log collection docs to link to this new doc in further reading sections and troubleshooting sections
• Remove old docker log collection troubleshooting guide

Merge instructions

Merge readiness:

• [ ] Ready for merge

For Datadog employees:

Your branch name MUST follow the <name>/<description> convention and include the forward slash (/). Without this format, your pull request will not pass CI, the GitLab pipeline will not run, and you won't get a branch preview. Getting a branch preview makes it easier for us to check any issues with your PR, such as broken links.

If your branch doesn't follow this format, rename it or create a new branch and PR.

[6/5/2025] Merge queue has been disabled on the documentation repo. If you have write access to the repo, the PR has been reviewed by a Documentation team member, and all of the required checks have passed, you can use the Squash and Merge button to merge the PR. If you don't have write access, or you need help, reach out in the #documentation channel in Slack.

Additional notes

[github-actions[bot]]

Preview links (active after the build_preview check completes)

New or renamed files

• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/containers/troubleshooting/log-collection

Removed or renamed files (these should redirect)

• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/logs/guide/docker-logs-collection-troubleshooting-guide

Modified Files

• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/containers/docker/log
• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/containers/kubernetes/log
• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/getting_started/tagging/

[buraizu]

Created DOCS-12883 for documentation team review

[JacksonDavenport]

Happy with the changes from the Containers TEE side 👍 , but can you also adjust this page:

• https://docs-staging.datadoghq.com/young.koh/containers_log_troubleshooting/getting_started/tagging/#tag-inheritance
• https://github.com/DataDog/documentation/blob/young.koh/containers_log_troubleshooting/content/en/getting_started/tagging/_index.md?plain=1#L170

This links to the Kubernetes log doc and its now removed troubleshooting section

[kohyoungheon]

Hi @estherk15 Thank you so much for reviewing this PR! I spoke to the containers TEE team about these particular suggestions:

1. The first section should be split off as a guide. It's high level and walks a reader through the why's of log collection and troubleshooting, rather than the how.

We would like for this section to stay in the troubleshooting doc where it currently is. It's meant to summarize the Kubernetes, Docker, Tagging, Autodiscovery steps into their most basic parts. Then importantly build upon that in the following troubleshooting sections.

For example:

• Providing you info on where the Log files are maintained and then later showing how to export them
• Telling you the autodiscovery rules, then showing how the status and configcheck can show your logs are being tailed and what config is applied -Showing you the tagging rules, then showing how stream-logs can expose these tags and how hostname preprocessing can be affected

Separating them to their own page I feel would make this troubleshooting process less clear as you would have to switch between those pages.

2. As for that other optional change of moving from tabs to table/description list, we would like to keep these as tabs for consistency between the chunky Autodiscovery configuration sections.

Thank you. Please let me know if you would like me to make any other changes!

[estherk15]

@kohyoungheon Thanks for checking with the TEE team and sharing their reasoning. I agree that the context connects well to the later troubleshooting steps. My only concern is that when users land on a troubleshooting page, they’re usually trying to solve something right away, and a long introductory section can slow them down.

I still think the context is important, just possibly better positioned as prerequisite or collapsible content so it supports, rather than interrupts, troubleshooting. But I’m happy to work with whichever direction the team prefers.

[JacksonDavenport]

Hey @estherk15 Young and I chatted some more about this. I think we'd prefer to keep the structure as is. If users are really in a rush they can use the menu on the right to skip right to the Troubleshooting commands and Common Issues sections. But ideally they do take the time to get the quick context on how everything works and take stock relative to the questions in those first sections. In that sense I'd agree that this is really a prerequisite step for your troubleshooting more than anything.

The alternative of putting this in a different doc feels like it would be cumbersome to navigate between the two for such a related topic. Having it as collapsible content in each of the troubleshooting commands sections may make those sections too wordy. Some of this context overlaps as well between the status, configcheck, and stream-logs output which might make that difficult.

We could change the parent headers like the following (or to whatever you'd prefer) if you think that might flow better than Log collection context.

## Overview
## Troubleshooting prerequisites
### Log files
### ...

## Troubleshooting methods
### Agent status
### ...

## Common issues
### ....