[Hawkular-dev] Calculated metrics: sharing ideas

[Joel Takvorian]

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:
http://www.vertabelo.com/blog/notes-from-the-lab/sql-vs-mongo-query )

On Thu, Jul 20, 2017 at 8:51 AM, Michael Burman <miburman at redhat.com> wrote:

> Hi,
>
> I'd personally would want to see another type of functional language,
> such that would look like the one when you do Streams / RxJava. I guess
> it's closer to the one in MongoDB/RethinkDB/InfluxDB 2.0/Riemann, than
> the one in Prometheus/Graphite (PromQL is mostly evolution of Graphite's
> query language).
>
> And it could allow us to provide features such as streaming metrics,
> since we could transform those queries directly to reactive queries (we
> should take advantage of the fact that we process the metrics by
> reacting to them in the backend).
>
>     - Micke
>
>
> On 07/19/2017 06:36 PM, Joel Takvorian wrote:
> > Hi,
> >
> > I just want to share some ideas about the eventuality of having a
> > language to perform some arithmetic / aggregations on metrics, before
> > it goes out of my head...
> >
> > Here's an example of what I would personally love to see in Hawkular:
> >
> > ----------------------------------------------
> > *Example:*
> > /sum(stats(rate((id(my_metric), tags(a=foo AND b=bar),
> > regexp(something_.+)), 5m), 10m))/
> > |
> > |=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for
> > id, 0-n for tags and regexp)
> > |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten
> > them in a single set
> > |===> rate(set_of_raw_metrics, rate_period) computes the rate for each
> > of them and return a set of metrics (map n=>n)
> > |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw
> > metrics, returning the same number of bucketized metrics (map n=>n)
> > |=====> sum(set_of_stats_metrics) sums every buckets, returning a
> > single bucketized metric (fold n=>1)
> >
> >
> > *Other:*
> > Functions like "sum" that take stats_metrics could have overloaded
> > shortcut "sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.
> > In other words above example could be rewritten:
> > /sum(rate((id(my_metric), tags(a=foo AND b=bar),
> > regexp(something_.+)), 5m), 10m)/
> >
> > Note: we can do aggregations like "sum" on raw data if necessary, it
> > just means we have to interpolate.
> >
> > *Scalar operations:*
> > /sum((id(a_metric_in_milliseconds), *1000**id(a_metric_in_seconds)),
> 10m)/
> > ----------------------------------------------
> >
> > Of course many other functions could come growing the library.
> >
> > Now I suppose the big question, if we want to do such thing, is "are
> > we going to invent our own language?" I don't know if there are
> > standards for this, and if they are good.
> >
> > The Prometheus query language cannot be transposed because a label is
> > not a tag and it makes no sense for us to write something like
> > "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".
> >
> > The same language could be used both for read-time on-the-fly
> > aggregations and write-time / cron-based rollups.
> >
> > WDYT?
> >
> >
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/ec2d543c/attachment.html