From 971d934351973d7985ffdea661d16264b94c566c Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 20 Mar 2025 10:34:46 -0700 Subject: [PATCH 01/20] [docs] Add RFC for managed CR --- docs/rfcs/managed.md | 142 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 docs/rfcs/managed.md diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md new file mode 100644 index 0000000000..4325a44297 --- /dev/null +++ b/docs/rfcs/managed.md @@ -0,0 +1,142 @@ +# TITLE + +**Status:** *Draft* + +**Author:** Antoine Toulme (@atoulme) + +**Date:** 2025-03-20 + +## Objective + +Condense all best practices and deployment patterns of OpenTelemetry components into a single custom resource +that covers the feature set of the OpenTelemetry Helm chart. + +## Summary +This request for comment aims to establish a new approach to management of resources in Kubernetes clusters, +specifically in Openshift environments, with the explicit goal of taking over the whole cluster, and making decisions +on how to best instrument all resources in the cluster on behalf of the administrator based on best practices, +OpenTelemetry standards and semantic conventions. + +The operator project offers custom resources (CR) to allow Kubernetes operators to define OpenTelemetry components +in their Kubernetes environments. Customers however do not want to manage components themselves, especially if they need +to think about component versioning and upgrade patterns, and would rather have an out-of-the-box experience that +requires little insight and gets them to a working state effortlessly. + +## Goals and non-goals + +### Give a comprehensive, out-of the box experience of OpenTelemetry for a first-time user +The goal is to delight first-time customers by giving them a complete view of what is possible with OpenTelemetry. + +### Do not offer a way to turn on and off specific features +We mean to offer a specific functional coverage of a specific use case that offers best practices of OpenTelemetry. + +We don't allow to toggle features in and out specifically because we want to avoid increasing the need for functional test coverage. + +If customers want to increase their level of control of the feature set, they can remove the managed custom resource and instead +follow the traditional route of setting up collectors, target allocators, instrumentation custom resources as is possible today. + +## Use cases for proposal + +### Initial installation + +The customer wants to install the operator and immediately get value from the installation. + +Upon installation, they install the custom resource with information on an OTLP endpoint where they can direct all data. + +### Upgrade + +The customer wants to upgrade their operator. All assets are upgraded out of the box in concert as part of the upgrade, +and are guaranteed to work through functional test coverage. + +### Deletion and reinstallation + +The customer can cleanly delete the custom resource, which triggers the deletion of all OpenTelemetry assets under +management by the operator. No stragglers are left. + +### Kubernetes metrics + +The customer upon installation of the custom resource can see Kubernetes cluster metrics as reported by the k8sclusterreceiver with default configuration. + +### Kubeletstats metrics + +The customer upon installation receives metrics from all Kubeletstats metrics from the default configuration of the kubeletstats receiver. + +### Automatic instrumentation + +All standard CRDs for instrumentations are all enabled by default for all namespaces. + +### Node host metrics + +The customer upon installation receives metrics from hostmetrics receiver with its default configuration. + +Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization. + +### Node logs + +The customer upon installation will receive all logs from Kubernetes, scraped with the filelog receiver from the file system. + +### Kubernetes entities + +When entities become viable, the customer will receive Kubernetes entities as reported by the k8sclusterreceiver. + +## Struct Design + +```go +import "go.opentelemetry.io/collector/exporter/otlpexporter" + +type ManagedCustomResource struct { + ExporterConfig otlpexporter.Config `yaml:"exporter"` +} +``` + +```yaml +--- +apiVersion: apiextensions.k8s.io/v1 +kind: CustomResourceDefinition +metadata: + annotations: + controller-gen.kubebuilder.io/version: v0.32.0 + name: managed.opentelemetry.io +spec: + group: opentelemetry.io + names: + kind: Managed + listKind: ManagedList + plural: manageds + singular: managed + scope: Cluster + versions: + - additionalPrinterColumns: + - jsonPath: .metadata.creationTimestamp + name: Age + type: date + - jsonPath: .spec.exporter.endpoint + name: Endpoint + type: string + name: v1alpha1 + schema: + openAPIV3Schema: + properties: + apiVersion: + type: string + kind: + type: string + metadata: + type: object + spec: + properties: + exporter: + + type: object + type: object + served: true + storage: true + +``` +## Rollout Plan + +See https://github.com/open-telemetry/opentelemetry-operator/issues/3818 + +## Limitations + +This managed resource is not aiming to please all users of the operator. This is a limited experience to deliver best practices and a comprehensive feature set encompassing many elements of OpenTelemetry. \ No newline at end of file From e7fea77e7e85db19d701fc7644fb8fd5c1611e73 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 20 Mar 2025 11:05:45 -0700 Subject: [PATCH 02/20] Update docs/rfcs/managed.md Co-authored-by: Israel Blancas --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 4325a44297..fb3e874e1f 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -1,4 +1,4 @@ -# TITLE +# Managed CRD **Status:** *Draft* From dd6898c02a9e80118eb942fcd4ceabe571af4d7b Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Fri, 21 Mar 2025 09:10:39 -0700 Subject: [PATCH 03/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index fb3e874e1f..ee6b9dae57 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -13,7 +13,7 @@ that covers the feature set of the OpenTelemetry Helm chart. ## Summary This request for comment aims to establish a new approach to management of resources in Kubernetes clusters, -specifically in Openshift environments, with the explicit goal of taking over the whole cluster, and making decisions +with the explicit goal of taking over the whole cluster, and making decisions on how to best instrument all resources in the cluster on behalf of the administrator based on best practices, OpenTelemetry standards and semantic conventions. From 7ee440f86910c8f6c7d186f3fe8efdc2214fe837 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Fri, 4 Apr 2025 06:54:09 +0100 Subject: [PATCH 04/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index ee6b9dae57..755f244f39 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -17,7 +17,7 @@ with the explicit goal of taking over the whole cluster, and making decisions on how to best instrument all resources in the cluster on behalf of the administrator based on best practices, OpenTelemetry standards and semantic conventions. -The operator project offers custom resources (CR) to allow Kubernetes operators to define OpenTelemetry components +The operator project offers custom resources (CR) to allow Kubernetes users/administrators to define OpenTelemetry components in their Kubernetes environments. Customers however do not want to manage components themselves, especially if they need to think about component versioning and upgrade patterns, and would rather have an out-of-the-box experience that requires little insight and gets them to a working state effortlessly. From c2191e4974666306b0e53524331162e07ce1272f Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sat, 19 Apr 2025 23:17:48 -0700 Subject: [PATCH 05/20] Changes based on code review --- docs/rfcs/managed.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 755f244f39..eb0ea8df9a 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -35,6 +35,11 @@ We don't allow to toggle features in and out specifically because we want to avo If customers want to increase their level of control of the feature set, they can remove the managed custom resource and instead follow the traditional route of setting up collectors, target allocators, instrumentation custom resources as is possible today. +### OTLP, single endpoint support + +The solution exports data to a single endpoint using the OTLP gRPC protocol. Customers may choose to deploy a gateway +to transform, filter, redact data before sending it to storage. + ## Use cases for proposal ### Initial installation @@ -53,31 +58,25 @@ and are guaranteed to work through functional test coverage. The customer can cleanly delete the custom resource, which triggers the deletion of all OpenTelemetry assets under management by the operator. No stragglers are left. -### Kubernetes metrics +### Infrastructure monitoring -The customer upon installation of the custom resource can see Kubernetes cluster metrics as reported by the k8sclusterreceiver with default configuration. +The customer upon installation of the custom resource can see Kubernetes cluster metrics, and kubeletstats metrics. -### Kubeletstats metrics +The customer can follow events and receive Kubernetes entity data. -The customer upon installation receives metrics from all Kubeletstats metrics from the default configuration of the kubeletstats receiver. +The customer upon installation receives metrics from hostmetrics receiver with its default configuration. Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization. -### Automatic instrumentation +### Workload monitoring All standard CRDs for instrumentations are all enabled by default for all namespaces. -### Node host metrics - -The customer upon installation receives metrics from hostmetrics receiver with its default configuration. - -Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization. - ### Node logs The customer upon installation will receive all logs from Kubernetes, scraped with the filelog receiver from the file system. -### Kubernetes entities +## configuration -When entities become viable, the customer will receive Kubernetes entities as reported by the k8sclusterreceiver. +The customer can enable exporting signals individually: metrics, logs, traces and profiles. ## Struct Design @@ -85,6 +84,9 @@ When entities become viable, the customer will receive Kubernetes entities as re import "go.opentelemetry.io/collector/exporter/otlpexporter" type ManagedCustomResource struct { + # List of signals supported: `logs`, `metrics`, `traces`, `profiles` + Signals []string `yaml:"signals"` + # OTLP exporter configuration ExporterConfig otlpexporter.Config `yaml:"exporter"` } ``` From d73d044d0ab309167f026c220459dec143ec7a26 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sat, 19 Apr 2025 23:30:36 -0700 Subject: [PATCH 06/20] add a bit on how the CR will adopt different platforms and enable different features based on those --- docs/rfcs/managed.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index eb0ea8df9a..6b6d731d01 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -40,6 +40,12 @@ follow the traditional route of setting up collectors, target allocators, instru The solution exports data to a single endpoint using the OTLP gRPC protocol. Customers may choose to deploy a gateway to transform, filter, redact data before sending it to storage. +### Context-aware + +Best practices differ between platforms, cloud providers, available endpoints, node operating system and so on. + +The solution will enable features based on those parameters. For example, it will deploy Openshift-specific features when deployed on the Openshift Cloud Platform. + ## Use cases for proposal ### Initial installation From 42c268c3868087f394d3b3f6fe52676bfb90e687 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Tue, 29 Apr 2025 09:12:49 -0700 Subject: [PATCH 07/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 6b6d731d01..5435891f7a 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -80,7 +80,7 @@ All standard CRDs for instrumentations are all enabled by default for all namesp The customer upon installation will receive all logs from Kubernetes, scraped with the filelog receiver from the file system. -## configuration +## Configuration The customer can enable exporting signals individually: metrics, logs, traces and profiles. From c7cd0a9c2767583ff734f6f41057d7d51697b102 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Tue, 29 Apr 2025 09:13:26 -0700 Subject: [PATCH 08/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 5435891f7a..8b88a9b63e 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -37,7 +37,7 @@ follow the traditional route of setting up collectors, target allocators, instru ### OTLP, single endpoint support -The solution exports data to a single endpoint using the OTLP gRPC protocol. Customers may choose to deploy a gateway +The solution exports data to a single endpoint using the OTLP protocol. Customers may choose to deploy a gateway to transform, filter, redact data before sending it to storage. ### Context-aware From 0f6006fe8ad2ce8d1801847660a0675a2a7f27b4 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Tue, 29 Apr 2025 09:14:19 -0700 Subject: [PATCH 09/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 8b88a9b63e..a4c9950ab4 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -9,7 +9,7 @@ ## Objective Condense all best practices and deployment patterns of OpenTelemetry components into a single custom resource -that covers the feature set of the OpenTelemetry Helm chart. +that covers the use cases fulfilled by the OpenTelemetry helm charts. ## Summary This request for comment aims to establish a new approach to management of resources in Kubernetes clusters, From e5beb6536d4a7b554d01c6af91f1fecb34ead8b6 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Wed, 30 Apr 2025 11:32:29 -0700 Subject: [PATCH 10/20] Update docs/rfcs/managed.md --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index a4c9950ab4..bbdabd4b8f 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -78,7 +78,7 @@ All standard CRDs for instrumentations are all enabled by default for all namesp ### Node logs -The customer upon installation will receive all logs from Kubernetes, scraped with the filelog receiver from the file system. +The customer upon installation will receive logs from the node operating system, as well as pod logs from Kubernetes, scraped with the filelog receiver from the file system. ## Configuration From c8d9cc3c4cc824dbb0e6239cf1878ababbe5275c Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:33:31 -0700 Subject: [PATCH 11/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index bbdabd4b8f..feee6b8d01 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -74,7 +74,7 @@ The customer upon installation receives metrics from hostmetrics receiver with i ### Workload monitoring -All standard CRDs for instrumentations are all enabled by default for all namespaces. +All standard CRDs for instrumentations are enabled by default for all namespaces. ### Node logs From c0deb647df45143021823e5ec8632dcf274f2f31 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:33:38 -0700 Subject: [PATCH 12/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index feee6b8d01..b8d37fb9b6 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -56,7 +56,7 @@ Upon installation, they install the custom resource with information on an OTLP ### Upgrade -The customer wants to upgrade their operator. All assets are upgraded out of the box in concert as part of the upgrade, +The user wants to upgrade their operator. All assets are upgraded out of the box in concert as part of the upgrade, and are guaranteed to work through functional test coverage. ### Deletion and reinstallation From 4e14c2f68b43d56873ad53e99fdcb4022b3cd017 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:33:45 -0700 Subject: [PATCH 13/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index b8d37fb9b6..921041baac 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -78,7 +78,7 @@ All standard CRDs for instrumentations are enabled by default for all namespaces ### Node logs -The customer upon installation will receive logs from the node operating system, as well as pod logs from Kubernetes, scraped with the filelog receiver from the file system. +The user upon installation will receive logs from the node operating system, as well as pod logs from Kubernetes, scraped with the filelog receiver from the file system. ## Configuration From 57653239422e4eaee5ef7ed36cc6de9437337f9d Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:33:52 -0700 Subject: [PATCH 14/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 921041baac..13171d3542 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -82,7 +82,7 @@ The user upon installation will receive logs from the node operating system, as ## Configuration -The customer can enable exporting signals individually: metrics, logs, traces and profiles. +The user can enable exporting signals individually: metrics, logs, traces and profiles. ## Struct Design From 7e59d759087d391f46d92249a4e6c7fa47ec2117 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:34:00 -0700 Subject: [PATCH 15/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 13171d3542..c272ce9b1a 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -50,7 +50,7 @@ The solution will enable features based on those parameters. For example, it wil ### Initial installation -The customer wants to install the operator and immediately get value from the installation. +The user wants to install the operator and immediately get value from the installation. Upon installation, they install the custom resource with information on an OTLP endpoint where they can direct all data. From 02d608123249602090944331fc6ab577dd61d139 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:34:07 -0700 Subject: [PATCH 16/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index c272ce9b1a..cb1705c074 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -70,7 +70,7 @@ The customer upon installation of the custom resource can see Kubernetes cluster The customer can follow events and receive Kubernetes entity data. -The customer upon installation receives metrics from hostmetrics receiver with its default configuration. Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization. +The user upon installation receives metrics from hostmetrics receiver with its default configuration. Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization. ### Workload monitoring From 9980088ad42944ca36becb473f80bde3d5fdfbba Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:34:17 -0700 Subject: [PATCH 17/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index cb1705c074..b67c90772d 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -25,7 +25,7 @@ requires little insight and gets them to a working state effortlessly. ## Goals and non-goals ### Give a comprehensive, out-of the box experience of OpenTelemetry for a first-time user -The goal is to delight first-time customers by giving them a complete view of what is possible with OpenTelemetry. +The goal is to delight first-time users by giving them a complete view of what is possible with OpenTelemetry. ### Do not offer a way to turn on and off specific features We mean to offer a specific functional coverage of a specific use case that offers best practices of OpenTelemetry. From aefe7a04ca4c1fc0d4f550fea1becde12cfad557 Mon Sep 17 00:00:00 2001 From: Antoine Toulme Date: Thu, 8 May 2025 12:34:23 -0700 Subject: [PATCH 18/20] Update docs/rfcs/managed.md Co-authored-by: Jacob Aronoff --- docs/rfcs/managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index b67c90772d..7a4e6ea440 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -30,7 +30,7 @@ The goal is to delight first-time users by giving them a complete view of what i ### Do not offer a way to turn on and off specific features We mean to offer a specific functional coverage of a specific use case that offers best practices of OpenTelemetry. -We don't allow to toggle features in and out specifically because we want to avoid increasing the need for functional test coverage. +We don't allow toggling features specifically because we want to avoid increasing the need for functional test coverage. If customers want to increase their level of control of the feature set, they can remove the managed custom resource and instead follow the traditional route of setting up collectors, target allocators, instrumentation custom resources as is possible today. From 4f7cfb4d3b5eb209aa112779ddac303273500741 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 9 May 2025 08:14:39 -0700 Subject: [PATCH 19/20] name change Managed -> ClusterObservability --- docs/rfcs/managed.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index 7a4e6ea440..de57b1070a 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -89,7 +89,7 @@ The user can enable exporting signals individually: metrics, logs, traces and pr ```go import "go.opentelemetry.io/collector/exporter/otlpexporter" -type ManagedCustomResource struct { +type ClusterObservability struct { # List of signals supported: `logs`, `metrics`, `traces`, `profiles` Signals []string `yaml:"signals"` # OTLP exporter configuration @@ -100,18 +100,18 @@ type ManagedCustomResource struct { ```yaml --- apiVersion: apiextensions.k8s.io/v1 -kind: CustomResourceDefinition +kind: ClusterObservability metadata: annotations: controller-gen.kubebuilder.io/version: v0.32.0 - name: managed.opentelemetry.io + name: clusterobservability.opentelemetry.io spec: group: opentelemetry.io names: - kind: Managed - listKind: ManagedList - plural: manageds - singular: managed + kind: ClusterObservability + listKind: ClusterObservabilityList + plural: co11ys + singular: co11y scope: Cluster versions: - additionalPrinterColumns: From 977ab2c8dc9bbdb37c2e9dea155d71c443ae7a6a Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Tue, 13 May 2025 11:54:17 -0700 Subject: [PATCH 20/20] customer->user --- docs/rfcs/managed.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/rfcs/managed.md b/docs/rfcs/managed.md index de57b1070a..fe69282177 100644 --- a/docs/rfcs/managed.md +++ b/docs/rfcs/managed.md @@ -18,7 +18,7 @@ on how to best instrument all resources in the cluster on behalf of the administ OpenTelemetry standards and semantic conventions. The operator project offers custom resources (CR) to allow Kubernetes users/administrators to define OpenTelemetry components -in their Kubernetes environments. Customers however do not want to manage components themselves, especially if they need +in their Kubernetes environments. Users however do not want to manage components themselves, especially if they need to think about component versioning and upgrade patterns, and would rather have an out-of-the-box experience that requires little insight and gets them to a working state effortlessly. @@ -32,12 +32,12 @@ We mean to offer a specific functional coverage of a specific use case that offe We don't allow toggling features specifically because we want to avoid increasing the need for functional test coverage. -If customers want to increase their level of control of the feature set, they can remove the managed custom resource and instead +If Users want to increase their level of control of the feature set, they can remove the managed custom resource and instead follow the traditional route of setting up collectors, target allocators, instrumentation custom resources as is possible today. ### OTLP, single endpoint support -The solution exports data to a single endpoint using the OTLP protocol. Customers may choose to deploy a gateway +The solution exports data to a single endpoint using the OTLP protocol. Users may choose to deploy a gateway to transform, filter, redact data before sending it to storage. ### Context-aware @@ -61,14 +61,14 @@ and are guaranteed to work through functional test coverage. ### Deletion and reinstallation -The customer can cleanly delete the custom resource, which triggers the deletion of all OpenTelemetry assets under +The user can cleanly delete the custom resource, which triggers the deletion of all OpenTelemetry assets under management by the operator. No stragglers are left. ### Infrastructure monitoring -The customer upon installation of the custom resource can see Kubernetes cluster metrics, and kubeletstats metrics. +The user upon installation of the custom resource can see Kubernetes cluster metrics, and kubeletstats metrics. -The customer can follow events and receive Kubernetes entity data. +The user can follow events and receive Kubernetes entity data. The user upon installation receives metrics from hostmetrics receiver with its default configuration. Note the metrics map to the host, meaning the collector will have access to host volumes to scrape their utilization.