3 Replies Latest reply on Apr 13, 2012 3:29 AM by pilhuhn

    REST interface cannot return more than 60 data points

    genman

      RHQ 4.2.

       

      Script:

       

      #!/bin/bash
      
      outdir=data
      url=http://localhost:7080/rest/1/metric/data
      duration=259200000
      ids="657236 623969 611685 611697" # 623970 611692 611701"
      dataPoints=120
      user="user:pw"
      udate=$( date "+%s" )
      sdate=$(( udate - 60 * 60 * 24))
      jsdate=$(( sdate * 1000 ))
      jedate=$(( udate * 1000 ))
      
      function c() {
          curl --user $user -H "Accept: application/json" "${url}/${1}/?dataPoints=${dataPoints}&startTime=${jsdate}&endTime=${jedate}"
      }
      
      for i in $ids
      do
          echo $i
          c $i > $outdir/${i}.json
      done
      

       

      If use 120 points, I only get back 60 regardless of the amount of data points.

       

      But I know this parameter is 'seen' since there is a bug when the number is increased. For example, I ask for 120 data points using the default duration, I get back 60 points where 30 of them are NaN values.

        • 1. Re: REST interface cannot return more than 60 data points
          pilhuhn

          This is a know limitation of the underlying server method to retrieve those bits (the classical graphs only display 60 slots)

           

          You can use the raw data retrieval - see e.g. http://pilhuhn.blogspot.de/2012/01/some-graphing-fun-with-d3js.html

          1 of 1 people found this helpful
          • 2. Re: REST interface cannot return more than 60 data points
            genman

            Is there some reason for this limitation?

             

            What is the raw URL to use? It wasn't clear to me...

            • 3. Re: REST interface cannot return more than 60 data points
              pilhuhn

              Well,

              the graphs as they are, have been ported over from JON 1. And there they only had the 60 buckets, so the code was developed with this in mind (even if the api suggests differently). This is definitively something that needs changing. With some luck we will have a GSoC student working on this. The REST-api call is merely calling this existing backend method with the 60 slots.

               

              The raw metric can be obtained at http://localhost:7080/rest/1/metric/data/{schedule}/raw      

              You can pass in a duration in seconds (end time=now)   ?duration=604800

              and also dedicated start and end time.

               

                  @Path("data/{scheduleId}/raw")

                  public StreamingOutput getMetricDataRaw(@PathParam("scheduleId") int scheduleId,

                                                          @QueryParam("startTime") long startTime,

                                                          @QueryParam("endTime") long endTime,

               

              Note that with this api, only the raw data can be exposed (last 7 days), while with the other one, you get access to the aggregated data of the past at well.