docs: Validate the LogPipeline OTel Setup and test the performance of the log agent

docs/contributor/benchmarks/otlp-logs-validation.md

@@ -1,14 +1,13 @@
 # OTel LogPipeline Setup Validation
 
-- [Setup Configuration Steps](#setup-configuration-steps)
+- [Setup Configuration Steps](#configuring-the-log-agent)
 - [Resources Under Investigation](#resources-under-investigation)
 - [Benchmarking Setup](#benchmarking-setup)
 - [Performance Tests Results](#performance-tests-results)
-  - [📊 Benchmarking Session #1](#-benchmarking-session-1)
-  - [📊 Benchmarking Session #2](#-benchmarking-session-2)
 - [Conclusions](#conclusions)
 
 
+
 ## Configuring the Log Agent
 
 To configure the log agent, deploy the [OTLP Logs Validation YAML](./otlp-logs-validation.yaml) either with Helm or manually:
@@ -391,7 +390,7 @@ By enabling the storeCheckpoint preset (Helm), the `file_storage` extension is a
 
 
 ## Comparison with FluentBit Setup
-In the FluentBit setup, for the very same (initial) scenario (that is, 10 generator replicas [old set-up] or 2 agents), the [load test](https://github.com/kyma-project/telemetry-manager/actions/runs/12691802471) outputs the following values for the agent:
+In the FluentBit setup, for the very same (initial) scenario (that is, 10 generator replicas [old setup] or 2 agents), the [load test](https://github.com/kyma-project/telemetry-manager/actions/runs/12691802471) outputs the following values for the agent:
 - Exported Log Records/second: 27.8K
 
 ## Conclusions
@@ -400,7 +399,7 @@ In the FluentBit setup, for the very same (initial) scenario (that is, 10 genera
   - Backpressure is currently not backpropagated from the gateway to the agent, resulting in logs being queued or lost on the gateway end. That's because the agent has no way of knowing when to stop, thus exports data continuously (this is a known issue, which is expected be solved by the OTel community in the next half year).
   - If the load is increased (that is, more generators, more logs, or more data), the log agent slows down.
   - The network communication between the agent and the gateway or/and the gateway represent a bottleneck in this setup. That's concluded because higher throughput was observed when using just a debug endpoint as an exporter.
-  - CPU and memory consumption are surprisingly low, and this was not improved by removing the limits (quite the opposite was observed, with the CPU throttling more often and the throughput decreasing).
+  - CPU and memory consumption are surprisingly low, and the efficiency was not improved by removing the limits (quite the opposite was observed, with the CPU throttling more often and the throughput decreasing).
   - If the batch processor is enabled, throughput increased. But this comes at the cost of losing logs in some scenarios.
   - Further methods of improving the throughput might still be worth investigating.