1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OBSDOCS-2226: fix issues identified by the CQA

This commit is contained in:
Eliska Romanova
2025-09-12 10:14:55 +02:00
parent 2b8d89c8e3
commit a2c6e9833d
5 changed files with 21 additions and 30 deletions

View File

@@ -55,7 +55,7 @@ labels::
Labels are key-value pairs that you can use to organize and select subsets of objects such as a pod.
node::
A worker machine in the {product-title} cluster. A node is either a virtual machine (VM) or a physical machine.
A compute machine in the {product-title} cluster. A node is either a virtual machine (VM) or a physical machine.
Operator::
The preferred method of packaging, deploying, and managing a Kubernetes application in an {product-title} cluster. An Operator takes human operational knowledge and encodes it into software that is packaged and shared with customers.
@@ -79,7 +79,7 @@ Prometheus adapter::
The Prometheus Adapter translates Kubernetes node and pod queries for use in Prometheus. The resource metrics that are translated include CPU and memory utilization. The Prometheus Adapter exposes the cluster resource metrics API for horizontal pod autoscaling.
Prometheus Operator::
The Prometheus Operator (PO) in the `openshift-monitoring` project creates, configures, and manages platform Prometheus and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
The Prometheus Operator in the `openshift-monitoring` project creates, configures, and manages platform Prometheus and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
Silences::
A silence can be applied to an alert to prevent notifications from being sent when the conditions for an alert are true. You can mute an alert after the initial notification, while you work on resolving the underlying issue.

View File

@@ -10,7 +10,7 @@
ifndef::openshift-dedicated,openshift-rosa[]
{product-version}
endif::openshift-dedicated,openshift-rosa[]
includes an optional enhancement to the monitoring stack that enables you to monitor services and pods in user-defined projects. This feature includes the following components:
includes an optional enhancement to the monitoring stack that helps you monitor services and pods in user-defined projects. This feature includes the following components:
.Components for monitoring user-defined projects
[options="header"]
@@ -19,10 +19,10 @@ includes an optional enhancement to the monitoring stack that enables you to mon
|Component|Description
|Prometheus Operator
|The Prometheus Operator (PO) in the `openshift-user-workload-monitoring` project creates, configures, and manages Prometheus and Thanos Ruler instances in the same project.
|The Prometheus Operator in the `openshift-user-workload-monitoring` project creates, configures, and manages Prometheus and Thanos Ruler instances in the same project.
|Prometheus
|Prometheus is the monitoring system through which monitoring is provided for user-defined projects. Prometheus sends alerts to Alertmanager for processing.
|Prometheus is the monitoring system that provides monitoring for user-defined projects. Prometheus sends alerts to Alertmanager for processing.
|Thanos Ruler
|The Thanos Ruler is a rule evaluation engine for Prometheus that is deployed as a separate process. In {product-title}
@@ -39,8 +39,8 @@ endif::openshift-dedicated,openshift-rosa[]
ifndef::openshift-dedicated,openshift-rosa[]
[NOTE]
====
The components in the preceding table are deployed after monitoring is enabled for user-defined projects.
The components in the preceding table are deployed after you enable monitoring for user-defined projects.
====
endif::openshift-dedicated,openshift-rosa[]
All of these components are monitored by the stack and are automatically updated when {product-title} is updated.
The monitoring stack monitors all components for user-defined projects. The components are automatically updated when {product-title} is updated.

View File

@@ -6,7 +6,7 @@
[id="default-monitoring-components_{context}"]
= Default monitoring components
By default, the {product-title} {product-version} monitoring stack includes these components:
By default, the {product-title} {product-version} monitoring stack includes the following components:
.Default monitoring stack components
[options="header"]
@@ -18,10 +18,10 @@ By default, the {product-title} {product-version} monitoring stack includes thes
|The {cmo-first} is a central component of the monitoring stack. It deploys, manages, and automatically updates Prometheus and Alertmanager instances, Thanos Querier, Telemeter Client, and metrics targets. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
|Prometheus Operator
|The Prometheus Operator (PO) in the `openshift-monitoring` project creates, configures, and manages platform Prometheus instances and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
|The Prometheus Operator in the `openshift-monitoring` project creates, configures, and manages platform Prometheus instances and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
|Prometheus
|Prometheus is the monitoring system on which the {product-title} monitoring stack is based. Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
|The {product-title} monitoring stack is based on the Prometheus monitoring system. Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
|Prometheus Adapter
|The Prometheus Adapter (PA in the preceding diagram) translates Kubernetes node and pod queries for use in Prometheus. The resource metrics that are translated include CPU and memory utilization metrics. The Prometheus Adapter exposes the cluster resource metrics API for horizontal pod autoscaling. The Prometheus Adapter is also used by the `oc adm top nodes` and `oc adm top pods` commands.
@@ -52,11 +52,11 @@ You can use {cmo-full} config map settings to manage monitoring-plugin resources
|Thanos Querier aggregates and optionally deduplicates core {product-title} metrics and metrics for user-defined projects under a single, multi-tenant interface.
|Telemeter Client
|Telemeter Client sends a subsection of the data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
|Telemeter Client sends a subsection of the data from platform Prometheus instances to Red{nbsp}Hat to enable remote health monitoring for clusters.
|===
All of the components in the monitoring stack are monitored by the stack and are automatically updated when {product-title} is updated.
The monitoring stack monitors all components within the stack. The components are automatically updated when {product-title} is updated.
[NOTE]
====

