[Hawkular-dev] Metric id and url restrictions

[Thomas Segismont]

Out of curiosity, can you explain what's going wrong? I don't understand 
why a properly url-encoded character make the proxy fail.

Le 18/09/2015 23:13, Matt Wringe a écrit :
> On 18/09/15 11:32 AM, John Mazzitelli wrote:
>> Metric IDs from our Wildfly Agent contain "/" because those are characters that are valid for Wildfly resources and we use the Wildfly resource names as part of the metric ID to uniquely identify them.
>
> Yeah, and the cAdvisor metrics from Heapster also contain slashes, which
> is where I am seeing the problem right now with OpenShift proxies.
> Outside of the proxy, then everything works fine with having encoded
> slashes in the URL, which is why I don't see the issue with my own
> testing. But it looks like for the UI they may need to use the proxy.
>
> Its not just the OpenShift proxies that have this problem, its a common
> issue with some types proxies and servers as well.
>
>>
>> So for IDs of metrics coming from things like "/deployment=the-app.war/subsystem=ejb3" will have "/" in them. The only alternative would be for us to replace "/" with a character that is valid for URLs but invalid for Wildfly resource names. Say "$deployment=the-app.war$subsystem=ejb3" or something like that.
>
> I don't know if it really matter here how wildfly does things. Your
> client should be able to encode the metricid in one format when going
> into hawkular and then decode when they get things back from hawkular.
>
>
> I don't know what should be the right solution there:
>
> 1) we could enforce what is allowed in a metric id field. This means we
> break backwards compatibility with what we currently have, but it also
> means that we can open up the door to things like restricting some
> metrics to some internal only things (see
> https://issues.jboss.org/browse/HWKMETRICS-208).
>
> 2) we keep our current endpoint as is, but add a new endpoint which can
> do queries via a post (essentially this is just an escape route to get
> around the issue when dealing with systems like this).
>
> So to do the equivalence of:
>
> GET
> http://localhost:8080/hawkular/metrics/gauges/foo%2fbar/data?start=10&end=110&buckets=2
>
> You could do also do something like:
> POST http://localhost:8080/hawkular/metrics/gauges/data
> {
>     "metric-id": foo/bar,
>     "start": 10,
>     "end": 110,
>     "buckets":2
> }
>
> 3) Band-aid solution to fix the immediate problem: update the heapster
> sink to encode metric ids in a format which does not include the '/'
> anywhere in it. This doesn't really solve the problem, but it would at
> least get us past the problem until we come up with a better, more
> permanent solution.
>
> Any thoughts?
>
>>
>>
>> ----- Original Message -----
>>> Currently we are storing metric id as any string. There are no
>>> restrictions on how we name the metrics, and when you access a single
>>> metric via a url you just need to make sure its url encoded properly here.
>>>
>>> This works fine when dealing with a client and the Hawkular Metrics
>>> directly, but can cause problems when dealing with proxies or other
>>> intermediary servers which are not exactly url compliant.
>>>
>>> The big issue is with slashes in the metric id. Even when properly
>>> encoded this can cause problems with things like proxies not accepting
>>> them (and even certain web container don't like them).
>>>
>>> Since we need to be able to integrate over networks with these types of
>>> servers, we need to find a solution to resolve this in hawkular.
>>>
>>> Possible solutions
>>>
>>> - enforce naming of anything which can show up in a the URL to make sure
>>> it cannot include a '/' . This would include things like metric Id. This
>>> should probably be enabled by default, but we could have an option to
>>> disable this if a user needs it.
>>>
>>> - create a new endpoint which can be used to perform a POST instead of
>>> doing a GET on the metric endpoint. This would mean sending things like
>>> the metric id and query string as part of the message body in the POST
>>> instead of in the URL.
>>>
>>> Any thoughts?
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>