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

[Bug]: Special cases are not handled correctly when using an elasticsearch backend with ES_TAGS_AS_FIELDS_ALL set #989

Open
Limess opened this issue Sep 21, 2022 · 1 comment
Labels

Comments

@Limess
Copy link

Limess commented Sep 21, 2022

What happened?

As a Jaeger user with Elasticsearch as a backend
I want the Jaeger UI to respect ES_TAGS_AS_FIELDS_DOT_REPLACEMENT
So I can use sophisticated UI functionality while using Elasticsearch as a backend

Currently, #659 is not working due to peer.service becoming peer_service (similar with other special functionality/fields implemented here: https://github.com/jaegertracing/jaeger-ui/blob/e197d1c8d36a73616620c2b4d55d18f4a017a188/packages/jaeger-ui/src/model/trace-dag/denseTransforms.tsx

Steps to reproduce

  • Setup Jaeger with an elasticsearch backend
  • Set ES_TAGS_AS_FIELDS_DOT_REPLACEMENT="_" on the collector
  • Send traces with span.kind=CLIENT, peer.service=PeerService

Expected behavior

I'd expect the PeerService to be shown as per this PR #659

Relevant log output

No response

Screenshot

peer.service is converted to peer_service, so the code path is not triggered. image

Additional context

No response

Jaeger backend version

v1.37.0

SDK

OpenTelemetry Java Agent v1.17.0

Pipeline

OTEL SDK -> OTEL Collector -> Jaeger Collector -> [Jaeger Proto] -> Elasticsearch (AWS Opensearch 1.3)

Stogage backend

AWS Opensearch 1.3

Operating system

Linux

Deployment model

Docker ECS Daemons

Deployment configs

ES_VERSION: "7"
      ES_SERVER_URLS: <es_backend_url>
      ES_TAGS_AS_FIELDS_ALL: "true"
      ES_TAGS_AS_FIELDS_DOT_REPLACEMENT: _
      SPAN_STORAGE_TYPE: elasticsearch
@Limess Limess added the bug label Sep 21, 2022
@Limess
Copy link
Author

Limess commented Sep 22, 2022

This only seems to occur when using a custom label, e.g _ rather than the default @. We've now switched to the default so are less interested in the resolution of this.

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

No branches or pull requests

1 participant