updateted the text and flow of section 6

hagen-p · hagen-p · commit 3e4bdd2c77cf · 2025-07-11T15:28:31.000+02:00
diff --git a/content/en/conf/1-advanced-collector/6-routing-data/6-1-connector.md b/content/en/conf/1-advanced-collector/6-routing-data/6-1-connector.md
@@ -4,38 +4,38 @@ linkTitle: 6.1 Routing Configuration
 weight: 1
 ---
 
-In this exercise, you will configure the **Routing Connector** in the `gateway.yaml`. While the Routing Connector can route metrics, traces, and logs based on any attributes, we will focus exclusively on trace routing.
-
-This setup enables the Gateway to route traces based on the `deployment.environment` attribute (though any span attribute can be used).
+In this exercise, you will configure the **Routing Connector** in the `gateway.yaml`. The Routing Connector can route metrics, traces, and logs based on any attributes, we will focus exclusively on trace routing based on the `deployment.environment` attribute (though any span/log/metirc attribute can be used).
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-**Configure `file` exporters**: The `routing` connector requires separate targets for routing. Create two new file exporters, `file/traces/route1` and `file/traces/route2`, to ensure data is directed correctly in the `exporters` section of the `gateway.yaml`:
+**Add new `file` exporters**: The `routing` connector requires different targets for routing. Create two new file exporters, `file/traces/route1-regular` and `file/traces/route2-security`, to ensure data is directed correctly in the `exporters` section of the `gateway.yaml`:
 
 ```yaml
-  file/traces/route1:                    # Exporter for regular traces
-    path: "./gateway-traces-route1.out"  # Path for saving trace data
-    append: false                        # Overwrite the file each time
-  file/traces/route2:                    # Exporter for security traces
-    path: "./gateway-traces-route2.out"  # Path for saving trace data
-    append: false                        # Overwrite the file each time 
+  file/traces/route1-regular:                     # Exporter for regular traces
+    path: "./gateway-traces-route1-regular.out"   # Path for saving trace data
+    append: false                                 # Overwrite the file each time
+  file/traces/route2-security:                    # Exporter for security traces
+    path: "./gateway-traces-route2-security.out"  # Path for saving trace data
+    append: false                                 # Overwrite the file each time 
 ```
 
-In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors.
+**Enable Routing** by adding the `routing` connector. In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors.
 
-**Add the `routing` connector**:
-In the **Gateway terminal** window, edit `gateway.yaml` and uncomment the `#connectors:` section. Then, add the following below the `connectors:` section:
+In the **Gateway terminal** window, edit `gateway.yaml` and  find and uncomment the `#connectors:` section. Then, add the following below the `connectors:` section:
 
 ```yaml
   routing:
-    default_pipelines: [traces/route1]   # Default pipeline if no rule matches
-    error_mode: ignore                   # Ignore errors in routing
-    table:                               # Define routing rules
+    default_pipelines: [traces/route1-regular]  # Default pipeline if no rule matches
+    error_mode: ignore                          # Ignore errors in routing
+    table:                                      # Define routing rules
       # Routes spans to a target pipeline if the resourceSpan attribute matches the rule
       - statement: route() where attributes["deployment.environment"] == "security-applications"
-        pipelines: [traces/route2]       # Target pipeline 
+        pipelines: [traces/route2-security]     # Security target pipeline 
 ```
 
 {{% /notice %}}
 
+The default pipeline in the configuration file  works at a Catch all. It will be the  routing target for any data (spans in our case) that does match a rule in the routing rules table, In this table you find the pipeline that is the target for any span that matches the following rule: "[deployment.environment"] == "security-applications"
+
+
 With the `routing` configuration complete, the next step is to configure the `pipelines` to apply these routing rules.
diff --git a/content/en/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md b/content/en/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md
@@ -6,9 +6,9 @@ weight: 2
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-**Update the `traces` pipeline to use routing**:
+**Update the original `traces` pipeline to use routing**:
 
