Updating diagrams with new styles (#2869)

content/en/docs/_index.md

@@ -13,4 +13,4 @@ for instrumenting, generating, collecting, and exporting telemetry data such as
 [logs](concepts/observability-primer/#logs). As an industry-standard, it is
 [natively supported by a number of vendors](/ecosystem/vendors/).
 
-![OpenTelemetry Reference Architecture](/img/otel_diagram.png)
+![OpenTelemetry Reference Architecture](/img/otel-diagram.svg)

content/en/docs/collector/deployment/gateway.md

@@ -28,7 +28,7 @@ same collector instance where the tail sampling policy is applied.
 
 Let's have a look at such a case where we are using the load-balancing exporter:
 
-![Gateway deployment with load-balancing exporter](../../img/gateway-lb-sdk.svg)
+![Gateway deployment with load-balancing exporter](../../img/otel-gateway-lb-sdk.svg)
 
 1. In the app, the SDK is configured to send OTLP data to a central location.
 2. A collector configured using the load-balancing exporter that distributes

content/en/docs/concepts/observability-primer.md

@@ -131,7 +131,7 @@ what steps make up a request).
 Many Observability back-ends visualize traces as waterfall diagrams that may
 look something like this:
 
-![Sample Trace](/img/waterfall_trace.png 'Trace waterfall diagram')
+![Sample Trace](/img/waterfall-trace.svg 'Trace waterfall diagram')
 
 Waterfall diagrams show the parent-child relationship between a root span and
 its child spans. When a span encapsulates another span, this also represents a

content/en/docs/concepts/sampling/index.md

@@ -16,7 +16,7 @@ without unacceptable latency or errors, do you really need all that data? Here
 the thing—you don’t always need a ton of data to find the right insights. _You
 just need the right sampling of data._
 
-![Illustration shows that not all data needs to be traced, and that a sample of data is sufficient.](traces_venn_diagram.png)
+![Illustration shows that not all data needs to be traced, and that a sample of data is sufficient.](traces-venn-diagram.svg)
 
 The idea behind sampling is to control the spans you send to your observability
 backend, resulting in lower ingest costs. Different organizations will have
@@ -79,7 +79,7 @@ all or most of the spans within the trace. Tail Sampling gives you the option to
 sample your traces based on specific criteria derived from different parts of a
 trace, which isn’t an option with Head Sampling.
 
-![Illustration shows how spans originate from a root span. After the spans are complete, the tail sampling processor makes a sampling decision.](tail_sampling_process.png)
+![Illustration shows how spans originate from a root span. After the spans are complete, the tail sampling processor makes a sampling decision.](tail-sampling-process.svg)
 
 Some examples of how you can use Tail Sampling include:
 

content/en/docs/concepts/signals/baggage.md

@@ -18,7 +18,7 @@ pass Baggage around, and each of the different library implementations has
 propagators that parse and make that Baggage available without you needing to
 explicitly implement it.
 
-![OTel Baggage](/img/otel_baggage.png)
+![OTel Baggage](/img/otel-baggage.svg)
 
 ## Why does OTel Baggage exist?
 
@@ -46,7 +46,7 @@ you’re searching in your Observability back-end.
 There are no built-in integrity checks to ensure that the Baggage items are
 yours, so exercise caution when retrieving them.
 
-![OTel Baggage](/img/otel_baggage-2.png)
+![OTel Baggage](/img/otel-baggage-2.svg)
 
 ## Baggage is not the same as Span attributes