open-telemetry / open-telemetry/opentelemetry-cpp

C++ Logger API does not compliant with the OTel Logs Data Model

Open
#3,000 8 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug spec-compliance Stale triage/accepted
Dominant language
C++
Stars
1.4k
Forks
632
Avg merge
1d 13h
Merged PRs (30d)
75

Description

In the OTel Logs Data Model, it is specified that the Body field must support any type to preserve the semantics of structured logs emitted by the application: https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-body. This is specifically useful for the application which logs a JSON-structured data i.e. map<string, any> as the Body. But the OTel C++ Logger API does not support such a case, it supports string_view or AttributeValue type in the Body (code) but neither of those can preserve the semantics of structured data.

Ideally, if the Logger API preserves the semantics of structured data, the structure should be preserved across the stack (e.g. from application to OTel collector via OTLP and eventually the structured data gets exported to the backend log store).

Seems like there is also an Event API for logging structured data. But it is still a WIP and is a specialized Log API and would have the same issue in opentelemetry-cpp since the current API does not support structured data.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with api/include/opentelemetry/logs/logger.h and the AttributeValue definition in api/include/opentelemetry/common/attribute_value.h, then compare them with the OTel Logs Data Model Body field and the linked Event API. Trace the existing logging and OTLP paths to determine where structured data support would need to be represented. Done means the API can preserve structured Body values across the supported stack, with tests covering the intended representation.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
api, observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.