Merge pull request #96830 from ochromy/OBSDOCS-2233

eromanova97 · web-flow · commit 1994bffb8c1d · 2025-08-20T12:27:01.000+02:00
[OBSDOCS-2233] fix typos in Logging 6.0
diff --git a/about/quick-start.adoc b/about/quick-start.adoc
@@ -8,7 +8,7 @@ toc::[]
 
 .Prerequisites
 * You have access to an {ocp-product-title} cluster with `cluster-admin` permissions.
-* You installed the {oc-first}.
+* You have installed the {oc-first}.
 * You have access to a supported object store. For example, AWS S3, Google Cloud Storage, {azure-short}, Swift, Minio, or {rh-storage}.
 
 .Procedure
diff --git a/configuring/configuring-log-forwarding.adoc b/configuring/configuring-log-forwarding.adoc
@@ -38,11 +38,11 @@ metadata:
 
 == Managing the Operator
 
-The `ClusterLogForwarder` resource has a `managementState` field that controls whether the operator actively manages its resources or leaves them Unmanaged:
+The `ClusterLogForwarder` resource has a `managementState` field that controls whether the Operator actively manages its resources or leaves them unmanaged:
 
-Managed:: (default) The operator will drive the logging resources to match the desired state in the CLF spec.
+Managed:: (default) The Operator will drive the logging resources to match the desired state in the CLF spec.
 
-Unmanaged:: The operator will not take any action related to the logging components.
+Unmanaged:: The Operator will not take any action related to the logging components.
 
 This allows administrators to temporarily pause log forwarding by setting `managementState` to `Unmanaged`.
 
@@ -85,7 +85,7 @@ googleCloudLogging:: Forwards logs to Google Cloud Logging.
 http:: Forwards logs to a generic HTTP endpoint.
 kafka:: Forwards logs to a Kafka broker.
 loki:: Forwards logs to a Loki logging backend.
-lokistack:: Forwards logs to the logging supported combination of Loki and web proxy with {ocp-product-title} authentication integration. LokiStack's proxy uses {ocp-product-title} authentication to enforce multi-tenancy
+lokistack:: Forwards logs to the logging supported combination of Loki and web proxy with {ocp-product-title} authentication integration. LokiStack's proxy uses {ocp-product-title} authentication to enforce multi-tenancy.
 otlp:: Forwards logs using the OpenTelemetry Protocol.
 splunk:: Forwards logs to Splunk.
 syslog:: Forwards logs to an external syslog server.
diff --git a/configuring/configuring-the-log-store.adoc b/configuring/configuring-the-log-store.adoc
@@ -26,15 +26,15 @@ include::modules/logging-loki-storage-minio.adoc[leveloffset=+2]
 include::modules/logging-loki-storage-odf.adoc[leveloffset=+2]
 include::modules/logging-loki-storage-swift.adoc[leveloffset=+2]
 
-//Loki stirage STS
+//Loki storage STS
 [id="installing-log-storage-loki-sts"]
 === Deploying a Loki log store on a cluster that uses short-term credentials
 
 For some storage providers, you can use the Cloud Credential Operator utility (`ccoctl`) during installation to implement short-term credentials. These credentials are created and managed outside the {ocp-product-title} cluster. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/authentication_and_authorization/managing-cloud-provider-credentials#cco-short-term-creds[Manual mode with short-term credentials for components].
 
-[NOTE]
+[IMPORTANT]
 ====
-Short-term credential authentication must be configured during a new installation of {loki-op}, on a cluster that uses this credentials strategy. You cannot configure an existing cluster that uses a different credentials strategy to use this feature.
+Short-term credential authentication must be configured during a new installation of {loki-op} on a cluster that uses this credentials strategy. You cannot configure an existing cluster that uses a different credentials strategy to use this feature.
 ====
 
 include::modules/logging-identity-federation.adoc[leveloffset=+3]