-1. To enable `routing`, update the original `traces:` pipeline by using `routing` as the only exporter. This ensures all span data is sent through the **Routing Connector** for evaluation. Also, remove **all** processors and replace it with an empty array (`[]`) as these are now defined in the `traces/route1` and `traces/route2` pipelines.
+1. To enable `routing`, update the original `traces:` pipeline to use `routing` as the only exporter. This ensures all span data is sent through the **Routing Connector** for evaluation and then onwards to connected pipelines. Also, remove **all** processors and replace it with an empty array (`[]`) as this will now behandeld in the `traces/route1-regular` and `traces/route2-security` pipelines, allowing for custom behaviour for each route.  Your `traces:` configuration should look like this:
 
     ```yaml
     traces:                       # Traces pipeline
@@ -19,38 +19,37 @@ weight: 2
       - routing
     ```
 
-**Add both the `route1` and `route2` traces pipelines**:
+**Add both the `route1-regular` and `route2-security` traces pipelines** below the existing `traces:` pipeline:
 
-1. **Configure Route1 pipeline**: This pipeline will handle all spans that match the routing rule for `route1`.
-This uses `routing` as its receiver. Place it below the existing `traces:` pipeline:
+1. **Configure Route1-regular pipeline**: This pipeline will handle all spans that have  **no match** in the routing table in the connector.
+Notice this uses `routing` as its only receiver and will recieve data thought its `connection` from the original traces pipeline. 
 
     ```yaml
-        traces/route1:               # Default pipeline for unmatched spans
+        traces/route1-regular:         # Default pipeline for unmatched spans
           receivers: 
-          - routing                   # Receive data from the routing connector
+          - routing                    # Receive data from the routing connector
           processors:
-          - memory_limiter            # Memory Limiter Processor
-          - resource/add_mode         # Adds collector mode metadata
+          - memory_limiter             # Memory Limiter Processor
+          - resource/add_mode          # Adds collector mode metadata
           - batch
           exporters:
-          - debug                     # Debug Exporter 
-          - file/traces/route1      # File Exporter for unmatched spans 
+          - debug                      # Debug Exporter 
+          - file/traces/route1-regular # File Exporter for unmatched spans 
     ```
 
-2. **Add the Standard pipeline**: This pipeline processes all spans that do not match the routing rule.
-This pipeline is also using `routing` as its receiver. Add this below the `traces/security` one:
+2. **Add the route2-security pipeline**: This pipeline processes all spans that do match our rule "[deployment.environment"] == "security-applications" in the  the routing rule. This pipeline is also using `routing` as its receiver. Add this  pipline below the `traces/route1-regular` one.
 
     ```yaml
-        traces/standard:              # Default pipeline for unmatched spans
+        traces/route2-security:         # Default pipeline for unmatched spans
           receivers: 
-          - routing                   # Receive data from the routing connector
+          - routing                     # Receive data from the routing connector
           processors:
-          - memory_limiter            # Memory Limiter Processor
-          - resource/add_mode         # Adds collector mode metadata
+          - memory_limiter              # Memory Limiter Processor
+          - resource/add_mode           # Adds collector mode metadata
           - batch
           exporters:
-          - debug                     # Debug exporter
-          - file/traces/standard      # File exporter for unmatched spans
+          - debug                       # Debug exporter
+          - file/traces/route2-security # File exporter for unmatched spans
     ```
 
 {{% /notice %}}
diff --git a/content/en/conf/1-advanced-collector/6-routing-data/6-3-test-routing.md b/content/en/conf/1-advanced-collector/6-routing-data/6-3-test-routing.md
@@ -6,7 +6,7 @@ weight: 3
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-In this section, we will test the `routing` rule configured for the **Gateway**. The expected result is that the`span` generated by the `loadgen` will be sent to the `gateway-traces-security.out` file.
+In this section, we will test the `routing` rule configured for the **Gateway**. The expected result is that the`span` generated by the `loadgen`  that match the “[deployment.environment”] == “security-applications” rule will be sent to the `gateway-traces-route2-security.out` file.
 
 **Start the Gateway**: In your **Gateway terminal** window start the **Gateway**.
 
