Section 2 updates

Author: rcastley

content/en/conf/1-advanced-collector/1-agent-gateway/1-2-send-metrics.md

@@ -93,4 +93,7 @@ jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.ti
 {{% /tab %}}
 {{% /tabs %}}
 
+> [!IMPORTANT]
+> Stop the **Agent** and the **Gateway** processes by pressing `Ctrl-C` in their respective terminals.
+
 {{% /notice %}}

content/en/conf/1-advanced-collector/2-building-resilience/2-1-configuration.md

@@ -10,7 +10,18 @@ While these components do not process telemetry data directly, they provide valu
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-**Update the `agent.yaml`**: In the **Agent terminal** window, add the `file_storage` extension and name it `checkpoint`:
+> [!IMPORTANT]
+> **Change _ALL_ terminal windows to the `2-building-resilience` directory and run the `clear` command.**
+
+Your directory structure will look like this:
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+**Update the `agent.yaml`**: In the **Agent terminal** window, add the `file_storage` extension under the existing `health_check` extension:
 
 ```yaml
   file_storage/checkpoint:             # Extension Type/Name
@@ -24,11 +35,9 @@ While these components do not process telemetry data directly, they provide valu
       max_transaction_size: 65536      # Max. size limit before compaction occurs
 ```
 
-**Add `file_storage` to existing `otlphttp` exporter**: Modify the `otlphttp:` exporter to configure retry and queuing mechanisms, ensuring data is retained and resent if failures occur:
+**Add `file_storage` to the exporter**: Modify the `otlphttp` exporter to configure retry and queuing mechanisms, ensuring data is retained and resent if failures occur. Add the following under the `endpoint: "http://localhost:5318"` and make sure the indentation matches `endpoint`:
 
 ```yaml
-  otlphttp: 
-    endpoint: "http://localhost:5318"
     retry_on_failure:
       enabled: true                    # Enable retry on failure
     sending_queue:                     # 
@@ -38,7 +47,7 @@ While these components do not process telemetry data directly, they provide valu
       storage: file_storage/checkpoint # File storage extension
 ```
 
-**Update the `services` section**: Add the `file_storage/checkpoint` extension to the existing `extensions:` section. This will cause the extension to be enabled:
+**Update the `services` section**: Add the `file_storage/checkpoint` extension to the existing `extensions:` section and the configuration needs to look like this:
 
 ```yaml
 service:
@@ -47,18 +56,18 @@ service:
   - file_storage/checkpoint            # Enabled extensions for this collector
 ```
 
-**Update the `metrics` pipeline**: For this exercise we are going to comment out the `hostmetrics` receiver from the Metric pipeline to reduce debug and log noise:
+**Update the `metrics` pipeline**: For this exercise we are going to comment out the `hostmetrics` receiver from the Metric pipeline to reduce debug and log noise, again the configuration needs to look like this:
 
 ```yaml
     metrics:
       receivers:
+      # - hostmetrics                    # Hostmetric reciever (cpu only)
       - otlp
-      # - hostmetrics                  # Hostmetrics Receiver
 ```
 
 {{% /notice %}}
 