diff --git a/installing/installing-logging.adoc b/installing/installing-logging.adoc
@@ -34,7 +34,7 @@ If you have the pull secret, add the `redhat-operators` catalog to the `Operator
 [id="installing-loki-and-logging-cli_{context}"]
 == Installation by using the CLI
 
-The following sections describe installing the {loki-op} and the {clo} by using the CLI.
+As an administrator, you can install the {loki-op} and the {clo} by using the CLI.
 
 include::modules/installing-loki-operator-cli.adoc[leveloffset=+2]
 include::modules/installing-logging-operator-cli.adoc[leveloffset=+2]
@@ -43,7 +43,7 @@ include::modules/installing-the-logging-ui-plug-in-cli.adoc[leveloffset=+2]
 [id="installing-loki-and-logging-gui_{context}"]
 == Installation by using the web console
 
-The following sections describe installing the {loki-op} and the {clo} by using the web console.
+As an administrator, you can install the {loki-op} and the {clo} by using the web console.
 
 include::modules/installing-loki-operator-web-console.adoc[leveloffset=+2]
 include::modules/installing-logging-operator-web-console.adoc[leveloffset=+2]
diff --git a/modules/installing-loki-operator-cli.adoc b/modules/installing-loki-operator-cli.adoc
@@ -24,7 +24,7 @@ metadata:
   labels:
     openshift.io/cluster-monitoring: "true" # <2>
 ----
-<1> You must specify `openshift-operators-redhat` as the namespace. To enable monitoring for the operator, configure Cluster Monitoring Operator to scrape metrics from the `openshift-operators-redhat` namespace and not the `openshift-operators` namespace. The `openshift-operators` namespace might contain community operators, which are untrusted and could publish a metric with the same name as an {ocp-product-title} metric, causing conflicts.
+<1> You must specify `openshift-operators-redhat` as the namespace. To enable monitoring for the Operator, configure Cluster Monitoring Operator to scrape metrics from the `openshift-operators-redhat` namespace and not the `openshift-operators` namespace. The `openshift-operators` namespace might contain community operators, which are untrusted and could publish a metric with the same name as an {ocp-product-title} metric, causing conflicts.
 <2> A string value that specifies the label as shown to ensure that cluster monitoring scrapes the `openshift-operators-redhat` namespace.
 
 . Apply the `Namespace` object by running the following command:
@@ -75,7 +75,7 @@ spec:
 ----
 <1> You must specify `openshift-operators-redhat` as the namespace.
 <2> Specify `stable-6.<y>` as the channel.
-<3> If the approval strategy in the subscription is set to `Automatic`, the update process initiates as soon as a new operator version is available in the selected channel. If the approval strategy is set to `Manual`, you must manually approve pending updates.
+<3> If the approval strategy in the subscription is set to `Automatic`, the update process initiates as soon as a new Operator version is available in the selected channel. If the approval strategy is set to `Manual`, you must manually approve pending updates.
 <4> Specify `redhat-operators` as the value. If your {ocp-product-title} cluster is installed on a restricted network, also known as a disconnected cluster, specify the name of the `CatalogSource` object that you created when you configured Operator Lifecycle Manager (OLM).
 
 . Apply the `Subscription` object by running the following command:
@@ -85,7 +85,7 @@ spec:
 $ oc apply -f <filename>.yaml
 ----
 
-. Create a `namespace` object for deploy the LokiStack:
+. Create a `namespace` object to deploy the LokiStack:
 +
 .Example `namespace` object
 [source,yaml]
diff --git a/modules/installing-loki-operator-web-console.adoc b/modules/installing-loki-operator-web-console.adoc
@@ -129,5 +129,5 @@ spec:
 
 .Verification
 
-. In the *LokiStack* tab veriy that you see your `LokiStack` instance.
+. In the *LokiStack* tab, verify that you see your `LokiStack` instance.
 . In the *Status* column, verify that you see the message `Condition: Ready` with a green checkmark.
diff --git a/modules/logging-creating-new-group-cluster-admin-user-role.adoc b/modules/logging-creating-new-group-cluster-admin-user-role.adoc
@@ -24,7 +24,7 @@ $ oc adm groups new cluster-admin
 ----
 $ oc adm groups add-users cluster-admin <username>
 ----
-. Enter the following command to add `cluster-admin` user role to the group:
+. Enter the following command to add the `cluster-admin` user role to the group:
 +
 [source,terminal]
 ----
diff --git a/modules/logging-identity-federation.adoc b/modules/logging-identity-federation.adoc
@@ -6,7 +6,7 @@
 [id="logging-identity-federation_{context}"]
 = Authenticating with workload identity federation to access cloud-based log stores
 
-You can use workload identity federation with short-lived tokens to authenticate to cloud-based log stores. With workload identity federation, you do not have to store long-lived credentials in your cluster, which reduces the risk of credential leaks and simplifies secret management.
+You can use workload identity federation with short-lived tokens to authenticate to cloud-based log stores. With workload identity federation, you do not have to store long-lived credentials in your cluster, reducing the risk of credential leaks and simplifying secret management.
 
 .Prerequisites
 
@@ -18,7 +18,7 @@ You can use workload identity federation with short-lived tokens to authenticate
 
 ** If you used the {ocp-product-title} web console to install the {loki-op}, the system automatically detects clusters that use short-lived tokens. You are prompted to create roles and supply the data required for the {loki-op} to create a `CredentialsRequest` object, which populates a secret.
 
-** If you used the {oc-first} to install the {loki-op}, you must manually create a `Subscription` object. Use the appropriate template for your storage provider, as shown in the following samples. This authentication strategy supports only the storage providers indicated within the samples.
+** If you used the {oc-first} to install the {loki-op}, you must manually create a `Subscription` object. Use the appropriate template for your storage provider, as shown in the following samples. This authentication method supports only the providers listed in the examples.
 +
 .{azure-first} sample subscription
 [source,yaml]
diff --git a/modules/logging-loki-log-access.adoc b/modules/logging-loki-log-access.adoc
@@ -4,11 +4,11 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="logging-loki-log-access_{context}"]
-= Fine grained access for Loki logs
+= Fine-grained access for Loki logs
 
-The {clo} does not grant all users access to logs by default. As an administrator, you must configure your users' access unless the Operator was upgraded and prior configurations are in place. Depending on your configuration and need, you can configure fine grain access to logs using the following:
+The {clo} does not grant all users access to logs by default. As an administrator, you must configure your users' access unless the Operator was upgraded and prior configurations are in place. Depending on your configuration and need, you can configure fine-grain access to logs using the following:
 
-* Cluster wide policies
+* Cluster-wide policies
 * Namespace scoped policies
 * Creation of custom admin groups
 
@@ -18,15 +18,15 @@ As an administrator, you need to create the role bindings and cluster role bindi
 * `cluster-logging-infrastructure-view` grants permission to read infrastructure logs.
 * `cluster-logging-audit-view` grants permission to read audit logs.
 
-If you have upgraded from a prior version, an additional cluster role `logging-application-logs-reader` and associated cluster role binding `logging-all-authenticated-application-logs-reader` provide backward compatibility, allowing any authenticated user read access in their namespaces.
+If you have upgraded from a prior version, an additional `logging-application-logs-reader` cluster role and its associated `logging-all-authenticated-application-logs-reader` cluster role binding provide backward compatibility, allowing any authenticated user read access in their namespaces.
 
 [NOTE]
 ====
 Users with access by namespace must provide a namespace when querying application logs.
 ====
 
-== Cluster wide access
-Cluster role binding resources reference cluster roles, and set permissions cluster wide.
+== Cluster-wide access
+Cluster role binding resources reference cluster roles, and set permissions cluster-wide.
 
 .Example ClusterRoleBinding
 [source,yaml]
diff --git a/modules/logging-loki-reliability-hardening.adoc b/modules/logging-loki-reliability-hardening.adoc
@@ -10,7 +10,7 @@ In the {logging} 5.8 and later versions, the {loki-op} supports setting pod anti
 
 include::snippets/about-pod-affinity.adoc[]
 
-The Operator sets default, preferred `podAntiAffinity` rules for all Loki components, which includes the `compactor`, `distributor`, `gateway`, `indexGateway`, `ingester`, `querier`, `queryFrontend`, and `ruler` components.
+The Operator sets default, preferred `podAntiAffinity` rules for all Loki components, which include the `compactor`, `distributor`, `gateway`, `indexGateway`, `ingester`, `querier`, `queryFrontend`, and `ruler` components.
 
 You can override the preferred `podAntiAffinity` settings for Loki components by configuring required settings in the `requiredDuringSchedulingIgnoredDuringExecution` field:
 
diff --git a/modules/logging-release-notes-6-0-8.adoc b/modules/logging-release-notes-6-0-8.adoc
@@ -11,7 +11,7 @@ This release includes link:https://access.redhat.com/errata/RHBA-2025:4520[RHBA-
 [id="logging-release-notes-6-0-8-bug-fixes_{context}"]
 == Bug fixes
 
-* Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication with an Elasticsearch output generates a valid configuration.  (link:https://issues.redhat.com/browse/LOG-7019[LOG-7019])
+* Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication with an Elasticsearch output generates a valid configuration. (link:https://issues.redhat.com/browse/LOG-7019[LOG-7019])
 
 [id="logging-release-notes-6-0-8-cves_{context}"]
 == CVEs
diff --git a/modules/logging-release-notes-6-0-9.adoc b/modules/logging-release-notes-6-0-9.adoc
@@ -11,7 +11,7 @@ This release includes link:https://access.redhat.com/errata/RHBA-2025:8144[RHBA-
 [id="logging-release-notes-6-0-9-bug-fixes_{context}"]
 == Bug fixes
 
-* Before this update, merging data from the `message` field into the root of a Syslog log event caused  inconsistencies with the ViaQ data model. These inconsistencies could overwrite system information, duplicate data, or corrupt the log event. This update makes Syslog parsing and merging consistent with the other output types and resolves the issue. (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
+* Before this update, merging data from the `message` field into the root of a Syslog log event caused inconsistencies with the ViaQ data model. These inconsistencies could overwrite system information, duplicate data, or corrupt the log event. This update makes Syslog parsing and merging consistent with the other output types and resolves the issue. (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
 
 * Before this update, log forwarding failed when the cluster-wide proxy configuration included a URL with a username containing an encoded `@` symbol; for example, `user%40name`. This update adds the correct support for URL-encoded values in proxy configurations and resolves the issue. (link:https://issues.redhat.com/browse/LOG-7186[LOG-7186])
 
diff --git a/modules/loki-pod-placement.adoc b/modules/loki-pod-placement.adoc
@@ -8,7 +8,7 @@
 
 You can control which nodes the Loki pods run on, and prevent other workloads from using those nodes, by using tolerations or node selectors on the pods.
 
-You can apply tolerations to the log store pods with the LokiStack custom resource (CR) and apply taints to a node with the node specification. A taint on a node is a `key:value` pair that instructs the node to repel all pods that do not allow the taint. Using a specific `key:value` pair that is not on other pods ensures that only the log store pods can run on that node.
+You can apply tolerations to the log store pods with the LokiStack custom resource (CR) and apply taints to a node with the node specification. A taint on a node is a `key:value` pair that instructs the node to repel all pods that do not tolerate the taint. Using a specific `key:value` pair that is not on other pods ensures that only the log store pods can run on that node.
 
 .Example LokiStack with node selectors
 [source,yaml]
@@ -48,7 +48,7 @@ spec:
 # ...
 ----
 <1> Specifies the component pod type that applies to the node selector.
-<2> Specifies the pods that are moved to nodes containing the defined label.
+<2> Specifies the pods that are scheduled onto nodes containing the defined label.
 
 
 .Example LokiStack CR with node selectors and tolerations
diff --git a/modules/loki-zone-fail-recovery.adoc b/modules/loki-zone-fail-recovery.adoc
@@ -12,7 +12,7 @@ Loki pods are part of a link:https://kubernetes.io/docs/concepts/workloads/contr
 
 [WARNING]
 ====
-The following procedure will delete the PVCs in the failed zone, and all data contained therein.  To avoid complete data loss the replication factor field of the `LokiStack` CR should always be set to a value greater than 1 to ensure that Loki is replicating.
+The following procedure will delete the PVCs in the failed zone, and all data contained therein. To avoid complete data loss, the replication factor field of the `LokiStack` CR should always be set to a value greater than 1 to ensure that Loki is replicating.
 ====
 
 .Prerequisites
diff --git a/modules/setting-up-log-collection.adoc b/modules/setting-up-log-collection.adoc
@@ -6,11 +6,11 @@
 [id="setting-up-log-collection_{context}"]
 = Setting up log collection
 
-This release of Cluster Logging requires administrators to explicitly grant log collection permissions to the service account associated with *ClusterLogForwarder*. This was not required in previous releases for the legacy logging scenario consisting of a *ClusterLogging* and, optionally, a *ClusterLogForwarder.logging.openshift.io* resource.
+This release of Cluster Logging requires administrators to explicitly grant log collection permissions to the service account associated with *ClusterLogForwarder*. This was not required in previous releases for the legacy logging scenario, which consisted of a *ClusterLogging* resource and, optionally, a *ClusterLogForwarder.logging.openshift.io* resource.
 
 The {clo} provides `collect-audit-logs`, `collect-application-logs`, and `collect-infrastructure-logs` cluster roles, which enable the collector to collect audit logs, application logs, and infrastructure logs respectively.
 
-Setup log collection by binding the required cluster roles to your service account.
+Set up log collection by binding the required cluster roles to your service account.
 
 == Legacy service accounts
 To use the existing legacy service account `logcollector`, create the following *ClusterRoleBinding*:
@@ -41,7 +41,7 @@ $ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccoun
 
 .Procedure
 
-. Create a service account for the collector. If you want to write logs to storage that requires a token for authentication, you must include a token in the service account.
+. Create a service account for the collector. If you want to write logs to a storage system that requires a token for authentication, you must include a token in the service account.
 
 . Bind the appropriate cluster roles to the service account:
 +
@@ -51,8 +51,8 @@ $ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccoun
 $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
 ----
 
-=== Cluster Role Binding for your Service Account
-The role_binding.yaml file binds the ClusterLogging operator's ClusterRole to a specific ServiceAccount, allowing it to manage Kubernetes resources cluster-wide.
+=== Cluster role binding for your service account
+The role_binding.yaml file binds the ClusterLogging Operator's ClusterRole to a specific ServiceAccount, allowing it to manage Kubernetes resources cluster-wide.
 
 [source,yaml]
 ----
@@ -192,7 +192,7 @@ rules:                                              <1>
 ----
 <1> rules: Specifies the permissions this ClusterRole grants.
 <2> apiGroups: Refers to the OpenShift-specific API group
-<3> obervability.openshift.io: The API group for managing observability resources, like logging.
+<3> observability.openshift.io: The API group for managing observability resources, like logging.
 <4> resources: Specifies the resources this role can manage.
 <5> clusterlogforwarders: Refers to the log forwarding resources in OpenShift.
 <6> verbs: Specifies the actions allowed on the ClusterLogForwarders.

Original file line number	Diff line number	Diff line change
`@@ -24,7 +24,7 @@ $ oc adm groups new cluster-admin`
`24`	`24`	`----`
`25`	`25`	`$ oc adm groups add-users cluster-admin <username>`
`26`	`26`	`----`
`27`		-. Enter the following command to add `cluster-admin` user role to the group:
	`27`	+. Enter the following command to add the `cluster-admin` user role to the group:
`28`	`28`	`+`
`29`	`29`	`[source,terminal]`
`30`	`30`	`----`