Tenant Id - Not Part of URL
by Stefan Negrea
Hello Everybody,
I've been working on a PR for the upcoming Hawkular Metrics release that will remove the tenant id from the end-point URLs. The tenant id will be moved to either a header parameter or a query parameter. The query parameter is in place for cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
Here is an example of the change:
Existing URL:
/{tenantId}/gauge/{metricId}/data
New URL:
/gauge/{metricId}/data
Tenant id set via:
1) header - tenantId
2) query parameter - tenantId
There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
Now, to the merits of this change. The tenant id is volatile, can change any time, and changes to it should be expected; but the rest of the URL is fixed. The second issue is that the tenant id is a security concern. So we were limited in design choices since a security concern was leaking as part of the URL.
So removing the tenant id from the URL will give us permanent & consistent addresses for resources (metrics and metric data points). And we will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id to be used on the request. If the same user later decides to use a tenant id to pass along the request, the URL of the resources would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret).
This change will give us the flexibility to adjust the security model (the meaning of tenant ids and ways to validate them) without compromising the URL structure. This will help Hawkular Metrics as it gets integrated into more and more projects and products.
Here are the links to the JIRA and the PR for this change:
https://github.com/hawkular/hawkular-metrics/pull/202
https://issues.jboss.org/browse/HWKMETRICS-68
Thank you,
Stefan Negrea
Software Engineer
1 year, 4 months
New and noteworthy in hawkular-parent 25
by Peter Palaga
Hi *,
hawkular-parent 25 brings the following:
* srcdeps-maven-plugin 0.0.5
* meets the promisses falsely done for 0.0.4:
* less console output
* built without tests
* wildfly-maven-plugin 1.1.0.Alpha4
I have sent PRs to all components repos.
Thanks,
Peter
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1 year, 4 months
[Metrics] How to react on low disk?
by Heiko W.Rupp
Hey,
<captain_obvious>
so for Hawkular-metrics (and Hawkular) we store the data in a Cassandra
database that puts files on a disk,
which can get full earlier than expected (and usually on week-ends). And
when the disk is full, Metrics does not like it.
</captain_obvious>
What can we do in this case?
I could imagine that on the C* nodes we run a script that uses df to
figure out the available space and tries
to run some compaction if space gets tight.
Of course that does not solve the issue per se, but should give some air
to breathe.
Right now I fear we are not able to reduce the ttl of a metric/tenant on
the fly and have metrics do the right thing - at least if I understood
yak correctly.
That script should possibly also send an email to an admin.
In case that we run Hawkular-full, we can determine the disk space and
feed that into Hawkular for Alerts to pick it up and then have the
machinery trigger the compaction and send the email.
10 years
using hawkular wildfly agent as a custom java agent
by John Mazzitelli
This is for Matt, but figured post here for public consumption.
The question was asked yesterday, "Can we use the Hawkular WildFly Agent to monitor other things other than WildFly?"
I gave one answer, but forgot there is a second alternative.
====
The first answer that I gave is that you can use the Hawkular Wildfly Agent to collect JMX data via Jolokia interface. There is an integration in the agent that lets you define your resource and metric metadata and your JMX/Jolokia servers. As an example, see here: https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa56...
You define where your JMX servers are via the <remote-jmx> managed server like this:
<remote-jmx name="Remote JMX" enabled="false" resourceTypeSets="MainJMX,MemoryPoolJMX" url="http://localhost:8080/jolokia-war"/>
OK, that's the JMX integration. Maybe useful, maybe not. But I mention it just in case.
====
The second alternative I forgot to mention was the ability for any component running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that proxy that store inventory and metrics into the Hawkular Server.
There is an example WAR module in the agent git repo that demonstrates how to obtain the proxy via JNDI and how to store inventory and metrics - see here: https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-a...
This is just a simple WAR with a servlet. But it shows how a component can get the agent proxy via JNDI here:
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
Here's code that shows the servlet doing things like sending metrics, avail, and creating resources:
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
No one is using this yet. So there may be issues I am not aware of, but we have integration tests that show this working.
This was put together with the anticipation of someone asking for this capability - that is, "can the agent be used to collect metrics for other things other than WildFly". Essentially, this just gives you a skeleton Java agent that you can extend to collect your own metrics and inventory. So you can write a WAR or EAR, deploy it in any WildFly that has an agent subsystem, and your EAR/WAR can be used as an "agent" for your custom stuff.
Again, maybe useful, maybe not. But I mention it just in case.
10 years
ruby-to-py
by John Mazzitelli
The ruby client is getting a lot of work and seems to be coming into shape.
What are the chances of us being able to take that ruby client and "copy" it to make a python client so we can have both ruby and py support?
10 years
Test coverage
by Heiko W.Rupp
Hey,
I think we should start looking at and recording test coverage
of our various Hawkular artifacts and also "enforce" them like
failing pull-requests when coverage is going below a certain
threshold.
We should have done that long time ago, but better late then
never ;-)
Heiko
10 years
Fwd: [aerogear-dev] Artemis bug on WildFly-10
by Heiko W.Rupp
Also as FYI in case we see something similar.
> From: Matthias Wessendorf <matzew(a)apache.org>
> To: AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org>
> Subject: [aerogear-dev] Artemis bug on WildFly-10
> Date: Thu, 24 Mar 2016 00:42:46 +0100
>
> Hi,
>
> more as a FYI....
>
> I am in the process of updating our Docker -DEV image to WF/10 (see
> [1]),
> and I noticed a bug in Artemis:
>
>
> Caused by: javax.jms.JMSException: Failed to create session factory
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
> at
> org.jboss.aerogear.unifiedpush.message.util.JmsClient$JmsReceiver.from(JmsClient.java:173)
> ... 172 more
> Caused by:
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT
> message=AMQ119013: Timed out waiting to receive cluster topology.
> Group:null]
> at
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:813)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> ... 175 more
> Now, this issue is addressed by
> https://issues.apache.org/jira/browse/ARTEMIS-385 and fixed in
> ActiveMQ-Artemis 1.3.0 (unreleased), but WildFly 10.x is (currently)
> on
> their 1.1.0 version.
>
> Worth to mention; I think I am unable to reproduce this directly on my
> Mac,
> just w/ CentOS7 and WF-10 (via ), using this image:
> https://github.com/jboss-dockerfiles/wildfly/tree/10.0.0.Final
>
>
> Cheers,
> Matthias
>
> [1] https://github.com/matzew/dockerfiles/tree/WF_10_ups_120
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
10 years
