Replace the link to Span Metrics Processor (#896)

concepts/observability-strategy/configurable-monitoring/pocs/shared-vs-per-sinal-type-collector/README.md

@@ -35,7 +35,7 @@ The first approach is the easiest one, the only drawback is a hard dependency on
 
 ### Signal translation
 
-It is sometimes necessary to convert signals from one signal type to another. Signal translations may be direct one-to-one operations or include derivative signals such as counts, aggregations, summarizations, etc. It is possible to, let's say, convert traces to metrics in the trace gateway using [Span Metrics Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/spanmetricsprocessor) and send them to the metric gateway, which in turn would send them to the backend. However, a shared collector is advantageous in this case because it can do it in-process without performing additional network calls.
+It is sometimes necessary to convert signals from one signal type to another. Signal translations may be direct one-to-one operations or include derivative signals such as counts, aggregations, summarizations, etc. It is possible to, let's say, convert traces to metrics in the trace gateway using [Span Metrics Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.95.0/processor/spanmetricsprocessor) and send them to the metric gateway, which in turn would send them to the backend. However, a shared collector is advantageous in this case because it can do it in-process without performing additional network calls.
 
 ## Proposal