<div dir="ltr">The only one I've used a lot among those you mention is mongodb query language. And honestly I don't like it very much, I find it quite counter-intuitive to use. It's all JSON, everything must be named and bracketed, I was quickly lost in a opened-closed-nested curly-braces hell. For instance, querying for age > 40 is "{age:{$gt:40}}". It's probably easy to implement as a query language, but it can become a nightmare for users. In db world I see it as a big step backward from SQL, which is much more "natural". (I just found that blog post that explains it better than me: <a href="http://www.vertabelo.com/blog/notes-from-the-lab/sql-vs-mongo-query">http://www.vertabelo.com/blog/notes-from-the-lab/sql-vs-mongo-query</a> )</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 20, 2017 at 8:51 AM, Michael Burman <span dir="ltr"><<a href="mailto:miburman@redhat.com" target="_blank">miburman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'd personally would want to see another type of functional language,<br>
such that would look like the one when you do Streams / RxJava. I guess<br>
it's closer to the one in MongoDB/RethinkDB/InfluxDB 2.0/Riemann, than<br>
the one in Prometheus/Graphite (PromQL is mostly evolution of Graphite's<br>
query language).<br>
<br>
And it could allow us to provide features such as streaming metrics,<br>
since we could transform those queries directly to reactive queries (we<br>
should take advantage of the fact that we process the metrics by<br>
reacting to them in the backend).<br>
<br>
- Micke<br>
<span class=""><br>
<br>
On 07/19/2017 06:36 PM, Joel Takvorian wrote:<br>
> Hi,<br>
><br>
> I just want to share some ideas about the eventuality of having a<br>
> language to perform some arithmetic / aggregations on metrics, before<br>
> it goes out of my head...<br>
><br>
> Here's an example of what I would personally love to see in Hawkular:<br>
><br>
> ------------------------------<wbr>----------------<br>
</span>> *Example:*<br>
> /sum(stats(rate((id(my_metric)<wbr>, tags(a=foo AND b=bar),<br>
> regexp(something_.+)), 5m), 10m))/<br>
<span class="">> |<br>
> |=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for<br>
> id, 0-n for tags and regexp)<br>
> |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten<br>
> them in a single set<br>
> |===> rate(set_of_raw_metrics, rate_period) computes the rate for each<br>
> of them and return a set of metrics (map n=>n)<br>
> |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw<br>
> metrics, returning the same number of bucketized metrics (map n=>n)<br>
> |=====> sum(set_of_stats_metrics) sums every buckets, returning a<br>
> single bucketized metric (fold n=>1)<br>
><br>
><br>
</span>> *Other:*<br>
<span class="">> Functions like "sum" that take stats_metrics could have overloaded<br>
> shortcut "sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.<br>
> In other words above example could be rewritten:<br>
</span>> /sum(rate((id(my_metric), tags(a=foo AND b=bar),<br>
> regexp(something_.+)), 5m), 10m)/<br>
<span class="">><br>
> Note: we can do aggregations like "sum" on raw data if necessary, it<br>
> just means we have to interpolate.<br>
><br>
</span>> *Scalar operations:*<br>
> /sum((id(a_metric_in_<wbr>milliseconds), *1000**id(a_metric_in_seconds)<wbr>), 10m)/<br>
<span class="im HOEnZb">> ------------------------------<wbr>----------------<br>
><br>
> Of course many other functions could come growing the library.<br>
><br>
> Now I suppose the big question, if we want to do such thing, is "are<br>
> we going to invent our own language?" I don't know if there are<br>
> standards for this, and if they are good.<br>
><br>
> The Prometheus query language cannot be transposed because a label is<br>
> not a tag and it makes no sense for us to write something like<br>
> "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".<br>
><br>
> The same language could be used both for read-time on-the-fly<br>
> aggregations and write-time / cron-based rollups.<br>
><br>
> WDYT?<br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> hawkular-dev mailing list<br>
> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
</div></div></blockquote></div><br></div>