From e622d5c29bbe64b19db707ba76cbefcd738b441d Mon Sep 17 00:00:00 2001 From: Ray Offiah Date: Fri, 20 Feb 2026 10:56:55 +0000 Subject: [PATCH 1/2] [DOC-9897]: documentation: smart quotes in examples -> issues Corrected smart quotes. Minor corrections. Signed-off-by: Ray Offiah --- .../pages/howto-manage-couchbase-logging.adoc | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/modules/ROOT/pages/howto-manage-couchbase-logging.adoc b/modules/ROOT/pages/howto-manage-couchbase-logging.adoc index a8d33261..396b1207 100644 --- a/modules/ROOT/pages/howto-manage-couchbase-logging.adoc +++ b/modules/ROOT/pages/howto-manage-couchbase-logging.adoc @@ -6,7 +6,7 @@ The Kubernetes Operator can be configured to manage certain aspects of Couchbase == Overview -The Couchbase Server application records important events, and saves the details to a xref:server:manage:manage-logging/manage-logging.adoc#log-file-listing[variety] of log files. +The Couchbase Server application records important events and saves the details to a xref:server:manage:manage-logging/manage-logging.adoc#log-file-listing[variety] of log files. These logs are distinct from the logs that are generated by the Kubernetes Operator xref:concept-operator-logging.adoc[itself]. Logging is performed continuously within each Couchbase Server container in a Couchbase deployment. @@ -24,7 +24,7 @@ Couchbase Server xref:server:learn:security/auditing.adoc[audit logging] is a sp When audit logging is enabled, Couchbase Server begins recording information on _who_ has performed _what_ action, _when_, and _how_ successfully. Audit records are written as JSON documents to a default file, named `audit.log`, which is stored alongside all other Couchbase Server log files in the `default` or `logs` volume that is attached to the pod. -After a specified period time, or once the file reaches a specified size (whichever happens first), the file is closed, and is saved under a modified name that features a timestamp corresponding to the time of saving. +After a specified period of time, or once the file reaches a specified size, (whichever happens first), the file is closed and is saved under a modified name that features a timestamp corresponding to the time of saving. A new, empty `audit.log` file is created and saved when a new audit event is generated. There are two approaches you can choose when it comes to implementing audit logging: <> and <>. @@ -52,7 +52,7 @@ It is expected that the administrator will implement an automated system for exp === Configuring Automated Audit Logging NOTE: Automated audit logging requires that logs be written to a persistent volume (i.e. the Couchbase deployment's `default` or `logs` volumes are backed by xref:best-practices.adoc#storage[persistent storage]). -Fully-ephemeral clusters are not supported by this feature. +This feature does not support fully-ephemeral clusters. _Automated_ audit logging involves having the Kubernetes Operator handle the audit log configuration and optionally manage the resultant audit log files. An audit logging configuration can be specified in the xref:resource/couchbasecluster.adoc[`CouchbaseCluster`] resource specification, allowing the Kubernetes Operator to set up audit logging in Couchbase Server, and optionally manage the resultant audit log files. @@ -75,8 +75,8 @@ spec: - "@eventing/local" - "@cbq-engine/local" rotation: - interval: “15m” - size: “20Mi” + interval: "15m" + size: "20Mi" pruneAge: "1h" # <.> ---- @@ -105,7 +105,7 @@ NOTE: Changing the location of the audit log is not supported, as it would break ==== Sidecar Garbage Collection kbd:[deprecated] -Native audit log cleanup was introduced in Couchbase Server 7.2.4, for earlier versions the Couchbase Kubernetes Operator can deploy a sidecar container with the Couchbase Server to cleanup rotated logs. +Native audit log cleanup was introduced in Couchbase Server 7.2.4, for earlier versions the Couchbase Kubernetes Operator can deploy a sidecar container with the Couchbase Server to clean up rotated logs. [source,yaml,subs="attributes,verbatim"] ---- @@ -121,14 +121,14 @@ spec: - "@eventing/local" - "@cbq-engine/local" rotation: - interval: “15m” - size: “20Mi” + interval: "15m" + size: "20Mi" garbageCollection: sidecar: enabled: true # <.> image: "{logging-helper}" # <.> - age: “1h” - interval: “20m” + age: "1h" + interval: "20m" resources: requests: cpu: @@ -158,7 +158,7 @@ It is highly recommended that you use, or migrate to, one of the other modes. == Collecting Logs The Kubernetes Operator package is distributed with a support tool -- xref:tools/cao.adoc[`cao`] -- which can be used to collect logs from Couchbase Server deployments. -The xref:tools/cao.adoc[`cao`] tool performs _explicit logging_, which means it captures a snapshot of the current logs at the time the tool is was run. +The xref:tools/cao.adoc[`cao`] tool performs _explicit logging_, which means it captures a snapshot of the current logs at the time the tool is run. Explicit logging can either be performed for all nodes in the cluster, or for one or more individual nodes. The results are saved as zip files: each zip file contains the log-data generated for an individual node. @@ -270,7 +270,7 @@ The general process for manual log collection is as follows: + Pausing management of the Couchbase cluster serves two purposes. The first purpose is that it will prevent the Kubernetes Operator from attempting to recover the malfunctioning pod after Kubernetes has killed it. -The second purpose is that it allows you to create a temporary replacement pod and mount the the detached PVCs to it without the Kubernetes Operator interfering. +The second purpose is that it allows you to create a temporary replacement pod and mount the detached PVCs to it without the Kubernetes Operator interfering. . Create a temporary pod resource with the persistent volumes mounted. The basic template will look like the following: From b6ecf791d87719ec1988fbdf49532d93c6ff3189 Mon Sep 17 00:00:00 2001 From: Ray Offiah <77050471+RayOffiah@users.noreply.github.com> Date: Fri, 20 Feb 2026 11:57:13 +0000 Subject: [PATCH 2/2] Update modules/ROOT/pages/howto-manage-couchbase-logging.adoc Co-authored-by: rao-shwe --- modules/ROOT/pages/howto-manage-couchbase-logging.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/howto-manage-couchbase-logging.adoc b/modules/ROOT/pages/howto-manage-couchbase-logging.adoc index 396b1207..5bb57c18 100644 --- a/modules/ROOT/pages/howto-manage-couchbase-logging.adoc +++ b/modules/ROOT/pages/howto-manage-couchbase-logging.adoc @@ -158,7 +158,7 @@ It is highly recommended that you use, or migrate to, one of the other modes. == Collecting Logs The Kubernetes Operator package is distributed with a support tool -- xref:tools/cao.adoc[`cao`] -- which can be used to collect logs from Couchbase Server deployments. -The xref:tools/cao.adoc[`cao`] tool performs _explicit logging_, which means it captures a snapshot of the current logs at the time the tool is run. +The xref:tools/cao.adoc[`cao`] tool performs explicit logging, which means it captures a snapshot of the current logs at the time the tool is run. Explicit logging can either be performed for all nodes in the cluster, or for one or more individual nodes. The results are saved as zip files: each zip file contains the log-data generated for an individual node.