Minor edits

Author: rcastley

content/en/conf/1-advanced-collector/6-routing-data/6-1-connector.md

@@ -4,37 +4,36 @@ linkTitle: 6.1 Routing Configuration
 weight: 1
 ---
 
-In this exercise, you will configure the **Routing Connector** in the `gateway.yaml` file. This setup enables the **Gateway** to route traces based on the `deployment.environment` attribute in the spans you send. By implementing this, you can process and handle traces differently depending on their attributes.
+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).
 
 {{% 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`:
+
+```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 
+```
+
 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:
 
 ```yaml
-connectors: 
   routing:
-    default_pipelines: [traces/standard] # Default pipeline if no rule matches
+    default_pipelines: [traces/route1]   # 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/security]     # Target pipeline 
-```
-
-The rules above apply to traces, but this approach also applies to `metrics` and `logs`, allowing them to be routed based on attributes in `resourceMetrics` or `resourceLogs`.
-
-**Configure `file:` exporters**: The `routing` connector requires separate targets for routing. In the `exporters:` section, add two file exporters, `file/traces/security` and `file/traces/standard`, to ensure data is directed correctly.
-
-```yaml
-  file/traces/standard:                    # Exporter for regular traces
-    path: "./gateway-traces-standard.out"  # Path for saving trace data
-    append: false                          # Overwrite the file each time
-  file/traces/security:                    # Exporter for security traces
-    path: "./gateway-traces-security.out"  # Path for saving trace data
-    append: false                          # Overwrite the file each time 
+        pipelines: [traces/route2]       # Target pipeline 
 ```
 
 {{% /notice %}}

content/en/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md

@@ -8,26 +8,24 @@ weight: 2
 
 **Update the `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.
-2. Remove all processors and replace it with an empty array (`[]`). These are now defined in the `traces/standard` and `traces/security` pipelines.
+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.
 
     ```yaml
-      pipelines:
-        traces:                           # Original traces pipeline
-          receivers: 
-          - otlp                          # OTLP Receiver
-          processors: []
-          exporters: 
-          - routing                       # Routing Connector
+    traces:                       # Traces pipeline
+      receivers:
+      - otlp                      # OTLP receiver
+      processors: []              # Processors for traces
+      exporters:
+      - routing
     ```
 
-**Add both the `standard` and `security` traces pipelines**:
+**Add both the `route1` and `route2` traces pipelines**:
 
-1. **Configure the Security pipeline**: This pipeline will handle all spans that match the routing rule for `security`.
+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:
 
     ```yaml
-        traces/security:              # New Security Traces/Spans Pipeline
+        traces/route1:               # Default pipeline for unmatched spans
           receivers: 
           - routing                   # Receive data from the routing connector
           processors:
@@ -36,7 +34,7 @@ This uses `routing` as its receiver. Place it below the existing `traces:` pipel
           - batch
           exporters:
           - debug                     # Debug Exporter 
-          - file/traces/security      # File Exporter for spans matching rule
+          - file/traces/route1      # File Exporter for unmatched spans 
     ```
 
 2. **Add the Standard pipeline**: This pipeline processes all spans that do not match the routing rule.
@@ -57,6 +55,7 @@ This pipeline is also using `routing` as its receiver. Add this below the `trace
 
 {{% /notice %}}
 
+<!--
 Validate the agent configuration using **[otelbin.io](https://www.otelbin.io/)**. For reference, the `traces:` section of your pipelines will look similar to this:
 
 ```mermaid
@@ -84,27 +83,28 @@ graph LR
     subgraph " "
     direction LR
       subgraph subID1[**Traces**]
-      REC1 --> ROUTE1
+      REC1 -- > ROUTE1
       end
       subgraph subID2[**Traces/standard**]
-      ROUTE1 --> ROUTE2
-      ROUTE2 --> PRO1
-      PRO1 --> PRO3
-      PRO3 --> PRO5
-      PRO5 --> EXP1
-      PRO5 --> EXP2
+      ROUTE1 -- > ROUTE2
+      ROUTE2 -- > PRO1
+      PRO1 -- > PRO3
+      PRO3 -- > PRO5
+      PRO5 -- > EXP1
+      PRO5 -- > EXP2
       end
       subgraph subID3[**Traces/security**]
-      ROUTE1 --> ROUTE3
-      ROUTE3 --> PRO2
-      PRO2 --> PRO4
-      PRO4 --> PRO6
-      PRO6 --> EXP3
-      PRO6 --> EXP4
+      ROUTE1 -- > ROUTE3
+      ROUTE3 -- > PRO2
+      PRO2 -- > PRO4
+      PRO4 -- > PRO6
+      PRO6 -- > EXP3
+      PRO6 -- > EXP4
       end
     end
 classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
 classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
 classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
 classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
 ```
+-->

content/en/conf/1-advanced-collector/6-routing-data/_index.md

@@ -12,7 +12,7 @@ For example, you might want to send *production* data to one exporter while dire
 {{% notice title="Exercise" style="green" icon="running" %}}
 
 > [!IMPORTANT]
-> **Change _ALL_ terminal windows to the `[WORKSHOP]/6-routing-data` directory and run the `clear` command.**
+> **Change _ALL_ terminal windows to the `6-routing-data` directory and run the `clear` command.**
 
 Copy `*.yaml` from the `5-transform-data` directory into `6-routing-data`. Your updated directory structure will now look like this: