Telemetry should be splitted

[bkchr]

Currently when submitting telemetry messages, we will be sending relay chain and parachain messages always to the same endpoint. This will not work, because the telemetry can not distinguish them.

As for logging, we need some sort of scopes to distinguish them. This can be done with slogger and the feature for setting a scope per future.

After we have scopes, we need to make the telemetry aware of these scopes and send the messages to the correct endpoint.

[cecton]

Are you sure it is sloggers? I don't see that feature... https://docs.rs/sloggers/1.0.1/sloggers/

[dvdplm]

Can you elaborate on how the telemetry splitting will look on the cli side (multiple --telemetry-url?) and on from the point of view of telemetry (two separate streams? or single stream but "tagged" with the parachain message type?).

[cecton]

Can you elaborate on how the telemetry splitting will look on the cli side (multiple --telemetry-url?) and on from the point of view of telemetry (two separate streams? or single stream but "tagged" with the parachain message type?).

The parachain and relaychain arguments are already separated in the CLI: cumulus [parachain_args] -- [relaychain_args] so they can have different telemetry: cumulus --telemetry-url x -- --telemetry-url y

on from the point of view of telemetry (two separate streams? or single stream but "tagged" with the parachain message type?).

I'm not sure about that. I need to investigate. But as Basti said:

we replace the singleton with an instance that is passed everywhere

[bkchr]

We will spawn two instances of the telemetry. Both will connect separately to the telemetry endpoint. We can optimize this later relative easy and only have one connected. But for now, we first need to get it working with instances.