[Hawkular-dev] java-based prometheus metrics scraper

[John Mazzitelli]

> Why should this be part of the agent? Shouldn't this be rather a standalone utility?

The code I have now IS a standalone utility. One maven dep "org.hawkular.agent:prometheus-scraper" - pull that in and anything can become a prometheus scraper and you can use the standalone CLI to produce XML or JSON metric data. It just doesn't do anything "hawkular-y" with the data it collects. You could then write a Java wrapper around it to (for example) insert the data into Hawk-Metrics. But then, we already have such a thing (the wildfly-agent) to get started with that - so we could reuse that, too (which is the current plan).

This is mainly to support an OpenShift requirement. Since we'll already have the hawkular wildfly agent integrated in OpenShift (hopefully :-) the idea is to piggyback on that work. Otherwise, we would have to integrate yet another hawkular feed into OpenShift (and from what I can tell, that is NOT a trivial exercise and Matt would probably have a seizure if we asked him to).

One thing I'm contemplating is to have this Prometheus support being very independent from the current way the wildfly agent does its thing. So, for example, you could inject the wildfly agent subsystem in a standalone wildfly to use as an "agent core" but only enable the prometheus stuff (you just don't define any DMR or JMX metadata in standalone.xml). Run this in, say, swarm and you've got a standalone prometheus agent - it just happens to reuse code that the wildfly agent uses (it just so happens to run in an EAP container, but it doesn't have any DMR or JMX stuff enabled). It's just a thought.

Note that AFAICS, there is no real inventory associated with Prometheus data. So right now I'm thinking this Prometheus stuff is only a "metrics only" feature. There are no resource types or resources associated with Prometheus data. I'm still thinking about this, though. Prometheus adds in a different way of looking at the world compared to how we've been doing things.

This is all in flux right now. I'm perfectly willing to admit that we are growing the Hawkular WildFly Agent into something it wasn't originally envisioned to be and that we should do something else. Discussions are welcome.

----- Original Message -----
> Why should this be part of the agent? Shouldn't this be rather a standalone
> utility?
> 
> I mean it sure can reuse large parts of the code from the agent (talking to
> inv and metrics, etc), but Prometheus doesn't have much to do with Wildfly,
> does it?
> 
> I fear that we're just bloating the agent more and more until it becomes an
> inseparable "blob" as RHQ agent. It already does Wfly, JMX, platform and now
> Prometheus.
> 
> On Monday, April 11, 2016 09:00:32 PM John Mazzitelli wrote:
> > FYI: I finished a Java-based Prometheus scraper - seems to be working. It
> > is
> > just code that scrapes any remote Prometheus endpoint given a URL and let's
> > you easily walk the metric data for further processing (like, if you want
> > to insert that data into Hawkular Metrics or if you want to dump the data
> > in XML or JSON format - the CLI does this today, see below). I'll
> > eventually blog about this, but not until I actually merge it into master.
> > It's in my branch right now here:
> > 
> > https://github.com/hawkular/hawkular-agent/tree/mazz/hwkagent-66-prometheus/
> > prometheus-scraper
> > 
> > This also includes a CLI tool - build the scraper maven module and you'll
> > get an uber-jar that let's you scrape a remote Prometheus endpoint and dump
> > the metric data in XML, JSON, or simple form. See the README.md for more.
> > 
> > Now I just have to figure out how to integrate this into the Hawkular
> > WildFly Agent :-) _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> --
> 
> Lukas Krejci
>