From 3745b9288115220f20f3d7562e8487ee73ffe011 Mon Sep 17 00:00:00 2001 From: Brian Burt Date: Wed, 11 Oct 2023 12:18:53 -0400 Subject: [PATCH] OBSDOCS-569-mod-docs-framework-for-cluster-obs-operator --- ...ng-the-cluster-observability-operator.adoc | 32 +++++++++++++++++++ .../_attributes | 1 + ...uster-observability-operator-overview.adoc | 29 +++++++++++++++++ .../cluster_observability_operator/images | 1 + .../cluster_observability_operator/modules | 1 + .../cluster_observability_operator/snippets | 1 + 6 files changed, 65 insertions(+) create mode 100644 modules/monitoring-understanding-the-cluster-observability-operator.adoc create mode 120000 monitoring/cluster_observability_operator/_attributes create mode 100644 monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc create mode 120000 monitoring/cluster_observability_operator/images create mode 120000 monitoring/cluster_observability_operator/modules create mode 120000 monitoring/cluster_observability_operator/snippets diff --git a/modules/monitoring-understanding-the-cluster-observability-operator.adoc b/modules/monitoring-understanding-the-cluster-observability-operator.adoc new file mode 100644 index 0000000000..e9a1044b5c --- /dev/null +++ b/modules/monitoring-understanding-the-cluster-observability-operator.adoc @@ -0,0 +1,32 @@ +//Module included in the following assemblies: +// +// monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc + +:_content-type: CONCEPT +[id="understanding-the-cluster-observability-operator_{context}"] += Understanding the Cluster Observability Operator + +A default monitoring stack created by the Cluster Observability Operator (COO) includes a highly available Prometheus instance capable of sending metrics to an external endpoint by using remote write. + +Each COO stack also includes an optional Thanos Querier component, which you can use to query a highly available Prometheus instance from a central location, and an optional Alertmanager component, which you can use to set up alert configurations for different services. + +[id="advantages-of-using-cluster-observability-operator_{context}"] +== Advantages of using Cluster Observability Operator + +The `MonitoringStack` CRD used by the COO offers an opinionated default monitoring configuration for COO-deployed monitoring components, but you can customize it to suit more complex requirements. + +Deploying a COO-managed monitoring stack can help meet monitoring needs that are difficult or impossible to address by using the core platform monitoring stack deployed by the Cluster Monitoring Operator (CMO). +A monitoring stack deployed using COO has the following advantages over core platform and user workload monitoring: + +Extendability:: Users can add more metrics to a COO-deployed monitoring stack, which is not possible with core platform monitoring without losing support. +In addition, COO-managed stacks can receive certain cluster-specific metrics from core platform monitoring by using federation. +Multi-tenancy support:: The COO can create a monitoring stack per user namespace. +You can also deploy multiple stacks per namespace or a single stack for multiple namespaces. +For example, cluster administrators, SRE teams, and development teams can all deploy their own monitoring stacks on a single cluster, rather than having to use a single shared stack of monitoring components. +Users on different teams can then independently configure features such as separate alerts, alert routing, and alert receivers for their applications and services. +Scalability:: You can create COO-managed monitoring stacks as needed. +Multiple monitoring stacks can run on a single cluster, which can facilitate the monitoring of very large clusters by using manual sharding. This ability addresses cases where the number of metrics exceeds the monitoring capabilities of a single Prometheus instance. +Flexibility:: Deploying the COO with Operator Lifecycle Manager (OLM) decouples COO releases from {product-title} release cycles. +This method of deployment enables faster release iterations and the ability to respond rapidly to changing requirements and issues. +Additionally, by deploying a COO-managed monitoring stack, users can manage alerting rules independently of {product-title} release cycles. +Highly customizable:: The COO can delegate ownership of single configurable fields in custom resources to users by using Server-Side Apply (SSA), which enhances customization. diff --git a/monitoring/cluster_observability_operator/_attributes b/monitoring/cluster_observability_operator/_attributes new file mode 120000 index 0000000000..f27fd275ea --- /dev/null +++ b/monitoring/cluster_observability_operator/_attributes @@ -0,0 +1 @@ +../_attributes/ \ No newline at end of file diff --git a/monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc b/monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc new file mode 100644 index 0000000000..997cc15ddc --- /dev/null +++ b/monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc @@ -0,0 +1,29 @@ +:_content-type: ASSEMBLY +[id="cluster-observability-operator-overview"] += Cluster Observability Operator overview +include::_attributes/common-attributes.adoc[] +:context: cluster_observability_operator_overview + +toc::[] + +:FeatureName: Using the Cluster Observability Operator +include::snippets/technology-preview.adoc[leveloffset=+2] + +The Cluster Observability Operator (COO) is an optional component of the {product-title}. You can deploy it to create standalone monitoring stacks that are independently configurable for use by different services and users. + +The COO deploys the following monitoring components: + +* Prometheus +* Thanos Querier (optional) +* Alertmanager (optional) + +The COO components function independently of the default in-cluster monitoring stack, which is deployed and managed by the Cluster Monitoring Operator (CMO). +Monitoring stacks deployed by the two Operators do not conflict. You can use a COO monitoring stack in addition to the default platform monitoring components deployed by the CMO. + +include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1] + +[role="_additional-resources"] +.Additional resources + +* link:https://kubernetes.io/docs/reference/using-api/server-side-apply/[Kubernetes documentation for Server-Side Apply (SSA)] + diff --git a/monitoring/cluster_observability_operator/images b/monitoring/cluster_observability_operator/images new file mode 120000 index 0000000000..e4c5bd02a1 --- /dev/null +++ b/monitoring/cluster_observability_operator/images @@ -0,0 +1 @@ +../images/ \ No newline at end of file diff --git a/monitoring/cluster_observability_operator/modules b/monitoring/cluster_observability_operator/modules new file mode 120000 index 0000000000..43aab75b53 --- /dev/null +++ b/monitoring/cluster_observability_operator/modules @@ -0,0 +1 @@ +../modules/ \ No newline at end of file diff --git a/monitoring/cluster_observability_operator/snippets b/monitoring/cluster_observability_operator/snippets new file mode 120000 index 0000000000..9f5bc7e4dd --- /dev/null +++ b/monitoring/cluster_observability_operator/snippets @@ -0,0 +1 @@ +../snippets \ No newline at end of file