-Validate the **Agent** configuration using **[otelbin.io](https://www.otelbin.io/)**. For reference, the `metrics:` section of your pipelines will look similar to this:
+<!-- Validate the **Agent** configuration using **[otelbin.io](https://www.otelbin.io/)**. For reference, the `metrics:` section of your pipelines will look similar to this:
 
 ```mermaid
 %%{init:{"fontFamily":"monospace"}}%%
@@ -76,16 +85,16 @@ graph LR
     subgraph " "
       subgraph subID1[**Metrics**]
       direction LR
-      REC1 --> PRO1
-      PRO1 --> PRO2
-      PRO2 --> PRO3
-      PRO3 --> PRO4
-      PRO4 --> EXP1
-      PRO4 --> EXP2
+      REC1 -- > PRO1
+      PRO1 -- > PRO2
+      PRO2 -- > PRO3
+      PRO3 -- > PRO4
+      PRO4 -- > EXP1
+      PRO4 -- > EXP2
       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-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
-```
+``` -->

content/en/conf/1-advanced-collector/2-building-resilience/2-2-test-environment.md

@@ -8,26 +8,25 @@ Next, we will configure our environment to be ready for testing the **File Stora
 
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-**Start the Gateway**: In the **Gateway terminal** window navigate to the `[WORKSHOP]/4-resilience` directory and run:
+**Start the Gateway**: In the **Gateway terminal** window run:
 
 ```bash { title="Start the Gateway" }
 ../otelcol --config=gateway.yaml
 ```
 
-**Start the Agent**: In the **Agent terminal** window navigate to the `[WORKSHOP]/4-resilience` directory and run:
+**Start the Agent**: In the **Agent terminal** window run:
 
 ```bash { title="Start the Agent" }
 ../otelcol --config=agent.yaml
 ```
 
-**Send five test spans**: In the **Loadgen terminal** window navigate to the `[WORKSHOP]/4-resilience` directory and run:
+**Send five test spans**: In the **Loadgen terminal** window run:
 
 ```bash { title="Start Load Generator" }
 ../loadgen -count 5
 ```
 
 Both the **Agent** and **Gateway** should display debug logs, and the **Gateway** should create a `./gateway-traces.out` file.
 
-{{% /notice %}}
-
 If everything functions correctly, we can proceed with testing system resilience.
+{{% /notice %}}

content/en/conf/1-advanced-collector/2-building-resilience/2-3-failure.md

@@ -6,18 +6,12 @@ weight: 3
 
 To assess the **Agent's** resilience, we'll simulate a temporary **Gateway** outage and observe how the **Agent** handles it:
 
-**Summary**:
-
-1. **Send Traces to the Agent** – Generate traffic by sending traces to the **Agent**.
-2. **Stop the Gateway** – This will trigger the **Agent** to enter retry mode.
-3. **Restart the Gateway** – The **Agent** will recover traces from its persistent queue and forward them successfully. Without the persistent queue, these traces would have been lost permanently.
-
 {{% notice title="Exercise" style="green" icon="running" %}}
 
-**Simulate a network failure**: In the **Gateway terminal** stop the **Gateway** with `Ctrl-C` and wait until the gateway console shows that it has stopped:
+**Simulate a network failure**: In the **Gateway terminal** stop the **Gateway** with `Ctrl-C` and wait until the gateway console shows that it has stopped. The **Agent** will continue running, but it will not be able to send data to the gateway. The output in the **Gateway terminal** should look similar to this:
 
 ```text
-2025-01-28T13:24:32.785+0100  info  service@v0.120.0/service.go:309  Shutdown complete.
+2025-07-09T10:22:37.941Z        info    service@v0.126.0/service.go:345 Shutdown complete.      {"resource": {}}
 ```
 
 **Send traces**: In the **Loadgen terminal** window send five more traces using the `loadgen`.
@@ -31,16 +25,13 @@ Notice that the agent’s retry mechanism is activated as it continuously attemp
 **Stop the Agent**: In the **Agent terminal** window, use `Ctrl-C` to stop the agent. Wait until the agent’s console confirms it has stopped:
 
 ```text
-2025-01-28T14:40:28.702+0100  info  extensions/extensions.go:66  Stopping extensions...
-2025-01-28T14:40:28.702+0100  info  [email protected]/service.go:309  Shutdown complete.
+2025-07-09T10:25:59.344Z        info    [email protected]/service.go:345 Shutdown complete.      {"resource": {}}
 ```
 
 {{% /notice %}}
 
-{{% notice title="Tip" style="primary" icon="lightbulb" %}}
-Stopping the agent will halt its retry attempts and prevent any future retry activity.
+By stopping the agent will halt its retry attempts and prevent any future retry activity.
 
 If the agent runs for too long without successfully delivering data, it may begin dropping traces, depending on the retry configuration, to conserve memory. By stopping the agent, any metrics, traces, or logs currently stored in memory are lost before being dropped, ensuring they remain available for recovery.
 
 This step is essential for clearly observing the recovery process when the agent is restarted.
-{{% /notice %}}

content/en/conf/1-advanced-collector/2-building-resilience/_index.md

@@ -16,18 +16,3 @@ This solution will work for metrics as long as the connection downtime is brief
 For logs, there are plans to implement a more enterprise-ready solution in one of the upcoming Splunk OpenTelemetry Collector releases.
 
 {{% /notice %}}
-
-{{% notice title="Exercise" style="green" icon="running" %}}
-
-> [!IMPORTANT]
-> **Change _ALL_ terminal windows to the `[WORKSHOP]/2-building-resilience` directory.**
-
-Your directory structure will look like this:
-
-```text { title="Updated Directory Structure" }
-.
-├── agent.yaml
-└── gateway.yaml
-```
-
-{{% /notice %}}