Routing layout change

Author: rcastley

content/en/ninja-workshops/10-advanced-otel/2-gateway/2-1-access-tokens.md

@@ -17,7 +17,7 @@ When deploying the Splunk Distribution of the OpenTelemetry Collector in host mo
 
 ## Configuring Splunk Access Tokens
 
-To authenticate and send data to Splunk Observability Cloud, you need to configure access tokens properly. 
+To authenticate and send data to Splunk Observability Cloud, you need to configure access tokens properly.
 In OpenTelemetry, authentication is handled via HTTP headers. To pass an access token, use the `headers:` key with the sub-key `X-SF-Token:`. This configuration works in both agent and gateway mode.
 
 Example:
@@ -86,4 +86,3 @@ service:
 ## Conclusion
 
 The `otlphttp` exporter is now the preferred method for sending telemetry data to Splunk Observability Cloud. Properly configuring Splunk Access Tokens ensures secure data transmission, while the Batch Processor helps optimize performance by reducing network overhead. By implementing these best practices, you can efficiently collect and transmit observability data at scale.
-

content/en/ninja-workshops/10-advanced-otel/6-sensitive-data/6-1-test-delete-tag.md

@@ -143,4 +143,5 @@ In this exercise, we will **delete** the `user.account_password`, **update** the
 {{% /tabs %}}
 
 {{% /notice %}}
-Stop the **Agent** and **Gateway** using `Ctrl-C`.
+
+Stop the **Agent** and **Gateway** using `Ctrl-C`.

content/en/ninja-workshops/10-advanced-otel/6-sensitive-data/6-2-test-redaction.md

@@ -60,6 +60,7 @@ In this exercise, we will **redact** the `user.visa` & `user.mastercard` **value
        -> user.visa: Str(4111 1111 1111 1111)
        -> user.amex: Str(3782 822463 10005)
   ```
+
 {{% /tab %}}
 {{% /tabs %}}
 
@@ -176,6 +177,6 @@ Add the Amex card regex to `blocked_values` and restart **Agent** collector.
 '\b3[47][0-9]{2}[\s-]?[0-9]{6}[\s-]?[0-9]{5}\b'
 ```
 
-These are just a few examples of how `attributes` and `redaction` processors can be configured to protect sensitive data. 
+These are just a few examples of how `attributes` and `redaction` processors can be configured to protect sensitive data.
 
 Stop the **Agent** and **Gateway** using `Ctrl-C`.

content/en/ninja-workshops/10-advanced-otel/7-transform-data/7-1-test-transform.md

@@ -7,13 +7,13 @@ weight: 1
 ### Test the Transform
 
 **Run the Log Generator**:
-In the `test` terminal window, navigate to the `[WORKSHOP]/7-transform-data` directory and start the appropriate `log-gen` script for your system. We want to work with structured JSON logs, so add the `-json` flag to the script command. 
+In the `test` terminal window, navigate to the `[WORKSHOP]/7-transform-data` directory and start the appropriate `log-gen` script for your system. We want to work with structured JSON logs, so add the `-json` flag to the script command.
 
 ```sh
 ./log-gen.sh -json
 ```
 
-The script will begin writing lines to a file named `./quotes.log`, while displaying a single line of output in the console. 
+The script will begin writing lines to a file named `./quotes.log`, while displaying a single line of output in the console.
 
  ```txt
  Writing logs to quotes.log. Press Ctrl+C to stop.
@@ -243,4 +243,4 @@ In this exercise, we will **remove the** `com.splunk/source` and `os.type` **met
 
 {{% /notice %}}
 
-Stop the **Agent** and **Gateway** using `Ctrl-C`.
+Stop the **Agent** and **Gateway** using `Ctrl-C`.

content/en/ninja-workshops/10-advanced-otel/8-routing/8-1-connector.md

@@ -4,27 +4,17 @@ linkTitle: 8.1 Routing Configuration
 weight: 1
 ---
 
-In the following exercise, you will configure the `routing connector` in the `gateway.yaml` file. This setup will enable the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By doing so, you can process and handle traces differently depending on their attributes.
+In the following exercise, you will configure the `routing` connector in the `gateway.yaml` file. This setup will enable the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By doing so, you can process and handle traces differently depending on their attributes.
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 Open the `gateway.yaml` and add the following configuration:
 
-- **Add the `connectors:` section**:  
-In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. In the `gateway.yaml` file, insert the `connectors:` section below the `receivers` section and above the `processors` section.
-
-  ```yaml
-  connectors:       # Section to configure connectors
-
-  processors:
-
-  ```
-
-- **Add the `routing` connector**:  
-  In this configuration, spans will be routed if the `deployment.environment` resource attribute matches `"security_applications"`.
-
-  This same approach can also be applied to `metrics` and `logs`, allowing you to route them based on attributes in `resourceMetrics` or `resourceLogs` similarly. Add the following under the `connectors:` section:
+- **Add the `routing` connector**: In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors in the `gateway.yaml` file. This same approach can also be applied to `metrics` and `logs`, allowing you to route them based on attributes in `resourceMetrics` or `resourceLogs` similarly.
+  
+  Add the following below the `receivers:` section and above the `processors:` section:
 
   ```yaml
+  connectors:
     routing:
       default_pipelines: [traces/standard] # Default pipeline to use if no matching rule
       error_mode: ignore                   # Ignore errors in the routing 
@@ -35,7 +25,7 @@ In OpenTelemetry configuration files, `connectors` have their own dedicated sect
   ```
 
 - **Configure two `file:` Exporters**:
-The `routing connector` requires different targets for routing. To achieve this, update the default `file/traces:` exporter and name it `file/traces/default:` and add a second file exporter called `file/traces/security:`. This will allow the routing connector to direct data to the appropriate target based on the rules you define.
+The `routing` connector requires different targets for routing. Add a second and third file exporter called `file/traces/security:` and `file/traces/standard:` respectively. This will allow the routing connector to direct data to the appropriate target based on the rules you define:
 
   ```yaml
     file/traces/standard:              # Exporter Type/Name (For regular traces)
@@ -50,4 +40,4 @@ The `routing connector` requires different targets for routing. To achieve this,
 
 {{% /notice %}}
 
-With the routing configuration complete, next we configure the pipelines to use the routing rules.
+With the `routing` configuration complete, next we configure the `pipelines` to use the routing rules.

content/en/ninja-workshops/10-advanced-otel/8-routing/8-2-pipelines.md

@@ -5,9 +5,10 @@ weight: 2
 ---
 
 {{% notice title="Exercise" style="green" icon="running" %}}
+
 - **Add both the `standard` and `security` traces pipelines**:
 
-  1. **Standard** pipeline: This pipeline will handle all spans that do not match the routing rule. Add it below the regular `traces:` pipeline, and leave the configuration unchanged for now.
+  1. **Standard pipeline**: This pipeline will handle all spans that do not match the routing rule. Add it below the regular `traces:` pipeline, and leave the configuration unchanged for now.
 
   ```yaml
     pipelines:
@@ -22,7 +23,7 @@ weight: 2
         - file/traces/standard        # File Exporter for spans NOT matching rule
   ```
 
-  - **Target pipeline**: This pipepline will handle all spans that match the routing rule.
+  - **Target pipeline**: This pipeline will handle all spans that match the routing rule.
 
   ```yaml
     pipelines:
@@ -37,7 +38,7 @@ weight: 2
         - file/traces/security        # File Exporter for spans matching rule
   ```
 
-- **Update the `traces` pipeline to handle routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures that all span data is sent through the routing connector for evaluation.
+- **Update the `traces` pipeline to use routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures that all span data is sent through the routing connector for evaluation.
 
 For clarity, we are removing the `debug` exporter from this pipeline, so that debug output is only shown from the new exporters behind the routing connector.