@@ -26,10 +26,10 @@ In this section, we will test the `routing` rule configured for the **Gateway**.
 ../loadgen -count 1
 ```
 
-Both the **Agent** and **Gateway** will display debug information. The gateway will also generate a new `gateway-traces-standard.out` file, as this is now the designated destination for regular spans.
+Both the **Agent** and **Gateway** will display debug information. The gateway will also generate a new `gateway-traces-route1-regular.out` file, as this is now the designated destination for regular spans.
 
 {{% notice title="Tip" style="primary" icon="lightbulb" %}}
-If you check `gateway-traces-standard.out`, it will contain the `span` sent by `loadgen`. You will also see an empty `gateway-traces-security.out` file, as the routing configuration creates output files immediately, even if no matching spans have been processed yet.
+If you check `gateway-traces-route1-regular.out`, it will contain the `span` sent by `loadgen`. You will also see an empty `gateway-traces-route2-security..out` file, as the routing configuration creates output files immediately, even if no matching spans have been processed yet.
 {{% /notice %}}
 
 **Send a Security Span**: In the **Loadgen terminal** window send a security span using the `security` flag:
@@ -38,14 +38,14 @@ If you check `gateway-traces-standard.out`, it will contain the `span` sent by `
 ../loadgen -security -count 1
 ```
 
-Again, both the **Agent** and **Gateway** should display debug information, including the span you just sent. This time, the **Gateway** will write a line to the `gateway-traces-security.out` file, which is designated for spans where the `deployment.environment` resource attribute matches `"security-applications"`.
-The `gateway-traces-standard.out` should be unchanged.
+Again, both the **Agent** and **Gateway** should display debug information, including the span you just sent. This time, the **Gateway** will write a line to the `gateway-traces-route2-security.out` file, which is designated for spans where the `deployment.environment` resource attribute matches `"security-applications"`.
+The `gateway-traces-route1-regular.out` should be unchanged.
 
 {{% tabs %}}
 {{% tab title="Validate resource attribute matches" %}}
 
 ```bash
-jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-security.out
+jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-route2-security.out
 ```
 
 {{% /tabs %}}
@@ -69,9 +69,9 @@ You can repeat this scenario multiple times, and each trace will be written to i
 
 In this section, we successfully tested the routing connector in the gateway by sending different spans and verifying their destinations.
 
-- **Regular spans** were correctly routed to `gateway-traces-standard.out`, confirming that spans without a matching `deployment.environment` attribute follow the default pipeline.
+- **Regular spans** were correctly routed to `gateway-traces-route1-regular.out`, confirming that spans without a matching `deployment.environment` attribute follow the default pipeline.
 
-- **Security-related spans** were routed to `gateway-traces-security.out`, demonstrating that the routing rule based on `"deployment.environment": "security-applications"` works as expected.
+- **Security-related spans** were routed to `gateway-traces-route2-security.out`, demonstrating that the routing rule based on `"deployment.environment": "security-applications"` works as expected.
 
 By inspecting the output files, we confirmed that the OpenTelemetry Collector *correctly evaluates span attributes and routes them to the appropriate destinations*. This validates that routing rules can effectively separate and direct telemetry data for different use cases.
 
diff --git a/content/en/conf/1-advanced-collector/6-routing-data/_index.md b/content/en/conf/1-advanced-collector/6-routing-data/_index.md
@@ -5,7 +5,7 @@ time: 10 minutes
 weight: 8
 ---
 
-The [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) in OpenTelemetry is a powerful feature that allows you to direct data (`traces`, `metrics`, or `logs`) to different pipelines based on specific criteria. This is especially useful in scenarios where you want to apply different processing or exporting logic to subsets of your telemetry data.
+The [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) in OpenTelemetry is a powerful feature that allows you to direct data (`traces`, `metrics`, or `logs`) to different pipelines/destinations based on specific criteria. This is especially useful in scenarios where you want to apply different processing or exporting logic to subsets of your telemetry data.
 
 For example, you might want to send *production* data to one exporter while directing *test* or *development* data to another. Similarly, you could route certain spans based on their attributes, such as service name, environment, or span name, to apply custom processing or storage logic.
 
