1:52 p.m.
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev