Routing formatting

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

@@ -7,34 +7,32 @@ 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.
 
 {{% notice title="Exercise" style="green" icon="running" %}}
-Open the `gateway.yaml` and add the following configuration:
-
-- **Add the `routing` connector**: In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. This approach also applies to `metrics` and `logs`, allowing them to be routed based on attributes in `resourceMetrics` or `resourceLogs`.
-
-  Add the following below the `receivers:` section and above the `processors:` section:
-
-  ```yaml
-  connectors:
-    routing:
-      default_pipelines: [traces/standard] # 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 
-  ```
-
-- **Configure `file:` exporters**:
-The `routing` connector requires separate targets for routing. 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 
-  ```
+
+**Add the `routing` connector**: In the **Gateway** terminal window edit `gateway.yaml` and add the following below the `receivers:` section and above the `processors:` section:
+
+```yaml
+connectors:
+  routing:
+    default_pipelines: [traces/standard] # 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 
+```
+
+In OpenTelemetry configuration files, `connectors` have their own dedicated section, similar to receivers and processors. 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. 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 
+```
 
 {{% /notice %}}
 

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

@@ -6,54 +6,56 @@ weight: 2
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-- **Add both the `standard` and `security` traces pipelines**:
+**Add both the `standard` and `security` traces pipelines**:
 
-  1. **Standard pipeline**: This pipeline processes all spans that do not match the routing rule. Add it below the existing `traces:` pipeline, keeping the configuration unchanged for now:
+1. **Standard pipeline**: This pipeline processes all spans that do not match the routing rule. Add it below the existing `traces:` pipeline, keeping the configuration unchanged for now:
 
-  ```yaml
-    traces/standard:                # Default pipeline for unmatched spans
-      receivers: 
-      - routing                     # Receive data from the routing connector
-      processors:
-      - memory_limiter              # Limits memory usage
-      - resource/add_mode           # Adds collector mode metadata
-      exporters:
-      - debug                       # Debug exporter
-      - file/traces/standard        # File exporter for unmatched spans
-  ```
-
-  - **Security pipeline**: This pipeline will handle all spans that match the routing rule:
-
-  ```yaml
-      traces/security:                # New Security Traces/Spans Pipeline       
+    ```yaml
+      traces/standard:                # Default pipeline for unmatched spans
         receivers: 
-        - routing                     # Routing Connector, Only receives data from Connector
+        - routing                     # Receive data from the routing connector
         processors:
-        - memory_limiter              # Memory Limiter Processor
+        - memory_limiter              # Limits memory usage
         - resource/add_mode           # Adds collector mode metadata
         exporters:
-        - debug                       # Debug Exporter 
-        - file/traces/security        # File Exporter for spans matching rule
-  ```
+        - debug                       # Debug exporter
+        - file/traces/standard        # File exporter for unmatched spans
+    ```
 
-- **Update the `traces` pipeline to use routing**: To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures all span data is sent through the routing connector for evaluation.
+2. **Security pipeline**: This pipeline will handle all spans that match the routing rule:
 
-  Remove all processors as these are now defined in the `traces/standard` and `traces/security` pipelines.
+    ```yaml
+        traces/security:                # New Security Traces/Spans Pipeline       
+          receivers: 
+          - routing                     # Routing Connector, Only receives data from Connector
+          processors:
+          - memory_limiter              # Memory Limiter Processor
+          - resource/add_mode           # Adds collector mode metadata
+          exporters:
+          - debug                       # Debug Exporter 
+          - file/traces/security        # File Exporter for spans matching rule
+    ```
 
-  ```yaml
-    pipelines:
-      traces:                           # Original traces pipeline
-        receivers: 
-        - otlp                          # OTLP Receiver
-        processors:
-        exporters: 
-        - routing                       # Routing Connector
-  ```
+**Update the `traces` pipeline to use routing**:
+
+1. To enable `routing`, update the original `traces:` pipeline by adding `routing` as an exporter. This ensures all span data is sent through the routing connector for evaluation.
+
+2. Remove all processors as these are now defined in the `traces/standard` and `traces/security` pipelines.
+
+    ```yaml
+      pipelines:
+        traces:                           # Original traces pipeline
+          receivers: 
+          - otlp                          # OTLP Receiver
+          processors:
+          exporters: 
+          - routing                       # Routing Connector
+    ```
 
-{{% notice note %}}
-By excluding the batch processor, spans are written immediately instead of waiting for multiple spans to accumulate before processing. This improves responsiveness, making the workshop run faster and allowing you to see results sooner.
 {{% /notice %}}
 
+{{% notice note %}}
+By excluding the batch processor, spans are written immediately instead of waiting for multiple spans to accumulate before processing. This improves responsiveness, making the workshop run faster and allowing you to see results sooner.
 {{% /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:

content/en/ninja-workshops/10-advanced-otel/8-routing-data/8-3-setup.md

@@ -8,21 +8,21 @@ In this section, we will test the `routing` rule configured for the **Gateway**.
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-- **Start the Gateway**: In the **Gateway** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
+**Start the Gateway**: In the **Gateway** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
 
-  ```sh
-  ../otelbin --config=gateway.yaml
-  ```
+```sh
+../otelbin --config=gateway.yaml
+```
 
-- **Start the Agent**: In the **Agent** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
+**Start the Agent**: In the **Agent** terminal window navigate to the `[WORKSHOP]/8-routing` directory and run:
 
-  ```sh
-  ../otelbin --config=agent.yaml
-  ```
+```sh
+../otelbin --config=agent.yaml
+```
 
-- **Create new security trace**: In the **Tests** terminal window navigate to the `[WORKSHOP]/8-routing` directory.
+**Create new security trace**: In the **Tests** terminal window navigate to the `[WORKSHOP]/8-routing` directory.
 
-  The following JSON contains attributes which will trigger the routing rule. Copy the content from the tab below and save into a file named `security.json`.
+The following JSON contains attributes which will trigger the routing rule. Copy the content from the tab below and save into a file named `security.json`.
 
 {{% tabs %}}
 {{% tab title="security.json" %}}

content/en/ninja-workshops/10-advanced-otel/8-routing-data/8-4-test-routing.md

@@ -6,19 +6,21 @@ weight: 3
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-- **Send a Regular Span**:  
-  1. Locate the **Test** terminal and navigate to the `[WORKSHOP]/8-routing` directory.
-  2. Send a regular span using the `trace.json` file to confirm proper communication.
+**Send a Regular Span**:
 
-  Both the **Agent** and **Gateway** should display debug information, including the span you just sent. The gateway will also generate a new `gateway-traces-standard.out` file, as this is now the designated destination for regular spans.
+1. Locate the **Test** terminal and navigate to the `[WORKSHOP]/8-routing` directory.
+2. Send a regular span using the `trace.json` file to confirm proper communication.
+
+Both the **Agent** and **Gateway** should display debug information, including the span you just sent. The gateway will also generate a new `gateway-traces-standard.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 should contain the `span` sent using the `cURL` command. 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.
 {{% /notice %}}
 
-- **Send a Security Span**:
-  1. Ensure both the **Agent** and **Gateway** are running.
-  2. Send a security span using the `security.json` file to test the gateway’s routing rule.
+**Send a Security Span**:
+
+1. Ensure both the **Agent** and **Gateway** are running.
+2. Send a security span using the `security.json` file to test the gateway’s routing rule.
 
 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.