diff --git a/modules/ROOT/pages/howto-manage-couchbase-logging.adoc b/modules/ROOT/pages/howto-manage-couchbase-logging.adoc index a8d3326..94b3cbe 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" # <.> ---- @@ -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: