Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure resultSignature is not necessarily a string #36499

Open
eberkut opened this issue Nov 22, 2024 · 4 comments
Open

Azure resultSignature is not necessarily a string #36499

eberkut opened this issue Nov 22, 2024 · 4 comments

Comments

@eberkut
Copy link

eberkut commented Nov 22, 2024

Component(s)

pkg/translator/azure, pkg/translator/azurelogs

What happened?

Description

The resultSignature field in Azure logs is expected to be a string in the codebase:

However, this field can vary in type depending on the Azure service emitting the logs. For instance, in Azure AI Search, the resultSignature field is an integer as stated in the Azure documentation:
https://learn.microsoft.com/en-us/azure/search/monitor-azure-cognitive-search-data-reference#resource-log-schema

This discrepancy causes errors in processing logs from services where resultSignature is not a string.

Steps to Reproduce

  1. Configure an Azure service that sends an integer for the resultSignature field (e.g., Azure AI Search).
  2. Set up the service's diagnostic settings to forward logs to an Azure Event Hub.
  3. Configure an OpenTelemetry Collector with a receiver for Azure Event Hub.
  4. Send a log event where the resultSignature field is an integer.

Expected Result

Logs from Azure services should be processed without errors, regardless of the type of the resultSignature field.

Actual Result

An error is generated when processing logs with a resultSignature field that is not a string.

Collector version

0.114.0

Environment information

Environment

OS: "Ubuntu 20.04"

OpenTelemetry Collector configuration

receivers:
  azureeventhub:
    connection: <REDACTED>
    format: azure
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch: {}

exporters:
  otlphttp:
    endpoint: <scrubbed_endpoint>
    headers:
      Authorization: "<REDACTED>"

service:
  pipelines:
    logs:
      receivers: [azureeventhub]
      processors: [batch]
      exporters: [otlphttp]
  telemetry:
    logs:
      level: "DEBUG"
      encoding: "json"
    metrics:
      level: normal
      address: 0.0.0.0:8888
  extensions: [health_check]

Log output

{"level":"error","ts":1732127778.2987723,"caller":"[email protected]/eventhubhandler.go:157","msg":"error decoding message","exporter_id":"aci-93f27a-ci-aitechsbx-dit-01","kind":"receiver","name":"azureeventhub","data_type":"logs","error":"failed to unmarshal logs: azure.azureRecords.Records: []azure.azureLogRecord: azure.azureLogRecord.ResultSignature: ReadString: expects \" or n, but found 2, error found in #10 byte of ...|nature\": 200, \"durat|..., bigger context ...|gs\", \"resultType\": \"Success\", \"resultSignature\": 200, \"durationMS\": 43, \"properties\": {\r\n  \"Descript|...","stacktrace":"github.com/open-telemetry/opentelemetry-collector-contrib/receiver/azureeventhubreceiver.(*eventhubHandler).newMessageHandler\n\tgithub.com/open-telemetry/opentelemetry-collector-contrib/receiver/[email protected]/eventhubhandler.go:157\ngithub.com/Azure/azure-event-hubs-go/v3.(*receiver).handleMessage\n\tgithub.com/Azure/azure-event-hubs-go/[email protected]/receiver.go:267\ngithub.com/Azure/azure-event-hubs-go/v3.(*receiver).handleMessages\n\tgithub.com/Azure/azure-event-hubs-go/[email protected]/receiver.go:244"}

Additional context

No response

@eberkut eberkut added bug Something isn't working needs triage New item requiring triage labels Nov 22, 2024
Copy link
Contributor

Pinging code owners:

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

@braydonk
Copy link
Contributor

braydonk commented Dec 4, 2024

Triage: Issue appears to be well specified and has necessary info. Moving to waiting-for-codeowners

@braydonk
Copy link
Contributor

braydonk commented Dec 4, 2024

/label -needs-triage

@github-actions github-actions bot removed the needs triage New item requiring triage label Dec 4, 2024
@braydonk
Copy link
Contributor

braydonk commented Dec 4, 2024

/label waiting-for-code-owners

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants