Is it possible to write a query to match all of these metrics:
foo.bar.something1.ending_word
foo.bar.something1.something2.ending_word
foo.bar.something1.something_else.ending_word
foo.bar.something1.something2.something3.something4.ending_word
foo.bar.ending_word
Something like this:
foo.bar[*].ending_word
?
I am trying to use this to query data in Grafana:
If your metrics are not tagged metrics, then you have to use the normal target expression syntax, in which case wildcards cannot cover indeterminite levels. Reference the graphite doc on this:
All wildcards apply only within a single path element. In other words,
they do not include or cross dots (.). Therefore, servers.* will not
match servers.ix02ehssvc04v.cpu.total.user, while servers....
will.
If your metrics are tagged metrics, then you must use seriesByTag() and in this case the name may be treated as "just another" tag called "name" in the seriesByTag() function. You may use regular expressions in seriesByTag() by using "name=~regEx", which means you can use .* to cover as many levels as you want. See the graphite docs on querying by tags for additional information.
If you can't control the metric naming such that you can use tagging, I don't see a way to do what you want. Be warned that switching a metric to being tagged means that you'll have to change all existing references to it (as well as migrate the data).
There may be some way to do this in Grafana, but I don't know Grafana.
Related
I don't see an option to select a Content fragment variation to be used with fragment reference data type. Wondering if I'm missing something or if any other data type that can use Content fragment variations.
You can't select a specific variation directly in the picker. The intent of the CF is supposed to be more holistic to include all variations, then allow the consumer to determine what variation fits the need.
If you do need a specific variation, and you have them consistently named, you could add a field to name which variation should be included. Then the query could filter based on that provided value so that it can inform the consumer which of the _variations to use.
I have an influxdb instance, in which an upstream server is logging measurements into. I have multiple series of the shape: web.[domain].[status], for example: web.www.foobar.com.2xx, web.www.quux.com.3xx etc. There are two "variables" encoded into the series name: the domain and the status (2xx, 3xx, etc. are already aggregated).
Now I'd like to see how many of those requests I get. One possibility would be to just list the series:
select sum("value") from "web.www.quux.com.2xx","web.www.quux.com.3xx",...
But this is neither practical (too many) nor actually feasible (new domains are added and removed all the time), so I need a more flexible approach.
Is there some kind of wildcard syntax allowed in the from clause? The documentation doesn't mention any. Or is there another way to approach this?
You should to avoid this kind of measurement naming convention:
https://docs.influxdata.com/influxdb/v1.8/concepts/schema_and_data_layout/#avoid-encoding-data-in-measurement-names
hAvoid encoding data in measurement names
InfluxDB queries merge data that falls within the same measurement; it’s better to differentiate data with tags than with detailed measurement names. If you encode data in a measurement name, you must use a regular expression to query the data, making some queries more complicated or impossible.
I have a query which returns a number of ways. I want to find nodes matching certain criteria which appear within those ways. Note that the nodes I'm interested in do not form part of the way itself, but do appear within the bounds of the way. Also, the ways do not all have corresponding areas, so using the area search doesn't work in all cases.
I've got a minimal example which finds way 95677318, and I want to be able to find node 1552949334:
(
way({{bbox}})["man_made"="lighthouse"];
)->.searchArea;
/*doesn't work:*/
/*node(area.searchArea)["seamark:name"];*/
/*recur down and find node directly, just for the purpose of this question*/
(
.searchArea;>;
node({{bbox}})["seamark:name"];
);
out;
(Try it on https://overpass-turbo.eu/s/EpV)
This feature is not yet available as of release 0.7.55. In case there's no corresponding area available on the Overpass server, this kind of query is simply not feasible.
See https://github.com/drolbr/Overpass-API/issues/77 for details.
From: http://developers.soundcloud.com/docs/api/tracks#filtering
I'm not sure from the docs if this functionality is available. I want to be able to:
use a range filter for comment_count, download_count, playback_count, favoritings_count, e.g. favoritings_count[from]=100
Is there a way I can use a range filter on # of favoritings with the current API?
I also see there are filters for "genres" and "types", but no examples are given. How do I use these filters?
The tracks resource does not currently support filtering on any of the properties you mentioned. You can apply interval filters to bpm, duration and created_at. You can however, set the 'order' param to 'hotness'. A tracks 'hotness' is determined by a number of factors, including the number of favoritings.
Genre is a user defined field, and therefore there isn't a strict enumeration of valid values. Common ones are things like 'dubstep' or 'house' or 'punk', etc. Types is currently one of: other, sample, sound effect, loop, stem, in progress, demo, podcast, spoken, recording, live, remix, original. Note that these are subject to change in the future.
I'll look into adding a list of valid values for 'types' to the docs. Thanks for pointing that out.
I'm trying to create a more advanced query mechanism for REST. Assume I have the following:
GET /data/users
and it returns a list of users. Then to filter the users returned for example I'd say:
GET /data/users?age=30
to get a list of 30 year old users. Now lets say I want users aged 30 - 40. I'd like to have essentially a set of reusable operators such as:
GET /data/users?greaterThan(age)=30&lessThan(age)=40
The greaterThan and lessThan would be reusable on other numeric, date, etc fields. This would also allow me to add other operators (contains, starts with, ends with, etc). I'm a REST noob so I'm not sure if this violates any of the core principles REST follows. Any thoughts?
Alternately, you might simply be better off with optional parameters "minAge" and "maxAge".
Alternative 2: encode the value(s) for parameters to indicate the test to be performed: inequalities, pattern matching etc.
This gets messy no matter what you do for complex boolean expressions. At some point, you almost want to make a document format for the query description itself, but it's hard to think of it as a "GET" anymore.
I would look into setting the value of the query parameter to include syntax for operators and such .. something like this for a range of values
/data/users?age=[30,40]
or
/data/users?age=>30&age=<40
would make it a little easier to read, just make sure to url encode if you are using any reserved characters