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
