Brighter Semantic Conventions

[iancooper]

As part of the work on V10 we are looking at semantic conventions for our support of open telemetry. We would love to get your feedback on these conventions: https://github.com/BrighterCommand/Brighter/blob/cloud_events_pub/docs/adr/0010-brighter-semantic-conventions.md

[martincostello]

General comment: for readability, wrapping attribute names in backticks may help, e.g. messaging.destination.partition.id rather than messaging.destination.partition.id.

source name: Paramore.Brighter <version number>

Based on the shape of the ActivitySource constructor API, I would suggest that the source name is simply Paramore.Brighter and the version is passed to the dedicated optional parameter, rather than baking the version into the name itself.

This is typically what the OpenTelemetry libraries for .NET do: example.

See the [OTel documentation for S3]

Missing link x2

We record the following attributes on a Command Processor span:

Does anything need to be considered about PII (or similar) data that could be stored in the value of paramore.brighter.request_body when it is added to a span?

(Cloud Events Distributed Tracing Extension)[https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/extensions/distributed-tracing.md]

Markdown link syntax is inverted.

[iancooper]

Thanks for these.

As we will allow you to configure adding body attributes to the span I assume that we can avoid PII issues by configuration. I would only expect you to add body if you had a issue that you needed help with, as it's going to add quite a lot of noise to your trace.