[googlecloudexporter] Support Google Cloud Format LogSeverity strings set as SeverityText field

[franciscovalentecastro]

Component(s)

googlecloudexporter

Is your feature request related to a problem? Please describe.

Currently the googlecloudexporter for logs has mappings [1] that use SeverityNumber to match a LogSeverity [3] value when sending the LogEntry to Google Cloud Logging. The exporter also has mappings [1] that transform the SeverityText field to SeverityNumber before exporting to Google Cloud Logging. This behaviour is documented in [2].

When parsing logs that contain LogSeverity [3] style values, this mappings doesn't export correctly some severity values when set as SeverityText. For example, NOTICE would be set as No Severity (0) in the LogEntry since the SeverityText -> SeverityNumber mapping in the exporter doesn't contain a rule for NOTICE.

[1] https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/v0.48.3/exporter/collector/logs.go#L66-L127

[2] https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/googlecloudexporter/README.md

[3] https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#logseverity

Describe the solution you'd like

Add LogSeverity styles values (uppercase, DEBUG, NOTICE, INFO ...) to the mapping from SeverityText -> SeverityNumber in [1]. The OpenTelemetry definition of SeverityText [4] doesn't have restrictions on which strings could be set in that field.

This solution enables a logging pipeline to use Google Cloud Logging data model logs without having to do intermediate transformation to set correctly SeverityNumber.

[1] https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/v0.48.3/exporter/collector/logs.go#L66-L127

[4] https://opentelemetry.io/docs/specs/otel/logs/data-model/#severity-field

Describe alternatives you've considered

One alternative would be to always have an intermediate LogSeverity -> SeverityNumber transform processor when handling logs that conform to the Google Cloud Logging (GCL) data model, e.g. using LogSeverity values. To manage a pipeline that handles GCL style logs, there would always have to intermediate transformations to make sure it is mapped correctly in the exporter.

Concerns : This adds more processing at each step when working with GCL data model logs.

Additional context

No response