Proposal: merge `pkg/translator/azure` and `pkg/translator/azurelogs`

[Fiery-Fenix]

Component(s)

pkg/translator/azurelogs

Describe the issue you're reporting

Both components providing similar functionality and even shares some code, for example TimeFormats functionality.
There 2 components that depends on those translators:

• receiver/azureeventhubreceiver (it even depends on both translators)
• receiver/kafkareceiver

Because both mentioned receivers can be used for the same purpose - consuming Azure Resource Logs from EventHub (the only difference is that azureeventhubreceiver uses AMQP protocol to communicate with EventHub, while kafkareceiver - Kafka protocol) - it is introducing major discrepancy in received data, because azurelogs and azure has different parsing logic.
To avoid such discrepancy I would like to propose to merge both translators into single one, with maybe some configuration addition to preserve compatibility.
This merge will also helps with future movement of this translators into encoding package (#39095)

Main difference at the moment in translators:
translator/azure:

• Has support for conversion of Azure Trace Records to OTLP Traces
• Parses Azure Resource Logs Attributes into OTLP Log Attributes
• Doesn't have Azure Resource Logs Category specific conversion rules

translator/azurelogs

• Parses Azure Resource Logs Attributes into OTLP Log Body (transition to OTLP Log Attributes is a WIP at the moment)
• Has Azure Resource Logs Category specific conversion rules for some part of Categories - this produce more aligned with OpenTelemetry SemConv outcome

As a result of merge, I would propose to have single component (ideally - encoding extension in future) that will have:

• Support for conversion of Azure Trace Records to OTLP Traces
• Parser for Azure Resource Logs Attributes into OTLP Log Attributes/Resource Attributes
• Azure Resource Logs Category specific conversion rules
• Configurable behavior

[github-actions]

Pinging code owners:

• pkg/translator/azurelogs: @atoulme @cparkins @MikeGoldsmith @constanca-m

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[VihasMakwana]

Yeah, I think this would help with maintainability. Let's hear more from codeowners.

[cparkins]

@Fiery-Fenix I think the proposed design makes sense. The intention of this package was to maintain compatibility between the two Receivers in the first place. The work to improve the Event Hubs Receiver was recently added (azurelogs) and should be available to the Kafka Receiver as well.

[constanca-m]

ideally - encoding extension in future

I have already created an issue for this #39095, waiting for approval.

I agree that merging the two would be the right path. It is a bit confusing that there are two translators for azure resource logs. I was under the impression that the translator for azure did not follow semantic conventions, and that was the only difference. Reading your description, maybe I was wrong and there are more differences. Do you know if there are any components that solely rely on the translator azure?

Currently, the translator azurelogs is going through a big restructure and there will be some breaking changes in the future. See #39186.

[MikeGoldsmith]

The original azure translator preceded a number of semconv changes so we decided to create a new translator. The intention was to develop the new translator to include everything the original could do and then remove the old one. As semconv is normally a whole pipeline choice, we though it best to add the choice of which translator in the receiver.

I'm in favour of merging the two, but need to ensure backward compatibility is maintained as it there are a number of breaking changes to the output telemetry (both attribute names and locations).