[Hawkular-dev] Metrics reporting into hawkular-metrics

[Michael Burman]

Hi,

There are actually many places where I think the API is too difficult 
and requires unnecessary lists, but I'm not favoring a large list of 
endpoints as convenience methods either, I think client libraries can 
take care of that issue, even if they look a bit silly. Otherwise using 
the API becomes too difficult "now which one should I choose for this 
behaviour, which one for this.."

I actually preferred the previous one which had all the metrics posted 
to a single place, instead of now dividing availability & numeric to 
different endpoints and I have to use different HTTP call for each 
metric type. Because in the end we're not talking about huge amount of 
extra code for client libraries even in this list case while adding just 
a single datapoint. For example, in Python this is simple:

data = [ { "data": .. } ]

In Golang it wouldn't be much more difficult either:

type Metric struct {
     Name string
     Data []*Datapoint
}

type Datapoint struct {
     Timestamp int64
     Value string
}

func main() {
     dpoint := &Datapoint{Timestamp: time.Now().Unix(), Value: "up"}
     metric := &Metric{Name: "hellometric", Data: []*Datapoint{dpoint}}
..

On reading path this is a bit more work, but still. Groovy was simple 
also. So I guess Java is the one with most work ;)

   - Micke


On 24.02.2015 13:30, Heiko W.Rupp wrote:
> Hi,
>
> I seem to have missed wrapping stuff like that.
>
> But why have <id, list <time,value>> when the most basic use case is a single <id, time, value> ?
> I think that way, client writing gets a lot harder than it should be.
>
> And no, having a java-json-serialization framework does not solve it for cases when the client
> is not written in java
>
>
>> Am 24.02.2015 um 12:21 schrieb Michael Burman <miburman at redhat.com>:
>>
>> Hi,
>>
>> The only issue I had with those methods was that I can't send anymore
>> availability & numeric metrics in the same request. But not that I
>> couldn't send many metrics in a same request. For example, this is what
>> my gather_agent sends to the endpoint:
>>
>> [
>>    {
>>      "data": [
>>        {
>>          "timestamp": 1424776542007,
>>          "value": 11989272.0
>>        }
>>      ],
>>      "name": "miranda.mem.memtotal"
>>    },
>>    {
>>      "data": [
>>        {
>>          "timestamp": 1424776542007,
>>          "value": 2423852.0
>>        }
>>      ],
>>      "name": "miranda.mem.memfree"
>>    },
>> ... and so on. In a single request. I'm posting this to the
>> http://{0}:{1}/rhq-metrics/{tenant_id}/metrics/numeric/data and it works
>> fine? I could send several data values of course in a single request
>> also. My python-client has tests for both of these scenarios, and they
>> seem to work fine?
>>
>>    -  Micke
>>
>>
>> On 24.02.2015 12:01, Heiko W.Rupp wrote:
>>> Hey,
>>>
>>> we need to have an endpoint that accepts a list of
>>>
>>> <name, timestamp , value>  triples.
>>>
>>>
>>> The current
>>>
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
>>>      List<NumericDataParams> paramsList) {
>>>
>>> does not work (not technically).
>>>
>>> A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
>>> Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
>>> a different id.
>>>
>>> The other similarly challenged endpoint is
>>>
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/{id}/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
>>>      @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
>>>
>>> The metric id is passed on the URL-Path and thus requires a new request per metric to report.
>>>
>>> The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
>>> to read mass data for one single id.
>>> Reporting use cases are different.
>>>
>>>
>>> _______________________________________________
>>> 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