Add Azure SDK & Logs

[MikeGoldsmith]

Fixes #1027

Changes

Adds the new Azure Logs semantic conventions.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[MikeGoldsmith]

Hi @lmolkova - please can we get your input on adding these Azure SDK / logs semantic conventions? Thanks 😄

[lmolkova]

Thank you for for working on this!

I'll share more comments, but the main question is whether we need to define those as attributes.
My assumption that azure logs would be mapped to OTel logs/log-based-events.

Logs/events have attributes and payload. We can take azure log as is, document the payload format and send them as is over OTLP with no mapping.

Event payload fields can be documented, here's an example, they don't need a namespace.

If there are no use-case for these attributes to appear on spans, metrics, resources, then event payload fields would work better.

So, was this option was considered? What would be the reasons to send azure logs with those as attributes and not event payload fields?

/cc @MSNev

[lmolkova]

I believe there are two major discussion points:

• whether we need attributes for azure log events or they should be populated as event payload fields (elaborated in the comment above)
• how the actual mapping works - is it possible to document Azure Log Event semconv? What goes into event name, timestamp, severity, payload, attributes, etc

[lmolkova]

no strong opinion, but wonder if we should reuse az.service_request_id here.

[lmolkova]

we should reuse existing cloud.resource_id

[TylerHelmuth]

@lmolkova the PR went with attributes because that has been the standard for collector translators/components so far. I believe the k8sobjectsreceiver is an early implementor of the event concept, but is currently suffering for being an early adopter (it sets event.domain still which was removed).

I'm not very up-to-date with the event spec. I see it is marked as experimental still, is it changing a lot still? I see this PR as an attempt to provide some clarity/stability for azure -> OTel semantics and I'm wondering if attributes gives more stability than events while azure -> OTel semantics become stable.

[TylerHelmuth]

Another question:

My understanding is that for any event.name value, the payload (log body in this case) should always be same. Do we have that guarantee with the data being targeted in open-telemetry/opentelemetry-collector-contrib#32486?

[MikeGoldsmith]

Thanks for your feedback @lmolkova. I've worked through most of your suggestions.

Regarding reuse of az.service_request_id and cloud.resource_id fields, do you mean using a link feature between two semconv definitions (I'm unsure if that exists or how to do it), or do you mean use the same field and description as the linked fields?