-
Notifications
You must be signed in to change notification settings - Fork 3.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
Cross-series regex queries are too strict #1039
Comments
The way this query is handled is by iterating over all series names that match the regex. We can add a clause to the query language, e.g. |
If a series was skipped, would it not appear in the output at all? Or would there be some notion of being able to tell which series gave errors. |
I'm guessing it wouldn't exist at all, may be the fact that they were skipped will get logged |
An example of what @codyhanson might be getting at. Normal Query
demoSkip_error
demoSkip_success
Query with Skip/Suppress Error
demoSkip_error
demoSkip_success
|
What's the use case for that kind of output ? |
I want to get data for many series at a time, but the data may be sparse. An example would be if I am recording response times for my servers by node, but the nodes may change or die at any given time, or simply not record any data during low-capacity periods of time. In this example case, I might use a series_name syntax of
Fundamentally, you have this awesome feature in the ability to query across series using a Regex, but it's totally hamstrung by the fact that the entire query fails if a single series isn't as expected. How depressing is it if you are querying across 100 series and the whole thing barfs because 1 of those didn't have data at the time you care about? Edit:Regarding having an Error message, that would be a way for me to know (in the response time example) whether I'm not getting a response for a given series because:
|
I hit this same problem. It seems unexpected that no error is returned if a series doesn't exist in the queried timeframe, but it returns an error if a metric doesn't exist. I need to be able to add and remove columns as my system matures. It doesn't seem like an "error" that needs "suppressing". Just return none/null for the value just like is done when the series doesn't exist for the entire time frame. I guess I could go to a single column per series as the OP proposed, but then I really begin to question what is the point of columns? |
This seems to be worse than I previously thought. It is not using the timeframe when checking if the column exists. Here is what I have observed:
Because |
+1 agree with @leesjensen on this. I'm definitely finding this error behavior to be unexpected and frustrating. edit: I like the suggestion "Just return none/null for the value just like is done when the series doesn't exist for the entire time frame." |
Hm I wonder if this is now fixed in the current 0.9.0 rc release: |
I also desperately need a solutuion for this. Having a system evolve constantly affects the fields contained in series. Some way to still get around this is needed very much for regex queries. |
My use case is I have many multi-column series, all named
xxx_yyy_zzz
where xxx/yyy/zzz are references I use to index the series. The structure of these series may change over time as the metrics I store (columns) change or become obsolete. The result is some series may or may not have a given metric, e.g.MetricA
.What I want to do is find a summary of all of
xxx
'sMetricA
with a query like:I think it would be reasonable to expect the query to simply return empty data for the series that don't have that field/column. An alternative, reasonable, behavior would be to "skip" those series and just return data for the series which have the desired field/column.
A workaround would be for me to change my data model and split it to be many more single-column series, each having the metric it's tracking in the series name (e.g.
xxx_yyy_zzz_MetricA
). This seems like a bit of a kludge to me though.Thoughts? Does this feature exist but I just didn't see it in the documentation? Is it on the roadmap? Is there a deeper concept of "metadata" in Influx beyond just the series name.
The text was updated successfully, but these errors were encountered: