K8SPSMDB-297 Documented cluster-level logging

[nastena1606]

modified: docs/debug-logs.md

[Copilot]

Pull Request Overview

This PR documents cluster-level logging functionality for the Percona Operator for MongoDB, explaining how logs are persistently stored and managed in Kubernetes environments.

• Adds comprehensive documentation for cluster-level logging feature
• Explains how Fluent Bit is used as a sidecar container for log collection
• Documents configuration options and behavior for the log collector

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The Fluent Bit link appears to be using a syntax for external links that may not render correctly in all markdown processors. Consider using standard markdown link syntax like [Fluent Bit](https://fluentbit.io/) or verify that the :octicons-link-external-16: syntax is supported by your documentation system.

Suggested change

The Operator collects logs using [Fluent Bit :octicons-link-external-16:] - a lightweight log processor, which supports many output plugins and has broad forwarding capabilities. Fluent Bit runs as a sidecar container within each database Pod. It collects logs from the primary `mongod` container, adds metadata, and stores them in a single file in a dedicated log-specific Persistent Volume Claim (PVC) at `/data/db/logs/`. This allows logs to survive Pod restarts and be accessed for later debugging.

The Operator collects logs using [Fluent Bit](https://fluentbit.io/) - a lightweight log processor, which supports many output plugins and has broad forwarding capabilities. Fluent Bit runs as a sidecar container within each database Pod. It collects logs from the primary `mongod` container, adds metadata, and stores them in a single file in a dedicated log-specific Persistent Volume Claim (PVC) at `/data/db/logs/`. This allows logs to survive Pod restarts and be accessed for later debugging.

[Copilot]

[nitpick] The sentence is broken across two lines unnecessarily. Consider joining these lines for better readability: 'You can additionally configure Fluent Bit using the logcollector.configuration subsection in the deploy/cr.yaml Custom Resource manifest.'

Suggested change

	You can additionally configure Fluent Bit using the `logcollector.configuration` subsection in
	the `deploy/cr.yaml` Custom Resource manifest. This allows you to define custom filters and output plugins to suit your specific logging and monitoring needs.
	You can additionally configure Fluent Bit using the `logcollector.configuration` subsection in the `deploy/cr.yaml` Custom Resource manifest. This allows you to define custom filters and output plugins to suit your specific logging and monitoring needs.

[gkech]

However, if the configuration was not empty, subsequent changes won't trigger an update automatically.

If we have a non-empty configuration and we update it for some reason, after applying the changes we will trigger the update without a problem!

[nastena1606]

So in any case we trigger the cluster update?

[egegunes]

yes, update is triggered in either case

[nastena1606]

Fixed