-
Notifications
You must be signed in to change notification settings - Fork 62
Move tags "message" and "backtrace" in "rails.exceptions" series to values #43
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
Conversation
Hm, the original implementation really looks like a mistake. However, just moving the keys from the tag set to the value set will introduce unwanted fields:
I suggest using different keys for Since both scenarios (just moving vs. also renaming) will need a backward incompatible release, users can at least continue to use the same measurement when the keys don't stay |
@toddboom As far as I can see, you've authored the code in question (some years ago :-)) Do you remember, why the message and backtrace ended up in the tag set? |
Btw. I don't expect any response this year, this time is stressful enough :-) 🎅 🌟 🎁 |
…luxdata/influxdb-rails#43
Any progress on this? We have a branch in our forked version that extends @vassilevsky's branch by implementing the changes proposed by @dmke (basically renaming the exception field keys). Would a new PR be the way to go? |
Another PR is not necessary, I'll pull directly from your fork. If I don't hear from @toddboom by next week, I'll just merge it in, if that's OK with you. |
Hi :) I'm fine by any solution. Not really wanting to show off here :) |
I'm going to include these changes in an upcoming 1.0 release (ETA: on the weekend). |
@dmke hey, sorry for being radio silent on this for so long! i think your intuitions on this are correct. my guess is that the exception being encoded as a tag probably goes way, way back to a time when we were internally (possibly for Errplane, which was pre-InfluxDB) planning to use the exception as part of an indexing strategy. in hindsight, this was a terrible idea and i fully support making it a value instead. merge away! |
Will do! :-) |
Merged in eb465f2. |
Hello 🙃
I was surprised to find such enormous series in my database 😲
I propose this move of long and highly variable data from tags to values.
What else can be done?