-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
WIP: Change ES tag schema to support tag search in Kibana #982
WIP: Change ES tag schema to support tag search in Kibana #982
Conversation
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
what about backwards compatibility with the data people already have stored in ES? |
I haven't been thinking about it yet. We could provide a migration to new model or support query for old model. |
Performance results https://github.com/pavolloffay/jaeger-perf-tests, 300k spans different limit parameter for jaeger-query
limit 50000 https://pastebin.com/axmkbmjH Query time of limit 50000: mean = 13533.82 milliseconds Report time with multiple quries The number of tags does not seem to affect query time |
I think #980 is a better solution. Types are just noise, given that ES already infers them. If you have untyped tags this is not true any more, but it is a bad practice and you always have the option of typing them as strings as an ad-hoc fix. |
Most important piece of my proposal is that only *specified tags would be stored as direct object. Other tags would still be stored as nested object like it is right now.
|
Resolves #906
Example tag mapping
With this mapping default ES configuration stores ~183 unique tag keys - see also #980 (comment)