Skip to content
This repository was archived by the owner on Jul 31, 2023. It is now read-only.
This repository was archived by the owner on Jul 31, 2023. It is now read-only.

Span attribute control implementation is incoherent #156

Open
@garthk

Description

@garthk

To be compatible with the OpenCensus protobuf protocol, an attribute value MUST be one of:

  • TruncatableString
  • int64
  • bool_value
  • double_value

Strikes me libraries for creating spans SHOULD prevent creation of attributes that OpenCensus Collector and OpenCensus Reporter can't handle, as otherwise end users will run into trouble whenever they change their ops infrastructure.

Some destinations are even stricter, e.g. Datadog (opencensus-beam/opencensus_datadog#8). For the same operational flexibility reasons, their export libraries SHOULD cast attributes their target can't handle to strings.

You might well argue that, no:

  • Each language has its own ecosystem of libraries
  • The supported attributes are up to them
  • The definition of AttributeValue is relevant only to the Go ecosystem, despite it being used in some software we encourage end users to deploy

Whatever angle you take, though, there's something about our version 0.9.1 that's wrong.

Despite its type declarations, :ocp.put_attribute/2 in 0.9.1 is even stricter than AttributeValue:

iex> :ocp.with_child_span("name")
iex> :ocp.put_attribute("double", 1.0)
{:error, :invalid_attribute}

None of the other ways to put attributes restrict attribute values, including:

  • :oc_span.put_attribute/3,
  • :oc_span.put_attributes/2,
  • :oc_trace.put_attribute/3,
  • :oc_trace.put_attributes/2,
  • :ocp.put_attributes/1

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions