Refactored HPA workshop for latest collector version

Author: rcastley

content/en/ninja-workshops/2-hpa/1-deploy-otel.md

@@ -50,7 +50,6 @@ helm install splunk-otel-collector --version {{< otel-version >}} \
 --set="splunkObservability.realm=$REALM" \
 --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
 --set="clusterName=$INSTANCE-k3s-cluster" \
---set="logsEngine=otel" \
 --set="splunkPlatform.endpoint=$HEC_URL" \
 --set="splunkPlatform.token=$HEC_TOKEN" \
 --set="splunkPlatform.index=splunk4rookies-workshop" \
@@ -78,25 +77,16 @@ kubectl get pods
 {{% tab title="kubectl get pods Output" %}}
 
 ``` text
-NAME                                                          READY   STATUS    RESTARTS   AGE
-splunk-otel-collector-agent-pvstb                             2/2     Running   0          19s
-splunk-otel-collector-k8s-cluster-receiver-6c454894f8-mqs8n   1/1     Running   0          19s
+NAME                                                         READY   STATUS    RESTARTS   AGE
+splunk-otel-collector-agent-ks9jn                            1/1     Running   0          27s
+splunk-otel-collector-agent-lqs4j                            0/1     Running   0          27s
+splunk-otel-collector-agent-zsqbt                            1/1     Running   0          27s
+splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj   0/1     Running   0          27s
 ```
 
 {{% /tab %}}
 {{< /tabs >}}
 
-<!--
-{{% notice title="Note" style="info" %}}
-
-If you are using the Kubernetes Integration setup from the Data Management page from the O11y UI, you find that the guide will use
-`--generate-name splunk-otel-collector-chart/splunk-otel-collector` instead of just `splunk-otel-collector-chart/splunk-otel-collector` as we do in the above example.
-
-This will generate a unique name/label for the collector install and Pods by adding a unique number at the end of the object name, allowing you to install multiple collectors in your Kubernetes environment with different configurations.
-
-Just make sure you use the correct label that is generated by the Helm chart if you wish to use the `helm` and `kubectl` commands from this workshop on an install done with the `--generate-name` option.
-{{% /notice %}}
--->
 Use the label set by the `helm` install to tail logs (You will need to press `ctrl + c` to exit).
 
 {{< tabs >}}

content/en/ninja-workshops/2-hpa/2-k8s-namespaces-dns.md

@@ -0,0 +1,41 @@
+---
+title: K8s Namespaces and DNS
+linkTitle: 2. K8s Namespaces and DNS
+weight: 2
+---
+
+## 1. Namespaces in Kubernetes
+
+Most of our customers will make use of some kind of private or public cloud service to run Kubernetes. They often choose to have only a few large Kubernetes clusters as it is easier to manage centrally.
+
+Namespaces are a way to organize these large Kubernetes clusters into virtual sub-clusters. This can be helpful when different teams or projects share a Kubernetes cluster as this will give them the easy ability to just see and work with their resources.
+
+Any number of namespaces are supported within a cluster, each logically separated from others but with the ability to communicate with each other. Components are only **visible** when selecting a namespace or when adding the `--all-namespaces` flag to `kubectl` instead of allowing you to view just the components relevant to your project by selecting your namespace.
+
+Most customers will want to install the applications into a separate namespace.  This workshop will follow that best practice.
+
+## 2.  DNS and Services in Kubernetes
+
+The Domain Name System (DNS) is a mechanism for linking various sorts of information with easy-to-remember names, such as IP addresses. Using a DNS system to translate request names into IP addresses makes it easy for end-users to reach their target domain name effortlessly.
+
+Most Kubernetes clusters include an internal DNS service configured by default to offer a lightweight approach for service discovery. Even when Pods and Services are created, deleted, or shifted between nodes, built-in service discovery simplifies applications to identify and communicate with services on the Kubernetes clusters.
+
+In short, the DNS system for Kubernetes will create a DNS entry for each Pod and Service. In general, a Pod has the following DNS resolution:
+
+``` text
+pod-name.my-namespace.pod.cluster-domain.example
+```
+
+For example, if a Pod in the `default` namespace has the Pod name `my_pod`, and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
+
+``` text
+my_pod.default.pod.cluster.local
+```
+
+Any Pods exposed by a Service have the following DNS resolution available:
+
+``` text
+my_pod.service-name.my-namespace.svc.cluster-domain.example
+```
+
+More information can be found here: [**DNS for Service and Pods**](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)

content/en/ninja-workshops/2-hpa/3-apache-otel-receiver.md

@@ -0,0 +1,105 @@
+---
+title: Apache OTel Receiver
+linkTitle: 3. Apache OTel Receiver
+weight: 3
+---
+
+## 1. Review OTel receiver for PHP/Apache
+
+Inspect the YAML file `~/workshop/k3s/otel-apache.yaml` and validate the contents using the following command:
+
+``` bash
+cat ~/workshop/k3s/otel-apache.yaml
+```
+
+This file contains the configuration for the OpenTelemetry agent to monitor the PHP/Apache deployment.
+
+```yaml
+agent:
+  config:
+    receivers:
+      receiver_creator:
+        receivers:
+          apache:
+            rule: type == "port" && pod.name matches "apache" && port == 80
+            config:
+              endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto
+```
+
+## 2.  Observation Rules in the OpenTelemetry config
+
+The above file contains an observation rule for Apache using the OTel `receiver_creator`. This receiver can instantiate other receivers at runtime based on whether observed endpoints match a configured rule.
+
+The configured rules will be evaluated for each endpoint discovered. If the rule evaluates to true, then the receiver for that rule will be started as configured against the matched endpoint.
+
+In the file above we tell the OpenTelemetry agent to look for Pods that match the name `apache` and have port `80` open. Once found, the agent will configure an Apache receiver to read Apache metrics from the configured URL. Note, the K8s DNS-based URL in the above YAML for the service.
+
+To use the Apache configuration, you can upgrade the existing Splunk OpenTelemetry Collector Helm chart to use the `otel-apache.yaml` file with the following command:
+
+{{< tabs >}}
+{{% tab title="Helm Upgrade" %}}
+
+``` bash
+helm upgrade splunk-otel-collector \
+--set="splunkObservability.realm=$REALM" \
+--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+--set="clusterName=$INSTANCE-k3s-cluster" \
+--set="splunkPlatform.endpoint=$HEC_URL" \
+--set="splunkPlatform.token=$HEC_TOKEN" \
+--set="splunkPlatform.index=splunk4rookies-workshop" \
+splunk-otel-collector-chart/splunk-otel-collector \
+-f ~/workshop/k3s/otel-collector.yaml \
+-f ~/workshop/k3s/otel-apache.yaml
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% notice title="NOTE" style="info" %}}
+The **REVISION** number of the deployment has changed, which is a helpful way to keep track of your changes.
+
+``` text
+Release "splunk-otel-collector" has been upgraded. Happy Helming!
+NAME: splunk-otel-collector
+LAST DEPLOYED: Mon Nov  4 14:56:25 2024
+NAMESPACE: default
+STATUS: deployed
+REVISION: 2
+TEST SUITE: None
+NOTES:
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-workshop.splunkcloud.com:443/services/collector/event".
+
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.
+```
+
+{{% /notice %}}
+
+## 3. Kubernetes ConfigMaps
+
+A ConfigMap is an object in Kubernetes consisting of key-value pairs that can be injected into your application. With a ConfigMap, you can separate configuration from your Pods.
+
+Using ConfigMap, you can prevent hardcoding configuration data. ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information.
+
+The OpenTelemetry collector/agent uses ConfigMaps to store the configuration of the agent and the K8s Cluster receiver. You can/will always verify the current configuration of an agent after a change by running the following commands:
+
+``` bash
+kubectl get cm
+```
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+How many ConfigMaps are used by the collector?
+{{% /notice %}}
+
+When you have a list of ConfigMaps from the namespace, select the one for the `otel-agent` and view it with the following command:
+
+``` bash
+kubectl get cm splunk-otel-collector-otel-agent -o yaml
+```
+
+{{% notice title="NOTE" style="info" %}}
+The option `-o yaml` will output the content of the ConfigMap in a readable YAML format.
+{{% /notice %}}
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+Is the configuration from `otel-apache.yaml` visible in the ConfigMap for the collector agent?
+{{% /notice %}}