View File

@@ -3,33 +3,30 @@
// * virt/support/virt-openshift-cluster-monitoring.adoc
// * observability/monitoring/monitoring-overview.adoc
// This module uses a conditionalized title so that the module
// can be re-used in associated products but the title is not
// included in the existing OpenShift assembly.
:_mod-docs-content-type: CONCEPT
[id="understanding-the-monitoring-stack_{context}"]
= Understanding the monitoring stack
The monitoring stack includes the following components:
* *Default platform monitoring components*.
Default platform monitoring components::
ifndef::openshift-dedicated,openshift-rosa[]
A set of platform monitoring components are installed in the `openshift-monitoring` project by default during an OpenShift Container Platform installation. This provides monitoring for core cluster components including Kubernetes services. The default monitoring stack also enables remote health monitoring for clusters.
A set of platform monitoring components are installed in the `openshift-monitoring` project by default during an {product-title} installation. This provides monitoring for core cluster components including Kubernetes services. The default monitoring stack also enables remote health monitoring for clusters.
endif::openshift-dedicated,openshift-rosa[]
ifdef::openshift-dedicated,openshift-rosa[]
A set of platform monitoring components are installed in the `openshift-monitoring` project by default during a {product-title} installation. Red Hat Site Reliability Engineers (SRE) use these components to monitor core cluster components including Kubernetes services. This includes critical metrics, such as CPU and memory, collected from all of the workloads in every namespace.
A set of platform monitoring components are installed in the `openshift-monitoring` project by default during a {product-title} installation. Red{nbsp}Hat Site Reliability Engineers (SRE) use these components to monitor core cluster components including Kubernetes services. This includes critical metrics, such as CPU and memory, collected from all of the workloads in every namespace.
endif::openshift-dedicated,openshift-rosa[]
+
These components are illustrated in the *Installed by default* section in the following diagram.
You can see these components in the *Installed by default* section in the following diagram.
* *Components for monitoring user-defined projects*.
Components for monitoring user-defined projects::
ifndef::openshift-dedicated,openshift-rosa[]
After optionally enabling monitoring for user-defined projects, additional monitoring components are installed in the `openshift-user-workload-monitoring` project. This provides monitoring for user-defined projects.
If you enable monitoring for user-defined projects, additional monitoring components are installed in the `openshift-user-workload-monitoring` project. This provides optional monitoring for user-defined projects.
endif::openshift-dedicated,openshift-rosa[]
ifdef::openshift-dedicated,openshift-rosa[]
A set of user-defined project monitoring components are installed in the `openshift-user-workload-monitoring` project by default during a {product-title} installation. You can use these components to monitor services and pods in user-defined projects.
endif::openshift-dedicated,openshift-rosa[]
These components are illustrated in the *User* section in the following diagram.
+
You can see these components in the *User* section in the following diagram.
image:monitoring-architecture.png[{product-title} monitoring architecture]

View File

@@ -10,7 +10,7 @@ The {product-title}
ifdef::openshift-rosa[]
(ROSA)
endif::openshift-rosa[]
monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. The monitoring stack includes default monitoring components and components for monitoring user-defined projects.
monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. You can learn about the monitoring stack architecture, which includes default monitoring components and components for monitoring user-defined projects.
// Understanding the monitoring stack
include::modules/monitoring-understanding-the-monitoring-stack.adoc[leveloffset=+1]
@@ -48,9 +48,3 @@ ifndef::openshift-dedicated,openshift-rosa[]
* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-monitor-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Granting users permissions for monitoring for user-defined projects]
* xref:../../../security/tls-security-profiles.adoc#tls-security-profiles[Configuring TLS security profiles]
endif::openshift-dedicated,openshift-rosa[]