I. suppose if define usage.stats.job.aggregation.range = 60. , it shall means start date and end date will hav 60min , right .
this previously no issue, which if define 60, it will start and end date will be 60minues. However there one time, unexpecting restart the services, and cause to not update the pid id of usage job, there after this issue happen. No matter how i update usage.stats.job.aggregation.range to any value, it will update the record fo 5 minutes (start and end date) , this cause to a lot of record to the mysql table . And i never update this for 5minutes. Not sure where is bug of this and how to solve it. On Thu, Aug 5, 2021 at 11:31 PM K B Shiv Kumar <s...@indiqus.com.invalid> wrote: > Ideally a single restart should be good enough. However I vaguely remember > facing this issue. I faintly remember if we changed the > usage.stats.job.exec.time to something a little ahead, it picked up > properly after that. I don't know why, coz they ideally are not related. > Maybe it takes the other variables into consideration on every execution > time. > > PS: Here is a summary of my findings with usage server sometime(as in some > versions back) ago. While they may not be relevant to your problem, it may > help understand the variables better. > > usage.stats.job.exec.time = 00:10 > usage.execution.timezone = <TIMEZONE OF CLIENT DEPLOYMENT> > usage.aggregation.timezone = <TIMEZONE OF CLIENT DEPLOYMENT> > usage.stats.job.aggregation.range = 60 > usage.sanity.check.interval = 2 > > Additional Notes > usage.stats.job.aggregation.range = 60 > Aggregate usage in what period ? The above specifies aggregation every 60 > minutes ie every hour. > > usage.stats.job.exec.time = 00:10 > It seems there is a bug in the ACS usage script. Irrespective of whatever > time you give in usage.stats.job.exec.time, it will always execute at the > execution time zone's 00th minute that is at the fresh hour (assuming > usage.stats.job.aggregation.range = 60). > > usage.execution.timezone = Asia/Kolkatta > This basically tells the cloudstack usage when to run periodically. > Ideally it should run periodically at the above time as per the frequency. > For example it should run at the 10th minute IST every hour. But it won't. > See above. > > usage.aggregation.timezone = <TIMEZONE OF CLIENT DEPLOYMENT> > This is important. The above values tell you what interval to aggregate. > It also tells you when the script will run and as per what time zone the > script run is defined (see bug). It however does not tell you how to > aggregate. For example hour … Is it HH:00:00 to HH:59:59 ? Is it HH:30:00 > to HH+1:29:59 ? Why not HH:07:00 to HH+1:06:59 ? That is where this value > comes to play. It will aggregate usage from HH:00:00 to HH:59:59 as per > this zone. Then why does my DB show strange values like HH:15:00 to > HH+1:14:59 ? The reason is whatever be the aggregation timezone, the value > in the DB will always be stored in UTC. > Best Regards, > > K B Shiv Kumar > IndiQus Technologies > > > On 05-Aug-2021, at 20:18, Hean Seng <heans...@gmail.com> wrote: > > > > Yes, both had restarted . Shall I restart both again ? > > > > On Thu, Aug 5, 2021 at 1:19 PM Sudharma Jain <sudharma....@gmail.com> > wrote: > > > >> Hi, > >> > >> I believe you haven't restarted the usage service after setting the > >> configuration. > >> > >> Thanks, > >> Sudharma > >> > >> On Wed, Aug 4, 2021 at 8:32 PM Hean Seng <heans...@gmail.com> wrote: > >> > >>> Hi > >>> > >>> I had configure following : > >>> > >>> usage.stats.job.aggregation.range = 480 > >>> > >>> > >>> However my usage record show : > >>> > >>> "enddate": "2021-08-03'T'18:00:52+00:00", > >>> > >>> "startdate": "2021-08-03'T'17:55:51+00:00", > >>> > >>> > >>> Although running every 480min, but it creating one record every > >>> 5minutes. This make generating a lot of record to Database, > >>> > >>> Is there anybody can advise me where record search is few hour one > >>> calculation * for the start and end date". , which parameter to > >>> configure for this. > >>> > >>> > >>> > >>> > >>> -- > >>> Regards, > >>> Hean Seng > >>> > >> > > > > > > -- > > Regards, > > Hean Seng > > -- Regards, Hean Seng
