Fix #60: OTEL -> OTel

Signed-off-by: Jirka Kremser <jiri.kremser@gmail.com>

Author: jkremser

README.md

@@ -1,10 +1,10 @@
-## `OTEL <--> KEDA` add-on
+## `OTel <--> KEDA` add-on
 
 [![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/otel-add-on)](https://artifacthub.io/packages/search?repo=otel-add-on)
 
 ### Description
 
-This is an external scaler for KEDA that intergrates with OpenTelemetry (OTEL) collector. The helm chart deploys also OTEL
+This is an external scaler for KEDA that intergrates with OpenTelemetry (OTel) collector. The helm chart deploys also OTel
 collector (using the [upstream helm chart](https://github.com/open-telemetry/opentelemetry-helm-charts)) where one can set up
 filtering so that scaler receives only those metrics that are needed for scaling decisions 
 ([example](https://github.com/kedify/otel-add-on/blob/v0.0.0-1/helmchart/otel-add-on/values.yaml#L133-L147)).
@@ -41,7 +41,7 @@ ScaledObject CR, and it provides a limited subset of features as PromQL.
 - [1] [OTLP format](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc)
 - [2] [OTLP metric receiver](https://github.com/open-telemetry/opentelemetry-collector/blob/d17559b6e89a6f97b6800a6538bbf82430d94678/receiver/otlpreceiver/otlp.go#L101)
 - [3] [processors](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)
-- [4] https://opencensus.io - obsolete, will be replaced by OTEL
+- [4] https://opencensus.io - obsolete, will be replaced by OTel
 - [5] [OpenCensus receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/opencensusreceiver)
 - [6] [Prometheus receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/prometheusreceiver)
 - [7] [OTLP exporter](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/otlpexporter/README.md)
@@ -50,21 +50,21 @@ ScaledObject CR, and it provides a limited subset of features as PromQL.
 
 #### 1. convert and react on metrics from OpenCensus
 
-By specifying an [opencensus receiver](https://github.com/kedify/otel-add-on/blob/v0.0.0-1/helmchart/otel-add-on/values.yaml#L112) in the helm chart values for OTEL collector,
+By specifying an [opencensus receiver](https://github.com/kedify/otel-add-on/blob/v0.0.0-1/helmchart/otel-add-on/values.yaml#L112) in the helm chart values for OTel collector,
 we will get the ability to get those metrics into our scaler.
 
 #### 2. convert and react on metrics from any other upstream receiver
-OTEL collector contains [numerous](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) integrations on the receiver part.
-All of these various receivers open new ways of how to turn metric from OTEL receiver into KEDA scaler. For instance by using 
+OTel collector contains [numerous](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) integrations on the receiver part.
+All of these various receivers open new ways of how to turn metric from OTel receiver into KEDA scaler. For instance by using 
 [sqlqueryreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/sqlqueryreceiver), one can achieve similar goals as with
 [MySQL](https://keda.sh/docs/2.15/scalers/mysql/) or [PostgreSQL](https://keda.sh/docs/2.15/scalers/postgresql/) scalers. 
 By using [githubreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/githubreceiver), one can hook to
 metrics from GitBub, etc.
 
 #### 3. process the metrics before reaching the scaler
-OTEL collector provides [various processors](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)
+OTel collector provides [various processors](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)
 that are being applied on all incoming metrics/spans/traces and one achieve for instance metric [filtering](https://github.com/kedify/otel-add-on/blob/v0.0.0-1/helmchart/otel-add-on/values.yaml#L138-L143)
-this way. So that not all the metric data are passed to scaler's short term memory. This way we can keep the OTEL scaler pretty lightweight.
+this way. So that not all the metric data are passed to scaler's short term memory. This way we can keep the OTel scaler pretty lightweight.
 
 OTTL lang:
 - [spec](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md)
@@ -74,9 +74,9 @@ If the simple metric query is not enough and one requires to combine multiple me
 arithmetic operations on the metrics, there is the [Metrics Generation Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricsgenerationprocessor)
 available as an option
 
-#### 4. OTEL patterns (metric pipelines)
-Basically any scenario described in [OTEL patterns](https://github.com/jpkrohling/opentelemetry-collector-deployment-patterns) or [architecture](https://opentelemetry.io/docs/collector/architecture/)
-should be supported. So no matter how the OTEL collectors are deployed, whether it's a fleet of sidecar containers deployed alongside each workload or
+#### 4. OTel patterns (metric pipelines)
+Basically any scenario described in [OTel patterns](https://github.com/jpkrohling/opentelemetry-collector-deployment-patterns) or [architecture](https://opentelemetry.io/docs/collector/architecture/)
+should be supported. So no matter how the OTel collectors are deployed, whether it's a fleet of sidecar containers deployed alongside each workload or
 some complex pipeline that spans multiple Kubernetes clusters, you will be covered.
 
 ## Installation
@@ -131,9 +131,9 @@ curl -X 'GET' \
 }
 ```
 
-### Configuration for OTEL collector
+### Configuration for OTel collector
 
-This repo has the OTEL collector helm chart as a dependency and some issues in the configuration are guarded
+This repo has the OTel collector helm chart as a dependency and some issues in the configuration are guarded
 by their upstream JSON Schema, but some are not, and it's a good idea to run the validator (especially if it's part
 of a CI/CD pipeline):
 

artifacthub/otel-add-on-scaler/0.0.5/README.md

@@ -0,0 +1 @@
+../../../README.md

artifacthub/otel-add-on-scaler/0.0.5/README.md

@@ -7,8 +7,8 @@ upstream [example](https://docs.dapr.io/getting-started/quickstarts/serviceinvoc
 where the Python app calls the Node app using the service invocation pattern.
 
 Both workloads run `daprd` in a sidecar container, which also exposes metrics. We have modified the `daprd` and its
-mutating webhook (`dapr-sidecar-injector`) to push metrics to our OTEL collector. These metrics use OpenCensus,
-so we need to configure the OTEL collector to accept metrics through the `opencensus` receiver.
+mutating webhook (`dapr-sidecar-injector`) to push metrics to our OTel collector. These metrics use OpenCensus,
+so we need to configure the OTel collector to accept metrics through the `opencensus` receiver.
 
 ## Setup
 
@@ -32,7 +32,7 @@ kubectl set image deploy/dapr-sidecar-injector -n dapr-system dapr-sidecar-injec
 kubectl rollout status -n dapr-system deploy/dapr-sidecar-injector
 ```
 
-Deploy this scaler and OTEL collector that forwards one whitelisted metric:
+Deploy this scaler and OTel collector that forwards one whitelisted metric:
 ```bash
 cat <<VALUES | helm upgrade -i kedify-otel oci://ghcr.io/kedify/charts/otel-add-on --version=v0.0.5 -f -
 opentelemetry-collector:
@@ -118,7 +118,7 @@ operationOverTime: 'rate'
 - The runtime_service_invocation_req_recv_total metric increments each time the `pythonapp` calls `nodeapp`.
 - One of the metric dimensions is the pod identity, meaning each pod exposes these metrics with its label attached.
 - Similar to PromQL, if not all dimensions are specified, multiple metric series will be returned.
-- The OTEL scaler calculates the rate over a one-minute window (default). This should be `1`, as we are calling the API 
+- The OTel scaler calculates the rate over a one-minute window (default). This should be `1`, as we are calling the API 
   every second, so the counter increments by one each second.
 - If multiple metric series are present, the sum is applied to aggregate the values. For example, if there are three
   producer pods, the total will be `3`.

examples/dapr/README.md

@@ -1,6 +1,6 @@
 # Use-case: pull metrics
 
-This use-case demonstrates how OTEL collector can be used as a scraper of another metric endpoints and
+This use-case demonstrates how OTel collector can be used as a scraper of another metric endpoints and
 then forwarding the filtered metrics into OTLP receiver in our scaler.
 
 Prepare helm chart repos:
@@ -30,7 +30,7 @@ Install this addon:
 helm upgrade -i kedify-otel oci://ghcr.io/kedify/charts/otel-add-on --version=v0.0.5 -f scaler-with-collector-pull-values.yaml
 ```
 
-Note the following section in the helm chart values that configures the OTEL collector to scrape targets:
+Note the following section in the helm chart values that configures the OTel collector to scrape targets:
 
 ```yaml
 ...
@@ -65,7 +65,7 @@ Note the following section in the helm chart values that configures the OTEL col
                   target_label: pod_name
 ...
 ```
-We are adding one static target - the metrics from the OTEL collector itself, just for demo purposes, these
+We are adding one static target - the metrics from the OTel collector itself, just for demo purposes, these
 won't be used for scaling decision. And also any pod annotated with `prometheus.io/scrape=true`. One can
 also modify the path where the metrics are exported using `prometheus.io/path=/metrics`.
 

examples/metric-pull/README.md

@@ -1,6 +1,6 @@
 # Use-case: push metrics
 
-This use-case demonstrates how OTEL collector can be used as a scraper of another metric endpoints and
+This use-case demonstrates how OTel collector can be used as a scraper of another metric endpoints and
 then forwarding the filtered metrics into OTLP receiver in our scaler.
 
 Prepare helm chart repos:
@@ -31,22 +31,22 @@ Install this addon:
 helm upgrade -i kedify-otel oci://ghcr.io/kedify/charts/otel-add-on --version=v0.0.5 -f scaler-only-push-values.yaml
 ```
 
-In this scenario, we don't install OTEL collector using the `kedify-otel/otel-add-on` helm chart, because
+In this scenario, we don't install OTel collector using the `kedify-otel/otel-add-on` helm chart, because
 the `opentelemetry-demo` already creates one and it was configured to forward all metrics to our scaler.
-If we wanted to filter the metrics, we would need to deploy another OTEL collector and configure the processor
+If we wanted to filter the metrics, we would need to deploy another OTel collector and configure the processor
 there so that it would look like this:
 
 ```bash
   ┌────────────┐     ┌────────────┐     ┌─────────────┐
   │            │     │            │     │             │
-  │ OTEL col 1 ├────►│ OTEL col 2 ├────►│ this scaler │
+  │ OTel col 1 ├────►│ OTel col 2 ├────►│ this scaler │
   │            │     │ (filtering)│     │             │
   └────────────┘     └────────────┘     └─────────────┘
 
 instead we go w/ simple (w/o filtering):
   ┌────────────┐     ┌─────────────┐
   │            │     │             │
-  │ OTEL col 1 ├────►│ this scaler │
+  │ OTel col 1 ├────►│ this scaler │
   │            │     │             │
   └────────────┘     └─────────────┘
 ```
@@ -98,6 +98,6 @@ k3d cluster delete metric-push
 ```
 
 > [!TIP]
-> In general, when instrumenting the application using OTEL sdk, you can call the 
+> In general, when instrumenting the application using OTel sdk, you can call the 
 > [ForceFlush](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#forceflush-1)
 > to further decrease the delay between a metric change and scaling trigger.